System Services: Abuse of Services and Daemons (T1569)

Services are programs that the operating system starts and manages for you. That makes them a convenient place to run something you do not want noticed. MITRE T1569, System Services, covers abusing services or daemons to execute commands or programs. It sits under the execution tactic and applies to Windows, macOS and Linux.

How attackers use it

Adversaries can run malicious content by interacting with or creating services, either locally or remotely. Many services are set to run at boot, which can help with persistence through Create or Modify System Process. MITRE notes that services can also be used for one-time or temporary execution, which means that checking only your boot-time services will miss some of it.

Three subtechniques cover the main platforms, and each has its own guide in this series: Launchctl on macOS (T1569.001), Service Execution on Windows (T1569.002) and Systemctl on Linux (T1569.003).

How to detect it

MITRE gives platform analytics that share one idea: compare what the service manager is asked to run with what you expect to run.

• Windows: abnormal creation or modification of services, whether through sc.exe, PowerShell or API calls, that load non-standard executables. Correlate registry changes in service keys with service creation events and the process that runs next.
• Linux: unusual invocations of systemctl, service or init scripts that create or modify daemons. Watch audit logs for binaries run from unexpected paths linked to service start and stop activity.
• macOS: changes to launchd service definitions and property list files that point at non-standard executables, and processes registered as launch daemons or agents without authorization.

Three questions are useful for any service hit:

1. Who created it, and from where?
2. Where does the executable live?
3. Did it run once, or is it configured to come back?

How to reduce the risk

MITRE lists four mitigations.

1. Privileged Account Management. Make sure permissions do not allow services that run at a higher permission level to be created or interacted with by a lower-privileged user.
2. User Account Management. Prevent users from installing their own launch agents or launch daemons.
3. Behavior Prevention on Endpoint. On Windows 10, enable Attack Surface Reduction rules to block processes created by PsExec from running.
4. Restrict File and Directory Permissions. Make sure the binaries of high-privilege services cannot be replaced or modified by lower-privileged users.

The fourth one is easy to forget. A perfectly configured service that points at a binary anyone can overwrite is an open door.

Check your own environment

Read-only commands by OS.

Windows (PowerShell):

Get-CimInstance Win32_Service | Select-Object Name,State,StartMode,StartName,PathName

Linux:

systemctl list-unit-files --state=enabled
systemctl list-units --type=service --state=running

macOS:

launchctl list
ls -la /Library/LaunchDaemons /Library/LaunchAgents

Then look at each result for:

• Executable paths in temporary or user-writable folders.
• Services running as a highly privileged account that you cannot match to software you installed.
• Service binaries or unit files that non-administrators can modify.

Baselining services

The cleanest way to make this technique stand out is a baseline. Capture the service list from a gold image, store it, and compare each host against it on a schedule. New entries are not always malicious, but they are always worth a question, and on servers the number of legitimate changes is small.

Remote execution

MITRE mentions that services can be created locally or remotely. Remote service creation shows up as authentication events on the target, then a service installation, then a process start. If you log all three, you can join them into a single alert: a network logon followed by a new service within seconds.

Quick check

Sources

• MITRE ATT&CK T1569, System Services