Skip to content

Back to the catalog

0xv1n.github.iowriteup

PrivEsc: Abusing the Service Control Manager for Stealthy & Persistent LPE

Walkthrough of a Windows privilege escalation and persistence technique credited to Grzegorz Tworek: from a compromised admin account, running `sc.exe sdset scmanager D:(A;;KA;;;WD)` grants the Everyone group full control over the Service Control Manager, letting any non-privileged user create a SYSTEM-context service (e.g. one that adds their account to local Administrators) that persists across reboots even if admin rights or the service are later removed. The post breaks down the SDDL security-descriptor syntax used in the command and provides a Sigma rule to detect the sdset DACL modification via process-creation logs.

TL;DR Abusing `sc sdset scmanager D:(A;;KA;;;WD)` to grant Everyone control of the Windows Service Control Manager for stealthy SYSTEM-level LPE and persistence, with an included Sigma detection rule.
Open original ↗
Document

What it is

A concrete persistence-plus-LPE technique for Windows, credited to Grzegorz Tworek (@0gtweet) and documented by Gabriel De Jesus (0xv1n). From an already-compromised elevated account, an admin modifies the ACL of the Service Control Manager itself (the scmanager pseudo-service) so that any non-privileged user can create services. Because SCM runs as SYSTEM, any unprivileged user can then create a service that executes arbitrary commands as SYSTEM. Note this differs from the catalog summary's guesses: it is not weak per-service permissions or binary hijacking — it is a one-command reconfiguration of SCM's global DACL.

How it works

The attacker (with local admin) runs one command that sets SCM's DACL to grant Everyone (WD) full access (KA):

sc.exe sdset scmanager D:(A;;KA;;;WD)

The SDDL breaks down as: D: discretionary ACL, A; access-allowed ACE, empty flags, KA rights, empty object/inherit GUIDs, WD = the Everyone principal. A non-privileged user can then create a service pointing at any command, which SCM launches as SYSTEM. The writeup's example adds the low-priv account to local admins:

sc create LPE displayName= "LPE" binPath= "C:\Windows\System32\net.exe localgroup Administrators nonpriv-user /add" start= auto

A machine restart triggers execution and the account lands in the Administrators group.

Preconditions / Affected

Requires an initial compromised administrative account to set the DACL. After that, the persistence works for any non-privileged account. The example privesc payload relies on a machine restart to fire the service.

What to do

Verify the descriptor with sc.exe sdshow scmanager, or map rights readably with sc.exe sdshow scmanager showrights. Detect the modification with the author's Sigma rule (process_creation), which flags sc.exe command lines containing all of sdset , scmanager , and D:(A;;KA;;;WD) — tagged attack.persistence / attack.privilege_escalation, level high. The author stresses that any modification to SCM's DACL should be scrutinized heavily.

Caveats

The technique is highly resilient: removing the account's admin rights leaves the malicious service; removing the service leaves the ability to create a new one — so the root fix is restoring SCM's ACL, not chasing the artifacts. The fetched text is truncated mid-sentence at "The remediation for this type of persis…", so the page's stated remediation is not fully captured here. The Sigma rule matches the exact PoC string; a variant DACL would evade the literal contains match.

Organisations named here

  • Grzegorz Tworek

Technologies named here

  • sc.exe
  • Windows
  • Sigma rule
  • Sigma
  • PowerShell

Techniques named here

  • Abusing Service Control Manager ACL via sdset
  • Malicious service creation for privilege escalation
  • Checking service security descriptor via sdshow

Related in Offensive Security