macOS Red Team - XPC-Based Persistence and Post-Exploitation

This article was prepared entirely within the framework of fully authorized red team exercises and research conducted in our own lab environment.

You can access our GitHub repository, which serves as the source for the content described in this article, here: https://github.com/redinpulse/RinP-xpc-framework

Introduction

The tool we use to maintain persistence during the post-exploitation phase of our macOS red team work leverages a design weakness in the macOS BTM (Background Task Management) service. By creating a new service, it places itself into the launchd lifecycle as if it were a legitimate Apple service. This yields a command channel that can reconnect at a scheduled time even after the current session ends, with a reduced chance of being caught by signature-based detection.

Enterprise Mac fleets often sit outside the EDR visibility provided for Windows endpoints, or within a more limited monitoring scope. In this article we summarize, in the light of our field experience, the capabilities of our internal tool that targets this visibility gap and the macOS security layers it faces: BTM, SIP, TCC, Gatekeeper and the Keychain ACL.

Why does persistence matter?

The phase of a red team engagement that actually produces value is not merely gaining initial access, but proving that this access is sustainable. Meterpreter or shell sessions can drop at any moment because of a network interruption, the system entering sleep, or the relevant process being terminated. For a red team, persistence essentially answers three questions:

• Can we regain access the next day?
• Do we keep the same privilege level when we return?
• Are we caught by the blue team’s signature-based detection rules along the way?

Our tool aims to answer these three questions by drawing on macOS’s own components.

What the tool can do

Persistence and communication

• LaunchDaemon installation that bypasses BTM constraints - Using the launchctl bootstrap and kickstart chain, it works around BTM’s non-blocking (advisory) supervision model. The service it creates is started automatically at boot and kept running through the KeepAlive mechanism.
• XPC-based communication channel - Instead of network sockets, communication runs over macOS’s Mach-based IPC infrastructure and the launchd service registration mechanism. As a result, the communication and listening model closely resembles the behavior of legitimate system services.
• Dynamic service naming - The service name is generated randomly on each install in a form that fits the com.apple.* pattern. There is no target service name or fixed IoC string embedded in the binary.
• Session-independent operation - The client is designed as a small, single-purpose binary with a low footprint. It runs when needed and exits once it completes its task.

Post-exploitation capabilities

• Running commands in the root context, creating new processes with defined arguments and environment variables, and reading files.
• Analyzing and exporting the TCC database - It maps permissions such as camera, microphone, screen recording and full disk access. On systems where SIP is disabled, it also supports modifying TCC records.
• Enumerating Keychain items and building a service/account inventory; collecting SSH keys and listing saved Wi-Fi networks (SSIDs).
• Surveillance and system visibility - Taking screenshots through native macOS APIs, reading the clipboard, and listing running processes.
• Security and environment reconnaissance - Checking SIP, Gatekeeper, FileVault and firewall states; detecting fourteen different security products; scanning the reachability of the system’s XPC brokers and building a network interface inventory.

Operational efficiency

• Nineteen Metasploit post modules and a six-stage automation chain that can be run with a single command: system inventory, security assessment, credential collection, TCC analysis, evidence production and cleanup of operational traces. All resulting output is saved as loot.
• When output is piped, it produces single-line JSON, so it integrates directly with automation and existing workflows.
• It offers universal binary support for both Apple Silicon and Intel-based Mac systems.

The architecture we face: macOS persistence elements and security mechanisms

Every layer we had to account for while designing the tool also offers meaningful clues about the real defensive capacity of organizations’ Mac fleets.

launchd and LaunchDaemons. One of the natural homes of system-level persistence on macOS is the plist files under /Library/LaunchDaemons and the binaries that run with root privileges. Because legitimate software uses the same mechanism, this directory is quite noisy for detection. The distinguishing indicators are therefore not only the file’s location; they are its code signature, its origin and its runtime behavior.

BTM (Background Task Management). BTM is the supervision layer Apple uses to track persistence items that run in the background without requiring user consent. The critical weakness in its design is that the disposition information is advisory: BTM can flag and register a service, but it does not block it at runtime. The bootstrap and kickstart chain our tool uses takes advantage of exactly this gap. In our laboratory tests, BTM registered the relevant service with an [enabled, allowed] state but did not prevent it from running. This behavior stems from an architectural supervision choice rather than the exploitation of a software vulnerability in the classic sense. For organizations that do not monitor BTM telemetry, it creates a silent visibility gap.

SIP (System Integrity Protection). When SIP is disabled, the root user’s domain of influence expands significantly, including the ability to write directly to the TCC database. When SIP is enabled, platform protections close this path. Determining the target system’s SIP state in advance is therefore critical for choosing the chain to be used in the red team engagement and the capabilities that can be reached.

TCC (Transparency, Consent and Control). TCC centrally manages sensitive permissions such as camera, microphone, screen recording and full disk access. Even a process with root privileges cannot arbitrarily grant itself permissions through the supported APIs. That said, in laboratory environments where SIP is disabled, the TCC database can be modified directly. During our tests, camera permission was added to a sample application, the change was verified through a database dump, and it was reverted at the end of the test.

Keychain and the ACL model. The Keychain is one of the most resilient security layers on macOS. Wi-Fi passwords and other secrets are protected by ACL policies that may require user interaction. Root privileges therefore do not automatically grant access to every item, especially in the context of a daemon without a user interface; access attempts may end with the errSecInteractionNotAllowed error. Taking this boundary into account, our tool builds an inventory from reachable data such as service names, account information and SSID lists. Knowing where a security boundary begins is an engineering requirement as important as offensive capability.

Gatekeeper, FileVault and EDR. Code signature verification, disk encryption and endpoint security solutions form the outer layers of the defensive chain. Although the tool’s signature-based detection surface is reduced, it is not entirely invisible. It can still be detected through behaviors such as creating a new plist, placing an unsigned binary, and using launchctl bootstrap. In our engagement reports we separately document these indicators as detection and monitoring points the blue team can use.

All of these layers point to a single core principle: on macOS, gaining privilege and accessing secret data are not the same thing. Root access does not mean every piece of data protected by TCC or the Keychain can automatically be reached. A successful macOS red team engagement does not stop at showing that root was reached; it clearly maps where that privilege is effective and at which security walls it is constrained.

What this means for organizations

As Mac fleets grow, organizations frequently run into a visibility gap: comprehensive EDR tracking on Windows endpoints, and fragmented, limited monitoring on macOS systems.

If BTM telemetry is not tracked, unsigned LaunchDaemons are not audited, and TCC changes do not raise alerts, it remains relatively easy for attackers to maintain persistence with little noise. The main reason we developed our own tool is to reveal these blind spots in client environments with verified findings rather than assumptions. We report, with the same transparency, at which stages we went undetected and at which points the defensive mechanisms engaged.

The value of a capable red team engagement lies not only in the ability to move undetected, but in the ability to measure where an organization’s existing defensive capacity is effective and where it falls short.

Our red team services

At Red in Pulse we run multi-platform red team, adversary simulation and purple team engagements, macOS included. We do not present our findings only as technical vulnerabilities; we turn them into prioritized, repeatable detection scenarios your blue team can use directly.

If you would like to assess your macOS security posture from the method and perspective of a real attacker, you can get in touch with us to discuss our red team services.