J. Perez Duertojperezduerto.info

Server Operators to Domain Admin: why a forgotten built-in group is tier-0 on a domain controller

  • active-directory
  • windows-privilege-escalation
  • privileged-groups
  • detection

Ask someone to name the dangerous Active Directory groups and they will say Domain Admins and Enterprise Admins. They rarely say Server Operators, which is exactly why it is dangerous. It sounds like a group for people who reboot print servers, so a tired administrator drops a service account into it to make some backup or service-management task work, and moves on. On a domain controller that decision quietly hands out Domain Admin, and this post is about why. It is the third link of the over-privileged service-account chain, and it is the step that turns a merely-read service account into total control of the directory.

What you will learn

  • Why a group's name tells you nothing about its power, and how to read a group by its privileges instead.
  • The two independent ways Server Operators escalates to Domain Admin on a DC: service reconfiguration and the backup privilege.
  • How to confirm the privileges on a token you control, so you recognize the opportunity when you see it.
  • How to prove both routes in a lab you own.
  • The group hygiene that makes this impossible, and why "empty the group" is the real fix.

Prerequisites and scope: you control an account that is a member of BUILTIN\Server Operators on a domain controller (often a service account that arrived there for convenience, sometimes via a gMSA read). Everything here is a group granted too much, not a bug, so it closes to group membership hygiene, not a patch.

The mental model

A group in Active Directory is a bundle of rights, and the name on the bundle is just a label someone chose. Judging a group by its name is like judging a box by the word written on the side instead of what is inside. "Server Operators" has a modest-sounding label, but open the box and you find two things that are each game-over on a domain controller:

  • a master key to the building's machinery (the ability to reconfigure and restart services), and
  • a locksmith's warrant that lets you read any locked room (SeBackupPrivilege).

Either one, on a DC, is Domain Admin by a short walk. The lesson for a learner is durable: always open the box. Enumerate what a group or a token actually grants, never trust the label.

Two independent routes from Server Operators to Domain Admin Membership of Server Operators on a domain controller leads to Domain Admin by two independent routes: reconfiguring a service to run as SYSTEM, or using SeBackupPrivilege to read NTDS.dit. Closing one route does not close the other. Server Operators on a DC Route 1 reconfigure a service: SYSTEM on the DC Route 2 SeBackupPrivilege: read NTDS.dit Domain Admin on the DC
Two doors, one room. Service control gives SYSTEM on the DC; the backup privilege reads the directory database. A defender who locks one door and leaves the other open has not closed the group. The fix is to empty it.

Why it is tier-0: two independent routes

Route 1: services on a DC run as SYSTEM, and you can reconfigure them

Server Operators can create, configure, start, and stop services on the machine. Windows services run under powerful local identities, most as LocalSystem (SYSTEM), which on a domain controller is a tier-0 context: SYSTEM on a DC can read the directory database and act as the machine account, which is a domain controller. So the escalation is blunt: point a service's binary path at a command of your choosing, start the service, and that command runs as SYSTEM on the DC.

:: reconfigure an existing (or new) service to run an attacker command as SYSTEM, then start it
sc.exe config <servicename> binPath= "cmd /c net localgroup administrators <you> /add"
sc.exe start  <servicename>

On a real engagement you would clean this up and choose a less destructive payload, but the principle is the point: service control on a DC equals SYSTEM on a DC equals domain compromise.

Route 2: SeBackupPrivilege, no service required

Server Operators also carries SeBackupPrivilege and SeRestorePrivilege in its token. The backup privilege lets you read any file regardless of its ACL, and on a DC the file that ends the game is NTDS.dit, the directory database with every account hash including krbtgt. You do not touch a service at all; you snapshot the volume and copy the database out in backup mode. That full technique, with the diskshadow and robocopy sequence, is its own deep-dive: SeBackupPrivilege on a domain controller.

Two doors, one room. A defender who locks the service door but leaves the backup door open has not closed the group.

Confirm the token before you act

Teaching yourself to read the token is the transferable skill. When you land a shell or a WinRM session as the member account, check what you were actually granted:

whoami /groups     # look for BUILTIN\Server Operators, and the mandatory level
whoami /priv       # look for SeBackupPrivilege, SeRestorePrivilege, SeServiceLogonRight-adjacent rights

If SeBackupPrivilege shows as Disabled, that is normal: it is present in the token and you enable it from code or with a helper when you use it. "Disabled" means "available to you", not "denied". Recognizing that one line is what separates "I am stuck" from "I own this DC".

Build it in a lab

Prove both routes on a DC you own:

  1. A DC and a test account. On a lab domain controller, create a plain user svc_test and add it to the built-in group:
    New-ADUser svc_test -Enabled $true -AccountPassword (ConvertTo-SecureString 'LabPass123' -AsPlainText -Force)
Add-ADGroupMember 'Server Operators' svc_test
  2. See the privileges. Log on (or WinRM) as svc_test and run whoami /priv. Note SeBackupPrivilege present.
  3. Route 1. Create a throwaway service and point it at a harmless marker command (for example writing a file to C:\Windows\Temp), start it, and confirm the file was created by SYSTEM.
  4. Route 2. Follow the NTDS extraction lab to copy the database out with the same account.
  5. Clean up. Remove the service and the test account. The habit of restoring the lab is the same habit that keeps you honest on an engagement.

Watching whoami /priv light up for an account you only added to a mild-sounding group is the entire lesson in one screen.

Detection

  • Membership is an inventory to watch, not just an event. Treat Server Operators, Backup Operators, and Account Operators membership as a standing list you review on a schedule. Additions are events 4728/4732/4756; a service account appearing in any of them is a near-certain misconfiguration or an attacker.
  • Service reconfiguration on a DC. Changes to a service's binary path are event 7045 (new service) and 4697 (a service was installed), plus command-line auditing (event 4688) catching sc.exe config ... binPath=. On a domain controller these are high-signal.
  • Backup-privilege use. SeBackupPrivilege assigned at logon is event 4672; shadow-copy creation and robocopy /B against NTDS are the follow-on tells, detailed in the NTDS post.

Prevention and response

  • Empty the group. The real fix is that Server Operators, Backup Operators, and Account Operators should be empty or contain only a tightly justified, monitored account. Microsoft's own guidance treats them as highly privileged. A service that needs one capability should be granted that one right, not dropped into a group that bundles ten.
  • Grant the narrow right instead. If a task genuinely needs to restart a specific service or back up specific files, delegate that precisely rather than via a built-in group.
  • Protect accounts that must hold it as tier-0. Anything in these groups can own the DC, so it belongs in the same trust tier as a Domain Admin: no logon to workstations, strong managed credentials, monitored.
  • Response after abuse. Assume DC compromise: if either route was used, treat the directory as fully compromised, rotate krbtgt twice, reset privileged accounts, and remove the offending membership. Removing the account without assuming compromise is the common half-measure that leaves an attacker's forged tickets valid.

Check yourself

  1. Why is the name "Server Operators" misleading, and what should you look at instead?
  2. Give the two independent escalation routes and the one-line reason each one reaches Domain Admin.
  3. whoami /priv shows SeBackupPrivilege as Disabled. Are you blocked? Why or why not?
  4. Why is "remove the account from the group" an incomplete response after the privilege was used?

Answers:

  1. The label describes an intended help-desk role, not the rights inside. Read the group by its privileges and capabilities (service control, SeBackup/SeRestore), which on a DC are tier-0.
  2. Route 1, service reconfiguration: services on a DC run as SYSTEM, and SYSTEM on a DC is domain compromise. Route 2, SeBackupPrivilege: it reads any file including NTDS.dit, which holds every hash.
  3. Not blocked. Disabled means the privilege is in your token and you enable it when you use it; it is available, not denied.
  4. Because if the backup or service route was used, the attacker likely extracted krbtgt and can forge tickets indefinitely. You must assume full directory compromise and rotate krbtgt, not just revoke the membership.

Use

Authorized and educational use only: your own lab, a directory you own, or an engagement with written permission. This is a teaching walkthrough of a built-in group's real power, tools named rather than carried, paired with detection and the group hygiene that closes it. It is not a runbook for use against systems you do not own.

References

Back to all techniques