macOS Launch Daemons are background services started by launchd at system boot or when the system is running, usually without a logged-in user. They are defined by property list files in system locations and are used for machine-wide tasks such as networking, updates and scheduled jobs.
What macOS Launch Daemons do
macOS Launch Daemons are system-level background jobs that launchd starts for the whole machine, not for a single logged-in user. They support boot-time and always-on tasks such as networking, update workflows, and scheduled maintenance.
Because they run outside an interactive session, launch daemons are a core part of macOS service management, but they also sit on a sensitive trust boundary: a daemon can influence system behaviour even when no user is present.
How launch daemons are defined and loaded
Launch daemons are typically described by property list files in system locations, where launchd reads metadata about what to start, when to start it, and under what conditions it should remain active. That makes the plist both configuration and control surface.
Operationally, this model gives macOS a consistent way to manage background services without relying on ad hoc scripts or manual startup tasks. It also means that file placement, ownership, and permissions matter because they help determine which jobs the system will trust and execute.
Why launch daemons matter for security
System daemons are attractive to attackers because persistence at the machine level can survive logoff, and in many cases reboot. If an adversary can add, alter, or abuse a daemon definition, they may gain repeated execution, hidden persistence, or a reliable way to re-establish control.
They also broaden the impact of compromise. A malicious or misconfigured daemon can run with elevated reach over networking, telemetry, software update paths, or local services, so the consequences are often wider than a single user account.
Common abuse patterns and defensive visibility
On macOS, launch daemons are often discussed alongside persistence tradecraft because they map closely to system service abuse. NHIMG’s macOS Detection and Response Guide covers related telemetry and response topics such as launch daemon persistence, unified logging, and macOS threat hunting.
That is why defenders often look for unexpected plist creation, suspicious ownership or path changes, and daemon behaviour that does not match an approved service inventory. The most important question is usually not whether launchd is involved, but whether the daemon is expected, authorised, and observable.
For a broader persistence context, NHIMG’s Persistence Techniques Guide is useful because launch daemons are one of the standard ways attackers maintain execution across reboots.
Risk and Threat Considerations
Launch daemons create machine-wide persistence and execution opportunity, so compromise of a daemon definition can outlast a user session and blend into normal boot-time activity. The risk is highest when defenders do not have a clean inventory of approved daemons or when filesystem protections are weak.
Failure mechanism: An attacker or misconfiguration changes a plist, introduces a new daemon, or points an approved daemon at malicious code, then relies on launchd to execute it at boot or during normal operation.
Impact: The result can be stealthy persistence, repeated code execution, privilege misuse, service disruption, or long-lived control of macOS endpoints.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1543.004 — Launch Daemon | Launch daemons are a direct macOS persistence mechanism in ATT&CK. |
| Recommendation — Monitor launch daemon creation and modification for persistence activity. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricts unnecessary background services and reduces daemon abuse surface. |
| AU-6 — Audit Review, Analysis, and Reporting | Daemon changes and execution are audit-worthy events for detection and review. | |
| Recommendation — Remove unneeded daemons and disable nonessential startup services. Review daemon-related logs for unexpected service creation or execution. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Launch daemons depend on secure system configuration and controlled startup settings. |
| CIS-13 — Network Monitoring and Defense | Daemon-driven network activity can reveal malicious service behaviour and persistence. | |
| Recommendation — Harden startup locations and enforce approved configuration baselines. Inspect unexpected daemon network activity for signs of compromise. | ||
Practitioner Guidance
Why practitioners should care: Treat launch daemons as part of endpoint hardening, not just application operations. Every approved daemon should have an owner, a documented purpose, and a known expected path so that unexpected changes stand out quickly.
What to watch for: Pay close attention to daemon definitions in system locations, especially newly created or modified plist files, unexpected binaries referenced by a daemon, and services that appear after a security incident or software install.
Practitioner takeaway: The practical control is not only to stop malicious daemons, but to keep the approved daemon set small, visible, and continuously reviewable.
Related resources from NHI Mgmt Group
- What breaks when macOS persistence is implemented through a Launch Agent that runs decoded scripts on a schedule?
- How should security teams detect macOS spyware that uses launch agents and other persistence tricks?
- How do you detect launch agent or launch daemon persistence on macOS?
- What should teams do after a macOS installer is found to launch a privileged payload?