Most SOCs that are fluent in Windows telemetry go quiet on Macs: they cannot say which events their agent collects, where macOS persistence hides or what to preserve when a Mac is compromised. Meanwhile macOS infostealers have become routine, delivered by fake fixes that persuade users to paste commands into Terminal, and they go straight for the keychain, browser sessions and developer credentials. This guide goes deeper than the macOS Security Guide for Enterprises on the detection side: the Endpoint Security framework and other telemetry sources, detections mapped to MITRE ATT&CK v20, hunting for launch agent and launch daemon persistence, TCC manipulation, Gatekeeper bypass, and macOS incident response and forensics. It is written for detection engineers, threat hunters and incident responders who own Mac fleets, including developer Macs.
Key takeaways
- The Endpoint Security framework is the sensor. Apple's supported API delivers process, file, persistence, TCC, login and XProtect events to security agents; ask any macOS EDR which event types it subscribes to.
- Infostealers win by persuasion, not exploits. Campaigns such as those delivering AMOS (Atomic Stealer) have users paste commands into Terminal and type their password into a fake prompt, which sidesteps Gatekeeper evaluation.
- Persistence on a Mac is mostly launchd. Launch agents, launch daemons and login items are registered with Background Task Management, so BTM events and inventory diffs catch most of it.
- TCC changes are high-signal. A new Full Disk Access or Accessibility grant, or any write to a TCC database, deserves an alert, because TCC is what stands between malware and the user's data.
- Treat a stealer infection as a credential incident. Isolating and reimaging the Mac is not enough; every session, token and key the user's keychain, browsers and developer tools held must be revoked.
macOS telemetry: what each source gives you
No single source covers everything. The Endpoint Security (ES) framework provides real-time events, unified logging adds context, and on-disk artefacts let you reconstruct what happened before your agent was installed or after it was disabled.
| Source | What it records | How you get it | Limits |
|---|---|---|---|
| Endpoint Security framework | Process exec and fork, file open, write, rename and extended attribute changes, launch item registration, TCC grants, logins, sudo, XProtect detections, Gatekeeper overrides | A security agent built as a system extension; eslogger for testing | Real time only: no history before the client starts |
| Unified logging | Subsystem messages from the OS and apps at default, info, debug, error and fault levels | Console app, the log tool, or the OSLog framework for historical data | Dynamic values often redacted as <private>; retention measured in days and volume-dependent |
| Background Task Management | Registered login items, launch agents and launch daemons with their owning developer | sfltool dumpbtm, ES BTM events, the declarative status report (macOS 14 and later) | Snapshot, not a timeline |
| FSEvents | Directory-level change records persisted per volume in .fseventsd | Forensic collection from the volume | Records that a path changed, not who changed it |
| Security product state | XProtect signature and behavioural detections, XProtect Remediator clean-ups, Gatekeeper overrides | ES xp_malware_detected, xp_malware_remediated and gatekeeper_user_override events; unified log | Known malware only; behavioural detections depend on Apple's updates |
| MDM inventory | OS version, FileVault, firewall, SIP and profile state | Device management service queries and declarative status | Polling interval; reports configuration, not behaviour |
The Endpoint Security framework in practice
ES clients run as macOS system extensions, need the com.apple.developer.endpoint-security.client entitlement and a Full Disk Access grant, and subscribe to event types. AUTH events (such as ES_EVENT_TYPE_AUTH_EXEC, which "requests permission from the OS to execute another image") let the client allow or deny in line; NOTIFY events report after the fact. Apple's deployment guidance is that "third-party security agents should be used only if they take advantage of these APIs", and that macOS kernel extensions "are no longer recommended": since macOS 11 they cannot load on demand and require the Reduced Security boot mode. An agent still shipping a kext, or asking you to lower boot security, is a finding in itself.
| Event family | ES events (es_events_t members) | Detection use |
|---|---|---|
| Process | exec, fork, exit, cs_invalidated, remote_thread_create, get_task, trace | Process trees, unsigned or ad hoc signed code, injection and task port access |
| File and attributes | create, write, rename, unlink, setextattr, deleteextattr | Quarantine attribute removal, writes to launch directories, keychain and browser profile reads (open) |
| Persistence | btm_launch_item_add, btm_launch_item_remove | New login items, agents and daemons with instigating process and executable path |
| Privacy and policy | tcc_modify, profile_add, profile_remove | TCC grants and revocations with the responsible process; unexpected configuration profiles |
| Apple security products | xp_malware_detected, xp_malware_remediated, gatekeeper_user_override | Route XProtect verdicts and user overrides into the SIEM |
| Authentication and sessions | authentication, sudo, su, openssh_login, screensharing_attach, lw_session_unlock | Privilege use, remote access and unusual logins |
| Accounts | od_create_user, od_group_add, od_modify_password | New local admins and hidden accounts |
| Kernel | kextload, kextunload | Any kext load on a fleet that should have none |
Use eslogger on a test Mac to see the raw JSON for an event before writing a rule, and to confirm that your agent's field names map to the same data. See the Detection Engineering Guide for rule lifecycle and testing.
Unified logging and macOS forensics artefacts
The macOS unified log is Apple's unified logging system, which "centralizes the storage of log data in memory and on disk, rather than writing that data to a text-based log file". For detection it fills gaps the agent does not cover, and for response it is often the only record of activity before the agent saw the threat.
- Collect, do not stream everything: forwarding the full unified log is noisy and expensive. Forward targeted predicates (TCC decisions, authentication, XProtect, installer and software update activity) and collect a full archive with
log collectduring incidents. - Plan for redaction: dynamic strings are frequently logged as
<private>, so a predicate that matches on a path or user name may silently return nothing. Test predicates on real data. - FSEvents: the
.fseventsdrecords survive file deletion, which helps when malware cleans up its staging folders, as the infostealers below do. - Quarantine records: downloaded files carry the
com.apple.quarantineattribute and per-user quarantine event history, which ties a binary to the browser and URL that delivered it. Commands pasted into Terminal and files fetched with curl never get the attribute. - Persistence and privacy state: launch directories, BTM output, and the user and system TCC databases. For wider DFIR method see the Digital Forensics (DFIR) Guide.
macOS infostealers: AMOS and the Terminal paste chain
Microsoft's May 2026 analysis of a ClickFix campaign shows the current pattern. Fake "fix" articles tell the user to paste an encoded command into Terminal. Scripts run that way "don't undergo the same evaluation" as apps opened through Finder, so Gatekeeper never assesses them. Native utilities fetch the next stage, AppleScript runs through osascript in memory, and a fake prompt asks for the user's password, which the malware validates locally before using it. Microsoft names three families in the campaign: Macsync, SHub and AMOS (the AMOS stealer, also known as Atomic Stealer).
- What it takes: macOS keychain theft comes first: keychain databases, Chromium browser credentials, cookies and autofill, cryptocurrency wallets, Notes, Telegram data and documents from user folders. Microsoft reports it can replace wallet apps with trojanised versions.
- How it stays: a user-level LaunchAgent disguised as an updater in some variants; in the AMOS variant a LaunchDaemon, created after the password is captured, configured to run at load and stay alive.
- How it leaves: data is archived in a staging folder, sent with an HTTP POST and the staging artefacts deleted.
- What to detect: Terminal or a shell spawned by an installer or user app; sequences of curl, Base64 decoding, decompression,
osascriptanddsclin quick succession; a non-browser process opening browser profile or keychain files; archive creation followed by an outbound POST; a new launch item minutes after any of these.
Keep XProtect updates flowing (Apple checks for them daily by default), and note Microsoft's report that Apple added a Terminal paste-blocking prompt in macOS 26.4 and later. For the credential side, see the Infostealer Threat Guide; the Snowflake breach showed what infostealer-harvested credentials do when MFA is absent.
Detections mapped to ATT&CK v20
Every ID below was checked on attack.mitre.org (v20) in October 2026. The detection strategy IDs are MITRE's.
| Technique | On a Mac | Telemetry and logic (in words) |
|---|---|---|
| T1059.002 AppleScript | Fake password dialogs and data collection through osascript | DET0414: osascript exec whose parent is Terminal, a shell or an unsigned binary, followed by credential file access or dscl exec |
| T1553.001 Gatekeeper Bypass (Defense Impairment) | Quarantine attribute removed or never set; user override | DET0288: deleteextattr on com.apple.quarantine, gatekeeper_user_override events, exec of unsigned or non-notarised binaries from Downloads or mounted volumes |
| T1543.001 Launch Agent | Plist in ~/Library/LaunchAgents or /Library/LaunchAgents with RunAtLoad or KeepAlive | DET0434: btm_launch_item_add plus plist writes; executable in a user-writable or hidden path |
| T1543.004 Launch Daemon | Plist in /Library/LaunchDaemons running as root | DET0401: new daemon not signed by an approved team identifier; daemon names imitating Apple or updaters |
| T1647 Plist File Modification (Defense Impairment) | LSUIElement to hide an app, LSEnvironment to inject environment variables | DET0109: Info.plist changes inside signed app bundles, followed by execution |
| T1548.006 TCC Manipulation | Abusing an app that already holds Full Disk Access, injection, or editing TCC.db when SIP is off | DET0534: writes to TCC databases, tcc_modify grants by unexpected processes, SIP disabled |
| T1555.001 Keychain | Dumping or copying the login keychain | DET0396: the security utility or a non-Apple process opening keychain files, with unusual parentage |
| T1685 Disable or Modify Tools | Security agent unloaded or its system extension removed | Agent heartbeat gaps, system extension state changes, profile_remove of the agent's profile |
Hunting macOS persistence
ATT&CK describes launch agents as plists loaded at login from /System/Library/LaunchAgents, /Library/LaunchAgents and ~/Library/LaunchAgents, with Label, ProgramArguments and RunAtLoad setting name, executable and timing. macOS launch daemons need elevated privileges and run as root, so launch daemon persistence is why stealers ask for the password first. Since macOS 13, Background Task Management registers these items and lists them under System Settings, General, Login Items.
- Baseline the fleet: collect
sfltool dumpbtmoutput or the BTM status report from every Mac and group items by developer team identifier. Most fleets have a few dozen legitimate items. - Approve the known: the Service Management payload auto-approves items by TeamIdentifier, BundleIdentifier, Label or LabelPrefix, so your own agents never prompt and everything else stands out.
- Hunt the outliers: items whose executable sits in
/Users/Shared,/tmp, a hidden directory or the user's Library; items with no team identifier or an ad hoc signature; labels imitatingcom.appleor software updaters; ProgramArguments invoking a shell,osascriptor a script interpreter. - Check what daemons point at: ATT&CK notes adversaries modify executables that existing daemons reference when folders such as
/usr/local/binare world-writable. Hash the targets, not only the plists. - Diff on a schedule: new items between two snapshots, correlated with the ES
btm_launch_item_addinstigator, give you the installing process.
For macOS threat hunting beyond persistence, apply the same baseline-and-outlier method to TCC grants and process trees. The cross-platform catalogue is in the Persistence Techniques Guide, and the hunting method in the Threat Hunting Guide.
TCC manipulation, TCC bypass and the privacy perimeter
TCC grants decide whether code can read mail, messages, browser data and other users' files, capture the screen or control the Mac. ATT&CK T1548.006 describes three routes: running code through an app that already holds Full Disk Access (scripts "inherit those permissions without a prompt"), injecting into such an app, and editing TCC.db when SIP is disabled. Detection points:
- Grant events: alert on
tcc_modifygrants of Full Disk Access, Accessibility or Screen Recording to anything outside your approved list; the event carries the instigating and responsible processes. - Database writes: any process other than the TCC daemon writing to a TCC database is a TCC bypass attempt.
- Inherited access: watch AppleEvents automation of Finder or Terminal by scripts, and child processes of apps that hold Full Disk Access, such as your own management and security agents.
- SIP state: SIP disabled on a managed Mac is both a compliance failure and a prerequisite for direct database tampering; report it from MDM inventory.
MITRE's mitigations include auditing Automation grants, resetting permissions with tccutil reset, and limiting Full Disk Access to binaries that need it. Managing grants with PPPC profiles is covered in the parent guide.
Other macOS malware classes
| Class | Typical entry and persistence | Best early signal |
|---|---|---|
| macOS dropper | Fake installer disk image or pasted command fetching a second stage | Exec from a mounted volume or Downloads followed by curl and a new binary in a user-writable path |
| macOS backdoor | Launch agent or daemon beaconing on an interval, sometimes in a trojanised developer tool | New launch item plus periodic outbound connections from an unsigned process |
| macOS ransomware | Usually after credential theft; encrypts user and network share data | One process renaming and writing many files; FSEvents bursts; deletion of local snapshots |
| Adware and bundleware | Browser extensions, configuration profiles and launch agents | profile_add of unknown profiles, browser setting changes |
The ATT&CK Launch Daemon page lists the 3CX supply chain attack and AppleJeus among its procedure examples, a reminder that signed, trusted software can carry a backdoor. See the Malware Guide for families across platforms.
macOS incident response
Incident response for macOS differs from Windows in two ways: internal storage on modern Macs is encrypted and tied to the hardware, so live logical collection is usually the practical route, and the most valuable loot on a Mac is credentials. A phased approach:
- Contain without powering off: isolate the Mac from the network through your agent or MDM and keep it running and unlocked if possible, because a shutdown leaves FileVault-protected data and in-memory state out of reach.
- Collect: a unified log archive, process and network state, BTM output, launch directories, TCC databases, quarantine history, FSEvents, shell histories, browser profiles and the user's Downloads folder. Hash what you collect and record the time.
- Scope: search fleet telemetry for the same launch item labels, executable hashes, domains and parent-child chains seen on the first Mac.
- Revoke credentials: assume every keychain item, browser session cookie, SSH key and cloud CLI token on the Mac is stolen. Revoke sessions at the identity provider, rotate keys and tokens and review their recent use. The GlassWorm campaign, which ATT&CK lists as collecting keys from
login.keychain-db, shows how stolen developer tokens become the next infection route. See the Leaked Credential Response Playbook. - Eradicate and recover: erase and reinstall rather than cleaning, re-enrol through Automated Device Enrolment, and restore user data only after scanning it.
- Feed back: turn the chain you observed into detections and test them with
esloggerreplays.
Roles, severity and communications follow your Incident Response Guide process.
Decision guidance
- Agent choice: require ES-based telemetry through a system extension, a published list of subscribed event types, AUTH-event blocking for exec, and support for BTM, TCC and XProtect events. Reject agents that need kernel extensions or Reduced Security.
- Small fleets: rely on the agent's built-in detections plus three custom alerts: new launch items outside approved teams, Full Disk Access or Accessibility grants, and Terminal launched by a non-terminal app followed by curl.
- Large or developer-heavy fleets: forward raw ES events for exec, BTM, TCC and authentication to the SIEM, keep 90 days of hunting data, and give developer Macs a stricter baseline because they hold production credentials.
Measurement
- Telemetry coverage: percentage of Macs whose agent reported in the last 24 hours with its system extension active and Full Disk Access present.
- Event completeness: share of required ES event types (exec, BTM, TCC, authentication, XProtect) arriving in the SIEM from each Mac.
- Persistence hygiene: count of launch items not matching an approved team identifier, trending to zero.
- Time to triage: median minutes from a new-launch-item or TCC-grant alert to an analyst decision.
- Credential revocation time: hours from confirmed stealer infection to all sessions and tokens revoked.
Common failure patterns
- Agent installed, events unchosen: the agent runs, but BTM, TCC and authentication events are not collected or not forwarded.
- Trusting Gatekeeper for pasted commands: Gatekeeper never sees a command pasted into Terminal or a file fetched by curl.
- Reimage and move on: the Mac is wiped while the stolen sessions and tokens stay valid.
- Full Disk Access sprawl: many tools hold Full Disk Access, so a compromise of any one inherits it.
- Blocked Apple updates: a proxy blocks XProtect and notarisation updates, silently ageing protection.
Framework mapping
| Framework | Reference | macOS detection and response activity |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring; AU-6 Audit Record Review; IR-4 Incident Handling | ES telemetry to the SIEM, hunting, IR playbook |
| NIST CSF 2.0 | DE.CM-09 computing hardware, software and their data monitored; RS.AN-03 analysis performed | Endpoint monitoring and incident analysis |
| CIS Controls v8.1 | Control 8 Audit Log Management; Control 10 Malware Defenses; Control 17 Incident Response Management | Log collection, XProtect and agent coverage, response process |
| ISO/IEC 27001:2022 | A.8.7 Protection against malware; A.8.16 Monitoring activities; A.5.26 Response to information security incidents | Malware controls, monitoring and response |
Practitioner checklist
- Confirm your macOS agent uses the Endpoint Security framework through a system extension and list the event types it collects.
- Forward exec, BTM, TCC, authentication, XProtect and Gatekeeper override events to the SIEM from every Mac.
- Approve your own launch items by team identifier and alert on every other new launch agent, launch daemon or login item.
- Alert on Full Disk Access, Accessibility and Screen Recording grants outside an approved list and on any write to a TCC database.
- Detect Terminal or shells spawned by installers or user apps followed by curl, decoding,
osascriptordscl. - Write an IR runbook covering live collection, unified log archives, BTM, TCC, quarantine and FSEvents artefacts.
- Revoke every session, token and key from an infected Mac before closing an infostealer incident.
- Track telemetry coverage and unapproved launch items weekly.
Standards and references
- Apple Developer: Endpoint Security
- Apple Platform Security: Protecting against malware in macOS
- Apple Platform Deployment: Manage login items and background tasks on Mac
- Apple Platform Deployment: System and kernel extensions in macOS
- Apple Developer: Logging (unified logging)
- MITRE ATT&CK: T1548.006 TCC Manipulation
- MITRE ATT&CK: T1543.004 Launch Daemon
- Microsoft Security Blog: ClickFix campaign uses fake macOS utilities lures to deliver infostealers
Related NHI Mgmt Group resources: macOS Security Guide for Enterprises · Threat Hunting Guide · Infostealer Threat Guide · Digital Forensics (DFIR) Guide · Persistence Techniques Guide