Detecting and Mitigating System Process Persistence (T1543)

Create or Modify System Process (MITRE ATT&CK T1543) is a persistence and privilege escalation technique that covers Windows, Linux, macOS and containers. It is the parent of four well known sub-techniques plus Container Service, and it describes a simple idea: if something starts every time the machine does, a malicious program can ride along.

Defenders get two things from understanding the parent technique. First, a shared model for what to watch on every platform. Second, a reminder that the privilege jump is part of the design, because these mechanisms often run with more rights than the person who set them up.

How attackers use it

When an operating system boots, it starts processes that do background work. On Windows and Linux these are called services. On macOS, launchd runs Launch Daemons and Launch Agents to finish system initialization and load user specific parameters.

MITRE describes two moves. An adversary can install a new service, daemon or agent configured to run at startup or at a repeating interval. Or the adversary can modify an existing one. Either way, the payload runs again and again.

The escalation angle is the second half of the technique. Services, daemons and agents may be created with administrator privileges but run as root or SYSTEM. An adversary who can create one may therefore run code with far more power than the account used to create it.

The sub-techniques cover each platform:

• Launch Agent (T1543.001), macOS, per-user.
• Systemd Service (T1543.002), Linux.
• Windows Service (T1543.003), Windows.
• Launch Daemon (T1543.004), macOS, system-wide.
• Container Service (T1543.005), container hosts and clusters.

How to detect it

MITRE's detection strategy for the parent gives one analytic per platform. Reading them side by side shows the pattern.

Windows. Look for command line or API creation and modification of services through sc.exe, powershell.exe, services.exe or the ChangeServiceConfig function. Watch for autostart services created through registry changes, files dropped into System32\services and odd parent and child process trees.

Linux. Watch for new or edited systemd service units, cron jobs that run binaries at boot and suspicious writes to /etc/init.d/. Pay attention to chmod +x and systemctl execution paths, especially from non-root parent processes.

macOS. Watch for creation or modification of LaunchDaemon or LaunchAgent plist files under /Library/LaunchDaemons/ and ~/Library/LaunchAgents/, plus execution of launchctl, property list edits and permission changes.

Containers. Watch for new container processes started with a restart policy, kubectl exec into init containers, and changes to container init specs. Flag images that override entrypoints to embed persistence.

The common thread is a configuration write followed by an execution that does not match a change record. If you can tie service and unit changes to tickets or deployments, whatever remains unexplained is your alert list.

How to reduce the risk

MITRE lists five mitigations. In plain steps:

1. Limit account privileges. Only authorized administrators should be able to touch system level process changes and service configuration.
2. Block risky drivers on Windows. On Windows 10, enable Attack Surface Reduction rules that prevent an application from writing a signed vulnerable driver. On Windows 10 and 11, enable the Microsoft Vulnerable Driver Blocklist.
3. Enforce driver signing. Make sure Driver Signature Enforcement is enabled so unsigned drivers cannot be installed.
4. Limit software installation. Allow installs only from trusted repositories, and be careful with orphaned software packages.
5. Manage privileged accounts. Control how SYSTEM, root and other privileged accounts are created, changed, used and permissioned.

Check your own environment

Read-only commands, by platform:

# Windows (PowerShell): services and who they run as
Get-CimInstance Win32_Service | Select-Object Name, StartName, StartMode, PathName

# Linux: enabled units and recently changed unit files
systemctl list-unit-files --state=enabled
find /etc/systemd/system /usr/lib/systemd/system -name '*.service' -mtime -7

# macOS: agent and daemon folders
ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents

# Docker host: restart policies
docker inspect --format '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' $(docker ps -aq)

Work through the results with a short checklist:

• Does each entry have an owner and a change record?
• Does the binary path sit in an expected, protected folder?
• Is the account it runs as the lowest that works?
• Is any name a near copy of an operating system component?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1543, Create or Modify System Process