Launchd persistence is a macOS technique where malicious software configures launchd to start automatically after login or reboot. Attackers use launch agents, launch daemons, or job plist files to maintain execution, survive removal attempts, and regain control of a host through a trusted system service.
What launchd persistence means on macOS
Launchd persistence is dangerous because it turns a normal startup mechanism into a durable foothold. By registering a job with launchd, malicious code can return after reboot or user logon without needing a separate dropper or manual restart.
This matters because launchd is a trusted part of macOS startup and service management. A persistence entry can blend in with legitimate software support tasks, especially when the attacker uses a launch agent for a user context or a launch daemon for system-level execution.
How launchd persistence works
In practice, persistence is usually achieved with a property list, or plist, that tells launchd what to run, when to run it, and under which account. The payload may live in a standard LaunchAgents or LaunchDaemons location, or the job may be inserted through a compromised configuration path that launchd reads at startup.
These jobs can start at login, on boot, on a schedule, or when a condition is met. Because launchd manages services for the whole platform, attackers often prefer it over noisier startup methods that are easier to spot in application folders or shell profiles.
Why attackers use it
Launchd persistence supports long-lived access, especially after an initial compromise. If defenders remove the visible malware binary but miss the launchd job, the system can re-execute the payload, restore remote access, or reload a second-stage component.
It is also operationally useful for the attacker because it lowers the effort needed to survive cleanup. The technique works well for stealthy post-compromise activity, including maintaining command access, re-establishing control after reboot, and creating a dependable path for follow-on tooling.
For a broader view of the same problem across persistence mechanism, Persistence Techniques Guide covers common startup and logon methods that defenders should recognize.
Detection and removal considerations
Detection usually starts with comparing live launchd jobs against expected software inventory and known-good startup entries. Suspicious plists, unfamiliar labels, unexpected binaries, and jobs that point to unusual paths are all strong review candidates, especially when they reappear after reboot.
Removal is not complete until the job definition, the referenced binary, and any supporting launchd artifacts are removed and verified. If the host was already compromised, responders should treat the persistence entry as evidence of broader intrusion rather than a standalone misconfiguration.
For identity-related follow-through after compromise, Identity Threat Detection and Response (ITDR) Guide is useful when attackers may have paired persistence with stolen credentials, tokens, or session abuse.
When persistence is part of a wider intrusion chain, Salt Typhoon telecom intrusions 2025 is a useful reference point for understanding how access abuse and long-term footholds reinforce one another.
Where it fits in a defensive macOS strategy
Launchd persistence should be treated as a lifecycle problem, not just a malware artifact. Hardening matters, but so do asset visibility, change control, and periodic review of startup locations that macOS automatically trusts.
Defenders get the best results when persistence hunting is tied to endpoint telemetry, file integrity review, and post-incident validation. A clean scan is not enough if the system still contains a job that will relaunch the payload on the next boot or login.
Launchd-specific review is strongest when it is paired with broader startup and service hunting. The same investigation mindset used for other persistence methods also helps uncover disguised jobs, renamed payloads, and reruns that appear only after a reboot.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1543.004 — Launch Daemon | Launchd persistence is a macOS service-persistence technique mapped to launch daemons and agents. |
| Recommendation — Hunt for and remove launchd-based persistence, then validate that the service no longer restarts on login or reboot. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricting unnecessary startup services and jobs reduces persistence opportunities on endpoints. |
| SI-4 — System Monitoring | Continuous monitoring is needed to detect unexpected launchd jobs and reappearing persistence artifacts. | |
| Recommendation — Disable or remove nonessential startup items and service jobs to reduce persistence paths. Monitor startup locations and service changes for unauthorized launchd jobs. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Baselines should control approved startup services and macOS persistence locations. |
| Recommendation — Enforce hardened macOS startup baselines and review deviations from approved service configuration. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Launchd persistence is commonly found through monitoring for unexpected service behavior and recurrence. |
| Recommendation — Watch for unexpected startup behavior and recurring execution after reboot. | ||
Related resources from NHI Mgmt Group
- When does malware persistence become an NHI governance issue?
- How do security teams know if persistence has been established on a compromised AI node?
- How should security teams prevent unwanted persistence in Active Directory and Entra ID?
- Why do stale accounts and old privilege create such a large persistence risk?