Launchctl Persistence

Expanded Definition

Launchctl persistence refers to abuse of macOS launch services and the launchctl interface to keep a process available after login or reboot. In legitimate administration, launch agents and launch daemons are used for approved background tasks. In security operations, the same mechanism becomes a persistence primitive when an adversary registers a payload to run under the current user context or at system start.

Definitions are stable at a high level, but implementation details vary across macOS versions and between LaunchAgents, LaunchDaemons, and per-user login items. That distinction matters because the execution context changes what the code can reach and how defenders should validate it. NIST control guidance on configuration management and least privilege is relevant here, especially where persistence entries are added outside normal software deployment workflows, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The most common misapplication is treating every launch item as benign system behaviour, which occurs when responders do not distinguish vendor-signed daemons from newly created labels pointing to user-writable or masqueraded paths.

Examples and Use Cases

Implementing detection for launchctl persistence rigorously often introduces endpoint inventory and macOS telemetry overhead, requiring organisations to weigh stronger coverage against the cost of collecting and normalising file, process, and login item data.

• A threat actor drops a plist in a user’s ~/Library/LaunchAgents directory so a loader starts at each login.
• An attacker registers a daemon with a label that resembles a legitimate Apple or enterprise service name to avoid obvious scrutiny.
• Security teams inspect unsigned or recently modified launch items that reference binaries in temporary, hidden, or otherwise unexpected directories.
• Incident responders compare active launch entries against approved software baselines and deployment records to separate sanctioned automation from persistence.
• Defenders correlate launchctl changes with other macOS persistence techniques, such as login items and cron-like scheduling, to identify layered tradecraft described in Apple’s platform guidance and aligned with monitoring principles in MITRE ATT&CK.

Why It Matters for Security Teams

Launchctl persistence is important because it turns a single execution event into repeated access, which changes an investigation from containment of one process to removal of a foothold that automatically reappears. On macOS fleets, that means endpoint teams need reliable visibility into who created the launch item, what binary it points to, and whether the file path and signing state match the expected software estate.

This term also matters for identity-adjacent security work. A persistence item running under the current user context can inherit that user’s access to files, browsers, cloud sessions, and secrets stored locally, so weak session hygiene can magnify the impact of a compromise. In environments that rely on privileged tooling for macOS administration, review and change control should be strong enough to distinguish legitimate automation from attacker-installed services, consistent with guidance from CISA on reducing exposure to actively exploited weaknesses and from platform hardening practices in Apple Platform Security.

Organisations typically encounter the true operational cost only after malware survives a reboot or re-login, at which point launchctl persistence becomes operationally unavoidable to remove.

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?