At the red team operation against the macOS fleet of one fintech company in early 2026, we received an initial access through credential phishing - and stumbled in a minute to CrowdStrike Falcon. He shot every reverse-shell payload before the first callback. Recompilation, ellcode encryption, obfuscation - Falcon caught on behavior, giving from a force of 30 seconds of aFOB. The solution came from another direction: XM Cyber (Hillel Pinto) researchers have shown that EDR and MDM agents on macOS can simply be turned off. On behalf of the standard user, without sudo, without kernel-exploitation. Three primitives – weak XPC-validation, injection through NIB files and abuse of kernel trust cache – allow silently deactivating CrowdRStrike Falcon Sensor, Kandji MDM and at least one more enterprise EDR. Kandji assigned the find CVE-2026-39118CrowdStrike paid the bug bounty. Apple refused to change the architecture. Classics.
Business logic of attack: why disable endpoint security on macOS
According to CrowdStrike Global Threat Report 2025, 79% of attacks are carried out without malware - through hands-on-keyboard and living off the land. Attacking with initial access on macOS-host wants:
• Fix - put a persistence without an alert
• Collect credentials - Keychain dump, SSH keys, OAuth tokens
• Develop an attack - lateral movement on other corporate network hosts
Each step generates a telemetry that an EDR agent sends to SOC/SIEM. If the agent is silent, the SOC team is blind. Simultaneous shutdown of CrowdStrike (detection) and Kandji (compliance/MDM) - complete loss on the endpoint. For a macos-float of 200-500 hosts, this is several hours of unhindered operation until the network funds notice an anomaly.
[Applicable to: internal pentest, red team-operation, post-exploitation on macOS 13+ with corporate EDR/MDM]
macOS gives vendors the only legitimate path to the system telemetry - Endpoint Security Framework (ES). Through ES, the agent receives notifications about events: exec, fork, open, mmap, mount and dozens of others. The agent works as a privileged LaunchDaemon with root rights, and UI components and auxiliary processes turn into user space. According to Outflank (EDR Internals for macOS and GNU/Linux study), this architecture - daemon + user-spacelessers - creates an attack surface that does not have Windows analogues with kernel-drivers.
And here the most interesting thing begins.
XPC-validation: where trust between the components is broken
The relationship between the components of the agent (daemon <-> UI, daemon <-> updater, daemon <->helmer) goes through XPC - regular IPC-mechanism macOS. Each XPC service is described by a plist file, communication passes through the Match ports. The critical point is the validation of the client. When process A is connected to XPC-service B, service B can check:
1. Code Signaling Activity of the Connecting Process
2. Team ID - whether the binary belongs to the vendor
3. Entitlements - are there any necessary privileges
4. Audit token - PID, UID, GID Cause Process
The problem that the XM Cyber team found: a number of EDR and MDM agents perform this validation is not strictly enough. Some check the presence of a valid Apple signature, but do not verify the Team ID. Others rely on path-based validation, which can be bypassed via symlink. In fact, Security Missviguration (A06 OWASP) at the IPC level of the desktop application. This gap is the first link in the chain (T1559.003, Execution)
Attack chain: from standard user to disconnecting the agent
Adjustments to the environment:
• macOS 13 Ventura or New (Endpoint Security Framework v2+)
• Standard user (without admin/sudo)
• EDR/MDM agent is installed and active (CrowdStrike Falcon, Kandji, analogue)
• SIP included (compartment corporate configuration)
• For XPC laboratory analysis: VM with SIP, Frida 16+ (pip install frida frida-tools) xpcspy, jtool2
Full chain: Recon -> XPC exploitation -> NIB injection -> Trust cache abuse -> Agent disable
Intelligence: fingerprinting EDR and MDM (T1518.001, Discovery)
Determination of the established EDR is performed without privileges:
Bash:
launchctl list | grep -iE 'crowd|falcon|kandji|sentinel|carbon'
ps aux | grep -iE 'falcond|kandji|sentineld'
ls /Library/LaunchDaemons/ | grep -iE 'crowd|kandji'
CrowdStrike Falcon registers daemon as com.crowdstrike.falcon.Agent, Kandji - how io.kandji.KandjiAgent. In addition launchctl is worth checking /Library/LaunchDaemons/ and /Library/LaunchAgents/ directly - some agents put several XPC services for different functions (update, telemetry, UI component).
For deep fingerprinting XPC services is useful xpcspy - utility based on Frida, intercepting XPC-messages in real time. It shows what methods the service exports. Static analysis of binarys through jtool2 allows you to extract entitlements and code signing requirements without starting the process.
Limitation: on macOS with SIP (all corporate hosts) dtrace and part of the Frida toolkit is limited. Fingerprinting through launchctl and ps It always works, the dynamic XPC analysis requires a laboratory environment with SIP switched off.
Exploitation of XPC and macOS privilege escalation (T1559.003, T1068)
The key primitive is the creation of a process that the XPC service of the agent will take as a legitimate component. According to XM Cyber, it is achieved through the client’s validation gap: the agent checks the client’s signature, but does not verify the full trust chain (Team ID, bundle identifier, entitlements). In terms of MITRE ATT&CK:
• T1559.003 (XPC Services, Execution) - the use of XPC as a privileged operations channel
• T1068 (Exploitation for Privilege Escalation) - exploiting software error to increase privileges
The attacker forms an XPC message that causes the privileged function of the agent (control by the sensor state: start/stop/unload). The standard user should not have access to such methods, but weak validation allows you to circumvent the restriction.
When the technique is NOT working:
• Agent uses a full audit check token with the verification of Team ID and a specific signing code requirement
• XPC service requires entitlement, which is impossible to obtain without a vendor signature
• Agent Built with Hardened Runtime + Library Validation
NIB file injection: payload via Interface Builder
NIB files (NeXT Interface Builder) - serialized descriptions of UI elements of macOS-app applications. When loading NIB, the application desileizes objects, including bindings to methods (actions) and values (outlets). Substitution of the NIB file of a legitimate application leads to the execution of arbitrary code in its context.
Sounds like a bug? No. It's by design - just no one thought that someone would replace the NIB in the context of the EDR.
XM Cyber uses NIB injection as a payload delivery mechanism in the context of the process that XPC service trusts. The modified NIB contains calls that form an XPC message to the preferred service of the agent. This is an extension of Process Injection (T1055) - instead of injecting the rashlocodine in memory, a standard mechanism of deseresilization of UI resources is used.
When the technique is NOT working:
• SIP-Secured directories (/System/, /usr/) - recording is not possible
• MDM-profile restricts the rights of entry in /Applications/
• The application uses Hardened Runtime with Library Validation, blocking the loading of modified resources
Trust cache abuse: CDHash and "memory" of the kernel
The third element is abuse kernel code-signing trust cache. The macOS kernel leads the CDHash cache - cryptographic hash of signed binaries. According to XM Cyber, CDHash continues to be considered trusted even after the modification of the binary: the kernel “remembers” it as tested.
Consistency:
1. Legitimate signed application starts - CDHash gets trust in cache
2. The attacker modifies the binary (adds NIB injection payload)
3. Modified binary starts - the core trusts it on a cashed CDHash
Apple, according to XM Cyber, does not plan to correct this behavior. Vendors of software are invited to independently implement protection. That is, Apple says: “Your problems are your solutions.”
Final: Disable or Modify Tools (T1562.001, Defense Evasion)
The result of the chain is to call the privileged function of the agent through a compromised XPC channel. According to XM Cyber, it was possible to:
• CrowdStrike Falcon Sensor - unload without triggering
• Kandji MDM Agent - permanent deactivation
• Third Enterprise EDR (not disclosed) - similar deactivation
All three products are disabled without a single notification in SOC. Direct application Disable or Modify Tools (T1685, Defense Evasion) Three agents, three vendors, the same architectural vain.
Business logic of attack: why disable endpoint security on macOS
According to CrowdStrike Global Threat Report 2025, 79% of attacks are carried out without malware - through hands-on-keyboard and living off the land. Attacking with initial access on macOS-host wants:
• Fix - put a persistence without an alert
• Collect credentials - Keychain dump, SSH keys, OAuth tokens
• Develop an attack - lateral movement on other corporate network hosts
Each step generates a telemetry that an EDR agent sends to SOC/SIEM. If the agent is silent, the SOC team is blind. Simultaneous shutdown of CrowdStrike (detection) and Kandji (compliance/MDM) - complete loss on the endpoint. For a macos-float of 200-500 hosts, this is several hours of unhindered operation until the network funds notice an anomaly.
[Applicable to: internal pentest, red team-operation, post-exploitation on macOS 13+ with corporate EDR/MDM]
macOS gives vendors the only legitimate path to the system telemetry - Endpoint Security Framework (ES). Through ES, the agent receives notifications about events: exec, fork, open, mmap, mount and dozens of others. The agent works as a privileged LaunchDaemon with root rights, and UI components and auxiliary processes turn into user space. According to Outflank (EDR Internals for macOS and GNU/Linux study), this architecture - daemon + user-spacelessers - creates an attack surface that does not have Windows analogues with kernel-drivers.
And here the most interesting thing begins.
XPC-validation: where trust between the components is broken
The relationship between the components of the agent (daemon <-> UI, daemon <-> updater, daemon <->helmer) goes through XPC - regular IPC-mechanism macOS. Each XPC service is described by a plist file, communication passes through the Match ports. The critical point is the validation of the client. When process A is connected to XPC-service B, service B can check:
1. Code Signaling Activity of the Connecting Process
2. Team ID - whether the binary belongs to the vendor
3. Entitlements - are there any necessary privileges
4. Audit token - PID, UID, GID Cause Process
The problem that the XM Cyber team found: a number of EDR and MDM agents perform this validation is not strictly enough. Some check the presence of a valid Apple signature, but do not verify the Team ID. Others rely on path-based validation, which can be bypassed via symlink. In fact, Security Missviguration (A06 OWASP) at the IPC level of the desktop application. This gap is the first link in the chain (T1559.003, Execution)
Attack chain: from standard user to disconnecting the agent
Adjustments to the environment:
• macOS 13 Ventura or New (Endpoint Security Framework v2+)
• Standard user (without admin/sudo)
• EDR/MDM agent is installed and active (CrowdStrike Falcon, Kandji, analogue)
• SIP included (compartment corporate configuration)
• For XPC laboratory analysis: VM with SIP, Frida 16+ (pip install frida frida-tools) xpcspy, jtool2
Full chain: Recon -> XPC exploitation -> NIB injection -> Trust cache abuse -> Agent disable
Intelligence: fingerprinting EDR and MDM (T1518.001, Discovery)
Determination of the established EDR is performed without privileges:
Bash:
launchctl list | grep -iE 'crowd|falcon|kandji|sentinel|carbon'
ps aux | grep -iE 'falcond|kandji|sentineld'
ls /Library/LaunchDaemons/ | grep -iE 'crowd|kandji'
CrowdStrike Falcon registers daemon as com.crowdstrike.falcon.Agent, Kandji - how io.kandji.KandjiAgent. In addition launchctl is worth checking /Library/LaunchDaemons/ and /Library/LaunchAgents/ directly - some agents put several XPC services for different functions (update, telemetry, UI component).
For deep fingerprinting XPC services is useful xpcspy - utility based on Frida, intercepting XPC-messages in real time. It shows what methods the service exports. Static analysis of binarys through jtool2 allows you to extract entitlements and code signing requirements without starting the process.
Limitation: on macOS with SIP (all corporate hosts) dtrace and part of the Frida toolkit is limited. Fingerprinting through launchctl and ps It always works, the dynamic XPC analysis requires a laboratory environment with SIP switched off.
Exploitation of XPC and macOS privilege escalation (T1559.003, T1068)
The key primitive is the creation of a process that the XPC service of the agent will take as a legitimate component. According to XM Cyber, it is achieved through the client’s validation gap: the agent checks the client’s signature, but does not verify the full trust chain (Team ID, bundle identifier, entitlements). In terms of MITRE ATT&CK:
• T1559.003 (XPC Services, Execution) - the use of XPC as a privileged operations channel
• T1068 (Exploitation for Privilege Escalation) - exploiting software error to increase privileges
The attacker forms an XPC message that causes the privileged function of the agent (control by the sensor state: start/stop/unload). The standard user should not have access to such methods, but weak validation allows you to circumvent the restriction.
When the technique is NOT working:
• Agent uses a full audit check token with the verification of Team ID and a specific signing code requirement
• XPC service requires entitlement, which is impossible to obtain without a vendor signature
• Agent Built with Hardened Runtime + Library Validation
NIB file injection: payload via Interface Builder
NIB files (NeXT Interface Builder) - serialized descriptions of UI elements of macOS-app applications. When loading NIB, the application desileizes objects, including bindings to methods (actions) and values (outlets). Substitution of the NIB file of a legitimate application leads to the execution of arbitrary code in its context.
Sounds like a bug? No. It's by design - just no one thought that someone would replace the NIB in the context of the EDR.
XM Cyber uses NIB injection as a payload delivery mechanism in the context of the process that XPC service trusts. The modified NIB contains calls that form an XPC message to the preferred service of the agent. This is an extension of Process Injection (T1055) - instead of injecting the rashlocodine in memory, a standard mechanism of deseresilization of UI resources is used.
When the technique is NOT working:
• SIP-Secured directories (/System/, /usr/) - recording is not possible
• MDM-profile restricts the rights of entry in /Applications/
• The application uses Hardened Runtime with Library Validation, blocking the loading of modified resources
Trust cache abuse: CDHash and "memory" of the kernel
The third element is abuse kernel code-signing trust cache. The macOS kernel leads the CDHash cache - cryptographic hash of signed binaries. According to XM Cyber, CDHash continues to be considered trusted even after the modification of the binary: the kernel “remembers” it as tested.
Consistency:
1. Legitimate signed application starts - CDHash gets trust in cache
2. The attacker modifies the binary (adds NIB injection payload)
3. Modified binary starts - the core trusts it on a cashed CDHash
Apple, according to XM Cyber, does not plan to correct this behavior. Vendors of software are invited to independently implement protection. That is, Apple says: “Your problems are your solutions.”
Final: Disable or Modify Tools (T1562.001, Defense Evasion)
The result of the chain is to call the privileged function of the agent through a compromised XPC channel. According to XM Cyber, it was possible to:
• CrowdStrike Falcon Sensor - unload without triggering
• Kandji MDM Agent - permanent deactivation
• Third Enterprise EDR (not disclosed) - similar deactivation
All three products are disabled without a single notification in SOC. Direct application Disable or Modify Tools (T1685, Defense Evasion) Three agents, three vendors, the same architectural vain.
