launchd is macOS and Darwin’s service management daemon that starts processes at boot, on login, or on demand. It is often abused for persistence through launch agents and daemons, so defenders should review installed plist files, check for unexpected jobs, and validate the signing and ownership of launch items.
What launchd does in macOS and Darwin
launchd is the core service manager for macOS and Darwin. It controls when background jobs start, whether they run at boot, at login, or only when triggered, and it acts as the coordination point for many persistent system and user-level processes.
Because it sits at the centre of startup and service execution, launchd is not just a convenience layer. It is part of the operating system’s trusted execution path, which means changes to its jobs can shape what runs automatically and when.
How launchd jobs are defined and invoked
launchd jobs are typically described in property list files, commonly called plist files, that declare what should run, under which user context, and on what trigger. Those definitions can be installed as launch agents or launch daemons depending on whether they should follow a user session or operate system-wide.
The practical distinction matters because a job that is valid for one context may be noisy or suspicious in another. A benign support tool, updater, or monitoring component can appear in either form, but defenders should expect its plist metadata, location, ownership, and signing characteristics to match its purpose.
For a concise map of the persistence patterns that attackers often try to blend into startup behaviour, see Persistence Techniques Guide.
Why launchd is attractive for persistence
launchd is a common persistence target because it provides reliable automatic execution without needing an interactive session. If an attacker can place or modify a launch item, the system may relaunch that code after reboot, after login, or when a specific condition is met.
This makes launchd persistence valuable for both noisy malware and quieter, longer-lived footholds. The risk is not only that malicious code starts again, but that it may do so in a way that blends with normal administration, software updates, and background services.
On macOS, the defender’s challenge is to distinguish expected automation from abused automation. That usually requires reviewing installed plist files, checking for unexpected jobs, and validating both signing and ownership of launch items against the host’s normal software set.
What defenders should verify and monitor
launchd review is most effective when it is tied to a known-good baseline for the device or fleet. Unexpected jobs, unusual paths, weak file permissions, or unsigned components are stronger signals when they do not align with approved software, managed configuration, or documented operational tooling.
Detection should focus on both the job definition and the executable it launches. A clean plist does not guarantee a clean payload, and a familiar binary name does not guarantee a trusted file if its location, signer, or owner is inconsistent with the rest of the system.
That review logic aligns with broader host-persistence detection work described in MITRE ATT&CK Enterprise Matrix, which helps defenders map startup and logon persistence to known adversary techniques.
Risk and Threat Considerations
launchd is high-value to attackers because it can turn a one-time compromise into durable execution. If a malicious launch agent or daemon is added, the host may keep reintroducing the attacker’s code even after the original process is closed.
Failure mechanism: Abuse usually succeeds when job files, executable paths, or ownership checks are weak enough that a persistence entry is accepted as legitimate startup automation.
Impact: The result can be recurring code execution, stealthier re-entry after reboot or login, and a longer window for credential theft, lateral movement, or further host compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | launchd jobs create boot and logon persistence on macOS |
| Recommendation — Map launchd jobs to T1547 and hunt for unexpected autostart entries. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | launchd abuse is often enabled by weak host configuration and unsafe autostart items |
| Recommendation — Harden macOS startup items and validate authorized launch agents and daemons. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | unneeded launchd jobs expand the executable surface on a host |
| CM-6 — Configuration Settings | launchd plist ownership, signing, and job settings are configuration controls | |
| AU-6 — Audit Review, Analysis, and Reporting | job creation and modification events should be reviewed for persistence abuse | |
| Recommendation — Disable unnecessary launch items and permit only required background services. Enforce approved launchd configuration settings and baseline expected plist attributes. Review launchd job changes and alert on unauthorized persistence additions. | ||
Practitioner Guidance
What to watch for: Treat newly introduced launch items, unexpected plist changes, and mismatches between a job’s declared purpose and its signer or owner as investigation triggers. The most useful review question is whether the host would still make sense if that launch item were removed.
Practitioner takeaway: launchd review is strongest when you compare every autostart entry against a known software baseline, not just against the current process list.