Detecting and Mitigating Malicious Windows Services (T1543.003)

Windows Service abuse (MITRE ATT&CK T1543.003) is a persistence and privilege escalation technique. Windows starts services at boot to do background work, and their configuration, including the path to the service executable or recovery commands, is stored in the registry.

It is one of the most common places for persistence to hide on Windows, and it is also easy to inspect if you know what to log.

How attackers use it

MITRE explains that adversaries may install a new service or change an existing one so it runs at startup. Service configuration can be set through system utilities such as sc.exe, by editing the registry directly or by calling the Windows API.

Services also give access to drivers. After a driver file (.sys) is placed on disk, it can be loaded and registered through Native API functions such as CreateServiceW(), or by hand through functions such as ZwLoadDriver() and ZwSetValueKey(), by creating the needed service registry values, or by command line utilities such as PnPUtil.exe. MITRE notes adversaries may use drivers as rootkits to hide activity. They may also load a signed but vulnerable driver, known as Bring Your Own Vulnerable Driver (BYOVD), as part of exploitation for privilege escalation.

Privilege is built in. Services can be created with administrator privileges but run as SYSTEM, so a service can be used to escalate. Adversaries may also start services directly through Service Execution.

To make analysis harder, MITRE describes two more habits:

• Masquerading, for example giving a service or its payload a name related to a legitimate operating system or benign software component.
• Hidden services, created by using the sc sdset command to set service permissions through the Service Descriptor Definition Language (SDDL). That can hide a service from standard enumeration such as Get-Service, sc query and services.exe.

How to detect it

MITRE's strategy for Windows joins several data points:

• Creation or modification of services through command line tools such as sc.exe and powershell.exe.
• Registry changes under HKLM\System\CurrentControlSet\Services.
• Services running as SYSTEM with unsigned or unusual binary paths.
• Driver installation and use of CreateServiceW.
• Parent and child process lineage, startup behavior and rare service names.

Useful event sources include the System log event 7045 (a service was installed) and Security event 4697 (a service was installed on the system), and Sysmon event IDs 1 (process creation), 12 and 13 (registry) and 6 (driver loaded). Treat a rare service name that appears on a single host with extra suspicion, since fleet wide software tends to appear on many.

The hidden service trick means a clean listing is not proof. Compare the registry view under the Services key with the output of the standard tools.

How to reduce the risk

MITRE lists five mitigations:

1. Block vulnerable drivers. On Windows 10, enable Attack Surface Reduction rules that stop an application from writing a signed vulnerable driver. On Windows 10 and 11, enable the Microsoft Vulnerable Driver Blocklist.
2. Enforce driver signing. Keep Driver Signature Enforcement turned on to restrict unsigned drivers.
3. Audit. Use tools that find privilege and service abuse opportunities, then correct them.
4. Use code signing. Only allow registration and execution of legitimately signed service drivers where possible.
5. Limit account privileges. Only authorized administrators should be able to change services and their configuration.

Check your own environment

Read-only commands in PowerShell and the command prompt:

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

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

reg query HKLM\System\CurrentControlSet\Services /s /v ImagePath

Then work through a checklist:

1. Which services have a path outside C:\Windows or C:\Program Files?
2. Which services run as SYSTEM but are not from a vendor you know?
3. Are there services installed recently on only one machine?
4. Do names copy Windows components but point to a different folder?
5. Is the vulnerable driver blocklist on across your fleet?

Quick check

Sources

• MITRE ATT&CK T1543.003, Create or Modify System Process: Windows Service