Services Registry Permissions Weakness (T1574.011) Guide

Services Registry Permissions Weakness (T1574.011) is a Windows technique in the stealth and execution tactics. The adversary hijacks the Registry entries that services use.

How attackers use it

Windows stores local service configuration in the Registry under HKLM\SYSTEM\CurrentControlSet\Services. The settings can be changed with tools such as the service controller (sc.exe), PowerShell or Reg. Access is controlled by ACLs and user permissions.

If those permissions are too loose, an adversary can change a service's binPath or ImagePath to point at an executable they control. When the service starts or restarts, that program runs in the account the service uses: a local or domain account, SYSTEM, LocalService or NetworkService. The result can be persistence, privilege escalation or both.

MITRE notes other keys in the service tree can be altered. The FailureCommand key can be changed so the service runs in an elevated context whenever it fails or is deliberately broken. The Performance key names a driver service's performance DLL and exported functions, which is another place a redirect can hide.

How to detect it

MITRE's analytic focuses on unauthorized changes to service-related Registry keys, naming ImagePath, FailureCommand, ServiceDll and Performance or Parameters keys. Correlate Registry modifications, odd changes to service metadata, and later service process executions that differ from the baseline.

Change auditing on the Services hive is the foundation. A baseline of ImagePath values per host lets you diff quickly.

How to reduce the risk

MITRE lists one mitigation: restrict Registry permissions. Make sure Registry hives are set so users cannot modify keys for system components, which could lead to privilege escalation. Back this with the least privilege rules for administrators.

Check your own environment

# Windows cmd: show the configuration of one service (replace the name)
sc.exe qc ExampleService

# Windows PowerShell: who can change a service's Registry key (replace the name)
(Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\ExampleService").Access |
  Select-Object IdentityReference,RegistryRights,AccessControlType

• Does any non-administrative group hold write or full control on a service key?
• Do you log Registry changes under the Services hive?
• Do you keep a baseline of ImagePath, FailureCommand and ServiceDll values?

Quick check

Sources

• MITRE ATT&CK T1574.011: Services Registry Permissions Weakness