Join our Newsletter — 33% off our NHI Course

How do you detect launch agent or launch daemon persistence on macOS?

Detect it by monitoring creation or modification of LaunchAgent and LaunchDaemon property list files and the processes that write them. Review the executable paths they reference, their load timing, and whether they run as a user or at system startup. Suspicious persistence often uses unfamiliar names, writable locations, or scripts that reconnect after reboot.

macOS launch agent and launch daemon persistence is easiest to catch when you treat the plist as both a filesystem artifact and an execution control. Look for new or changed files under the standard launchd locations, then confirm whether the referenced binary, script, or wrapper is legitimate, whether the timing matches user logon or system boot, and whether the job name, path, or execution context looks abnormal.

The highest-signal detections come from correlating file writes with process activity. A benign installer may create a launch item during setup, but persistence usually shows a non-interactive process creating or editing a plist, followed by execution from a path that is writable, hidden, or inconsistent with the software name. That is where macOS Detection and Response Guide is useful because it ties LaunchAgent and LaunchDaemon hunting to the surrounding telemetry you need to validate whether the job is expected or malicious.

Look for persistence tradecraft that blends into normal macOS administration: unusual labels, jobs that restart after reboot, scripts embedded in shell wrappers, and launch items that point into user-writable or temporary locations. Attackers often prefer launchd because it offers reliable startup execution without needing an obvious login item, and because a single plist can survive across reboots and user sessions. The broader pattern is the same one covered in Persistence Techniques Guide, where startup execution is treated as a repeatable technique rather than a one-off file artifact.

For defenders, the practical question is not just whether a plist exists, but whether the launch path, owner, and execution target make sense for the host role. Daemons should usually map to system-level needs, while agents should align to a specific user or application workflow. If a job claims to support a trusted app but launches a script from an unexpected location, or if the load timing suggests automatic recovery after failure rather than normal startup behavior, treat it as a persistence candidate and investigate the parent process, surrounding install activity, and any companion binaries or scripts.

Risk and Threat Considerations

Launchd persistence is attractive because it survives reboots and can be made to look like routine software behavior. The main risk is not the plist itself, but the durable execution path it creates: once an attacker plants a launch agent or daemon, they can regain code execution, reestablish command and control, or keep a foothold alive after partial cleanup.

Failure mechanism: An attacker writes or alters a launch plist, points it to a malicious or staged executable, and relies on macOS to invoke it at login or startup. If defenders only search for obvious malware names, they miss jobs that use legitimate-looking labels, writable locations, or helper scripts.

Impact: The host can continue to execute attacker-controlled code after reboot, which turns a single compromise into persistent access. That persistence also increases the chance of credential theft, lateral movement, and repeated reinfection until the launch item and its payload are both removed.

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 sets the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1543.001 — Create or Modify System Process: Launch Agent LaunchAgent persistence is the core macOS startup mechanism in this question.
T1543.004 — Create or Modify System Process: Launch Daemon LaunchDaemon persistence maps directly to macOS system startup execution.
Recommendation — Hunt for launch agent creation and modification, then validate the startup path and payload. Monitor launch daemon writes and startup execution for unauthorized persistence.
CIS Controls v8 CIS-8 — Audit Log Management Detecting persistence depends on correlating plist changes with process and startup telemetry.
Recommendation — Centralise and review endpoint logs that show who created or modified launchd items.

Practitioner Guidance

What to verify: Confirm the launch item’s creation time, parent process, owner, and target path before you trust it. A plist written by an installer, MDM action, or known management tool is a different case from one written by a browser, archive utility, script interpreter, or other user-space process that has no obvious reason to establish startup execution.

Decision rule: If the launch entry points to a writable path, an unfamiliar script, or a binary outside the application bundle or system path you expect, treat it as suspicious until proven otherwise. If you cannot quickly justify why the job exists, remove the persistence mechanism, preserve the plist and payload for analysis, and check for related login items, helper processes, and other startup artifacts.

What good looks like: Mature detection combines file integrity monitoring, process telemetry, and startup inventory so you can see both the persistence object and the process that created it. The goal is not merely to enumerate launchd items, but to distinguish sanctioned startup behavior from durable attacker execution.

Practitioner takeaway: Persistence detection on macOS becomes reliable when you validate the launch item’s origin and execution context, not just the presence of a plist file.