macOS Security Architecture

What macOS gives you for free — and where it falls short

TCC (Transparency, Consent, and Control) is macOS's permission framework for sensitive resources. Applications must be explicitly granted access to the camera, microphone, contacts, calendar, photos, full disk access, screen recording, accessibility features, and the Desktop/Documents/Downloads folders. TCC prompts are enforced by the kernel — an application cannot bypass TCC by running as root. Even with root access, TCC-protected resources require explicit user consent or an MDM-managed TCC profile. This is stronger than anything Windows provides natively: there is no Windows mechanism that prevents a root-level process from reading the user's documents folder.

For endpoint security, TCC creates both a protection and a constraint. The protection: malware on macOS cannot silently access the camera, keylog through accessibility APIs, or read browser credential stores without triggering a TCC prompt. The constraint: MDE for macOS itself needs TCC permissions to function — specifically Full Disk Access for file scanning, System Extensions for system event monitoring, and Network Extension for network traffic filtering. Without these grants, MDE operates in a degraded mode with limited visibility. Deploying MDE's TCC permissions at enterprise scale requires Intune MDM: the TCC permissions are delivered as a configuration profile, granted silently through the MDM channel without user prompts. This is why macOS endpoint security at scale requires Intune enrollment, not just MDE installation.

The attacker's perspective on TCC differs from Windows at every level. An attacker who gains code execution on macOS faces TCC restrictions that constrain post-exploitation in ways Windows attackers never encounter. Keylogging requires an accessibility TCC grant. Screen capture requires screen recording. Reading Safari passwords requires full disk access. If the attacker does not have these grants — and they typically do not because they inherit the permissions of the compromised process — they must either bypass TCC through a vulnerability (these exist but are patched aggressively by Apple), social-engineer the user into granting permissions, or operate within the permissions the compromised process already has. TCC significantly constrains the post-exploitation toolkit compared to Windows.

Gatekeeper prevents execution of unsigned or unnotarized applications downloaded from the internet. When a user downloads an application, Gatekeeper checks its code signature and notarization status. Unsigned applications are blocked by default. Notarization means Apple has scanned the binary for known malware before the developer distributed it. The user can override Gatekeeper for individual applications through right-click → Open, but this requires deliberate action — drive-by downloads are blocked without user intervention. The limitation: Gatekeeper validates the signature and notarization but not the application's behavior. A signed, notarized application that performs malicious actions after execution is not caught by Gatekeeper — which is the scenario in the phishing example above. This is exactly how Atomic Stealer (AMOS) operates: the malware is distributed as a signed disk image that passes Gatekeeper, then uses AppleScript to display a fake password prompt that harvests the user's credentials.

The macOS threat landscape has evolved significantly. Shlayer dominated macOS malware for several years through adware bundling and fake Flash Player installers. Atomic Stealer (AMOS) emerged as a credential stealer targeting browser passwords, cryptocurrency wallets, and Keychain data — sold as malware-as-a-service for $1,000/month. MacStealer targets similar data with a Telegram-based C2 infrastructure. Realst targets cryptocurrency users through fake blockchain game websites. These are not theoretical threats — they are active campaigns observed in production environments. The common pattern: all bypass Gatekeeper through social engineering (convincing the user to open the application) or through legitimate code signing (obtaining a Developer ID certificate under false pretenses). Gatekeeper is a gate, not a wall — it prevents accidental execution of unsigned code but does not prevent deliberate execution of signed malicious code.

SIP (System Integrity Protection) prevents modification of protected system directories — /System, /usr (except /usr/local), /bin, /sbin — even by processes running as root. SIP is enforced by the kernel and can only be disabled from Recovery Mode, requiring physical access. An attacker with root access on a running macOS system cannot modify system binaries, cannot replace system frameworks, and cannot install rootkits in protected directories. The attacker must persist in non-protected locations: launch agents (~/Library/LaunchAgents/), login items, or application-specific directories. This is a significant architectural advantage over Windows, where a root-level attacker can modify any system file, and over Linux, where root can modify anything without kernel-level enforcement.

On Apple Silicon Macs (M1/M2/M3/M4), the security architecture adds another layer: Secure Boot validates the entire boot chain from the Secure Enclave before the kernel loads. The signed system volume (SSV) cryptographically verifies the integrity of the system volume at every boot. Traditional kernel rootkits that modify kernel memory or load unsigned kernel extensions are effectively impossible on modern macOS with SIP enabled and Secure Boot enforcing. This does not mean macOS is immune to persistent compromise — user-space persistence through launch agents and login items remains available — but it means the persistence mechanisms available to an attacker on macOS are significantly more constrained and more detectable than on Windows or Linux, where kernel-level persistence is achievable with sufficient privilege.

The Endpoint Security Framework is Apple's API for security tools to receive kernel-level event notifications. It provides process execution events, file system events, network events, and authentication events — similar to what ETW provides on Windows. MDE for macOS uses the ES framework for real-time protection and EDR telemetry. The ES framework replaced the deprecated kext model, providing security tools with stable, supported kernel-level visibility without the risks of loading third-party kernel code. On Apple Silicon, kexts are no longer supported at all — the ES framework is the only path for security tool kernel-level integration.

macOS security status: what the analyst checks

Before deploying MDE on macOS endpoints, you need to verify that the built-in protections are active and properly configured. Three commands give you the baseline security posture.

$ csrutil status
System Integrity Protection status: enabled.
$ spctl --status
assessments enabled
$ sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db \
    "SELECT client, service, auth_value FROM access WHERE auth_value=2;"
com.microsoft.wdav       | kTCCServiceSystemPolicyAllFiles | 2
com.microsoft.wdav.epsext | kTCCServiceSystemPolicyAllFiles | 2
$ mdatp health --field real_time_protection_enabled
true
$ mdatp health --field definitions_status
"up_to_date"

SIP enabled means system binary protection is active — the kernel prevents modification of protected directories even by root. Gatekeeper assessments enabled means unsigned application blocking is active. The TCC database query shows which applications have been granted Full Disk Access (auth_value=2 means granted). The two com.microsoft.wdav entries are Defender for macOS and its endpoint security system extension — both need Full Disk Access to scan the filesystem. If these entries are missing, MDE is operating in degraded mode. The mdatp health checks confirm real-time protection is active and definitions are current.

On a macOS endpoint without MDE deployed, the first three checks still apply — SIP and Gatekeeper should always be enabled. If SIP is disabled on any endpoint, investigate immediately: SIP can only be disabled from Recovery Mode, which requires physical access or MDM remote Recovery. A disabled SIP on a managed device indicates either unauthorized physical access or a serious misconfiguration.

TCC bypass vulnerabilities deserve specific attention because they undermine the strongest part of macOS's defense model. Apple patches TCC bypasses aggressively — they are treated as security-critical issues — but new bypasses are discovered regularly. Recent examples include CVE-2023-32369 (Migraine), which allowed TCC bypass through the macOS Migration Assistant, and CVE-2023-40424, which bypassed TCC through a Finder race condition. These bypasses typically require local code execution first, which means TCC bypass is a post-exploitation technique rather than an initial access vector. The defensive response: keep macOS fully patched (TCC bypass patches are in Rapid Security Responses, not just major updates), deploy MDE for macOS to detect post-exploitation TCC bypass attempts, and use Intune TCC profiles to ensure MDE itself has the permissions it needs to detect these attempts. The TCC model is strong enough that attackers invest significant effort in finding bypasses — which is itself evidence that TCC provides meaningful security value.

The Endpoint Security Framework and macOS persistence

Starting with macOS 10.15 Catalina, Apple replaced kernel extensions (kexts) with the Endpoint Security (ES) framework for security tool integration. The ES framework provides an authorized, user-space API for security tools to receive kernel-level event notifications: process execution, file system events, network events, and authentication events — analogous to what ETW provides on Windows. MDE for macOS uses the ES framework as its primary telemetry source, receiving kernel-level notifications without requiring a kernel extension. This is more stable than the kext approach — kexts could cause kernel panics — and more secure because the ES API limits what the security tool can access to specific event categories.

The practical implication: MDE on macOS has different detection capabilities than MDE on Windows because the ES framework provides different event types than Windows ETW. macOS ES does not provide the equivalent of Windows registry events — macOS uses property lists, not a registry. macOS ES provides different network event granularity. And macOS process monitoring captures different metadata fields than Windows DeviceProcessEvents. KQL hunting queries written for Windows may need adaptation for macOS — the MDE Advanced Hunting table names are the same, but the available fields and event types differ per platform.

This cross-platform detection asymmetry matters for security operations. A detection rule that works on Windows — monitoring DeviceRegistryEvents for Run key persistence — has no equivalent on macOS because macOS does not have a registry. The macOS equivalent is monitoring DeviceFileEvents for .plist creation in LaunchAgents directories. Both are persistence detection, both use MDE tables, but the query logic is completely different. Security teams that build detections only for Windows and assume "MDE covers macOS too" are correct at the telemetry level (MDE collects macOS events) but wrong at the detection level (the detection rules must be platform-specific). Module ES13 addresses this by building parallel detection sets for Windows, Linux, and macOS persistence, credential access, and execution patterns.

Where Windows has registry run keys and scheduled tasks for persistence, macOS uses launch agents (per-user, ~/Library/LaunchAgents/) and launch daemons (system-wide, /Library/LaunchDaemons/). Each is a property list (.plist) file specifying a program to run at user login (agents) or system startup (daemons). An attacker who drops a malicious .plist in LaunchAgents gains persistence that survives reboot. MDE for macOS monitors these directories for new .plist creation through the ES framework's file monitoring, alerting if the .plist points to a suspicious binary. Login items — applications configured to launch at user login through System Settings — are another persistence mechanism that the ES framework monitors. Cron jobs exist on macOS but are less commonly used than on Linux — launch agents are the standard persistence mechanism for macOS. The SIP-protected LaunchDaemons directory at /System/Library/LaunchDaemons/ cannot be modified even by root, but the user-writable directories at ~/Library/LaunchAgents/ and /Library/LaunchDaemons/ are the primary persistence targets for macOS malware.

// Detect macOS persistence — new LaunchAgent or LaunchDaemon creation
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath has_any ("LaunchAgents", "LaunchDaemons")
| where ActionType == "FileCreated"
| where FileName endswith ".plist"
| project Timestamp, DeviceName, FolderPath, FileName,
    InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc

This query detects the macOS equivalent of Windows registry Run key persistence — new .plist files created in LaunchAgents or LaunchDaemons directories. On a stable macOS fleet, software installations are the primary legitimate source of new launch agents. A .plist created by a scripting engine (bash, python, osascript) rather than an installer process warrants investigation. The InitiatingProcessFileName field distinguishes between legitimate installer activity and suspicious persistence creation — the same process-context filtering that works for Windows registry persistence applies to macOS launch agent detection.