Safeguard
Application Security•

Detecting and Mitigating Launch Daemon Abuse (T1543.004)

Launch Daemons run as root before anyone logs in on macOS. See how adversaries abuse them for persistence and what to watch and lock down.

Safeguard Security Team
2 min read

Launch Daemon abuse (MITRE ATT&CK T1543.004) is a persistence and privilege escalation technique on macOS. Launch Daemons are property list (plist) files that tell launchd, the macOS service manager, what to run in the background.

They matter to defenders because of where they sit. They need elevated privileges to install, they run for every user before login, and they need no user interaction.

How attackers use it

At startup, launchd loads system-level daemons from plist files in /System/Library/LaunchDaemons/ and /Library/LaunchDaemons/. A plist needs a Label, a Program path to the executable and RunAtLoad to say when it runs.

MITRE describes an adversary installing a daemon with RunAtLoad set to true and Program pointing at a malicious executable. The daemon name may copy one from the operating system or a benign product, which is Masquerading (T1036). When it runs, the program inherits administrative permissions.

There is a second route that needs no new plist. MITRE notes that some changes, such as installing third-party package management software, can leave folders like usr/local/bin globally writeable. A poorly configured system may then let an adversary edit an executable that an existing daemon plist already references.

How to detect it

MITRE's detection strategy centers on file and process telemetry:

  • Creation or modification of .plist files in /Library/LaunchDaemons/, especially with unusual Program or ProgramArguments paths.
  • Execution under launchd with elevated privileges that follows such a change.
  • Correlation across Unified Logs, file monitoring and process telemetry.

A new daemon that appears outside a software install or an approved change is worth a look. So is a daemon whose binary lives in a user-writable path.

How to reduce the risk

  1. Limit who can create daemons. Reduce user privileges and fix privilege escalation paths so only authorized administrators can add Launch Daemons.
  2. Audit folder permissions. Use tools that find folder permission problems, and review the changes third-party software makes to folders.

Quick check

Name one way an adversary can abuse Launch Daemons without adding a new plist.

By modifying an executable that an existing daemon plist references, which becomes possible when a folder such as usr/local/bin has been made globally writeable.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.