Service Execution on Windows: Detecting It (T1569.002)

The Windows service control manager is a normal part of administration, which is why abusing it hides well. MITRE T1569.002, Service Execution, covers using it to run malicious commands or payloads. It is an execution technique and applies to Windows.

How attackers use it

The service control manager is services.exe. People reach it through GUI components and tools such as sc.exe and Net. MITRE says PsExec can also execute commands or payloads through a temporary Windows service created via the service control manager API. Both PsExec and sc.exe accept remote servers as arguments, so they can be used for remote execution.

Adversaries may execute either a new service or a modified one. MITRE notes this technique is the execution half used together with Windows Service during service persistence or privilege escalation.

How to detect it

MITRE's detection strategy looks for abnormal service executions started through service control manager APIs, sc.exe, net.exe or PsExec creating temporary services. Specific signals it names:

• services.exe spawning non-standard binaries.
• Registry changes in service keys followed by rapid execution.
• Network connections from processes tied to transient services.
• Correlation across process lineage, registry activity and service logs, which MITRE calls a strong signal.

The log sources to enable are well known:

• System event ID 7045, a service was installed on the system.
• Security event ID 4697, a service was installed, which needs the relevant audit policy.
• Process creation, such as Sysmon Event ID 1 or Security Event ID 4688 with command line logging, so you can see sc.exe arguments and the child processes of services.exe.
• Logon events on the target host, to see where remote service creation came from.

A service that is created, started and deleted within seconds is a classic shape for temporary execution.

How to reduce the risk

MITRE lists three mitigations.

1. Privileged Account Management. Make sure that services with higher permissions cannot be created or interacted with by lower-privileged users.
2. Behavior Prevention on Endpoint. On Windows 10, turn on Attack Surface Reduction rules that block processes created by PsExec from running.
3. Restrict File and Directory Permissions. Make sure high-permission service binaries cannot be replaced or modified by lower-privileged users.

Add a network side as well. Remote service creation travels over the administrative interfaces of the target host, so limiting which systems can reach those interfaces limits where this can be done from. Ordinary workstations rarely need to start services on each other.

Check your own environment

A read-only look at installed services, with the account and the binary path:

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

And recent service installs from the System log:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 50

Check these points:

• Do any service paths point to temporary or user profile folders?
• Do any services run as an account you cannot explain?
• Are install events collected centrally from all servers and workstations?
• Which admin tools legitimately use PsExec-style execution in your team, and from which jump hosts?

Handling a hit

When a suspicious service appears, find the process that created it and the logon session behind that process. If the session was a network logon, trace it back to the source host, because that host is probably compromised too. Preserve the service binary and the registry key before cleanup. After that, check whether the same binary or service name exists on other hosts.

Reducing noise

Service creation is common during software installs and patching. To keep alerts useful, tie them to change windows and known installers. Anything outside a change window, from a non-admin account or pointing to a user-writable path, is worth a look.

Quick check

Sources

• MITRE ATT&CK T1569.002, Service Execution