Active Directory Backup Operators, Print Operators, Server Operators Privilege Escalation: The Groups Nobody Audits

Active Directory Backup Operators, Print Operators, Server Operators Privilege Escalation Explained

Active Directory Backup Operators, Print Operators, Server Operators privilege escalation is a class of risk that most Domain Admins-focused reviews never check, because none of these four built-in groups — Backup Operators, Print Operators, Server Operators, or Account Operators — is nested inside Domain Admins or Enterprise Admins by default. Yet Microsoft's own documentation lists all four as Active Directory security groups, and Microsoft separately classifies them as protected accounts and groups — the same protection tier as Domain Admins and Schema Admins.

That classification is the tell. Membership in any one of these four groups is enough to reach full read/write access to every file on a domain controller, kernel code execution, service-level command execution, or domain-wide account manipulation. None of these are misconfigurations or missing patches — they are the designed behavior of Windows user rights, applied by default to a group an attacker only has to get one account added to.

How Each Group Grants Domain Admin-Adjacent Rights

The mechanism is the Default Domain Controllers Policy GPO, which assigns specific Windows user rights to these groups on every DC in the domain:

These defaults are documented directly by Microsoft: the "Back up files and directories" policy page lists Administrators, Backup Operators, and Server Operators as the default holders on domain controllers, and the "Load and unload device drivers" policy page lists Administrators and Print Operators. Account Operators' scope is described in the same security groups reference: members can create and modify most account types, but the group itself has no members by default and Microsoft's guidance is to keep it that way.

The Attack Chain: Four Separate Ways In

Step 1 — Backup Operators to ntds.dit

SeBackupPrivilege bypasses NTFS ACLs entirely, which means it can be used to lift the AD database straight off a live DC without ever touching the domain admin group. The pattern documented across multiple public write-ups — Semperis, Hacking Articles, and nhimg.org — uses diskshadow.exe to create a volume shadow copy so the locked ntds.dit file can be copied out, then robocopy (which honors SeBackupPrivilege) to pull the copy and a SYSTEM registry hive export off the box:

# diskshadow script (run from an account holding SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Offline, ntds.dit plus the SYSTEM hive hand over every password hash in the domain — a straight line to a pass-the-hash login as a Domain Admin, with no exploit and no CVE required. It reaches the same secrets our ACL abuse and DCSync piece covers for ACL-based paths — just through a file-system bypass instead of a replication right.

Step 2 — Print Operators to SYSTEM via a loaded driver

SeLoadDriverPrivilege lets a Print Operator load a kernel-mode driver on a domain controller. As Tarlogic's research on the privilege and multiple offensive-security note collections (e.g. HackTricks) describe, this privilege is commonly abused by loading a legitimately signed but exploitable driver — the Capcom.sys technique is the best documented public example — to run arbitrary code in kernel space as NT AUTHORITY\SYSTEM. From there, adding the current account to Domain Admins or dumping ntds.dit directly is trivial.

Step 3 — Server Operators to service hijack

Server Operators inherit the same backup/restore rights as Backup Operators, but they also get SERVICE_ALL_ACCESS over most services on a DC. Hacking Articles' write-up on the group walks through repointing a legitimate service's binary path at an attacker-controlled executable and restarting it — the service then runs the payload as SYSTEM. Published research on SeRestorePrivilege abuse (commonly reached through Server Operators membership) additionally shows it enables overwriting protected system binaries and hijacking service DLLs, giving at least three independent paths from a single group membership to SYSTEM on a DC.

Step 4 — Account Operators to silent persistence

Account Operators carries no OS privilege, but its AD-native rights are broad: create new users, reset most users' passwords, and add or remove members from most groups, domain-wide. The Cyber Advisors write-up on Account Operators describes it as often "one step away from Domain Administrator" — the group can't touch Domain Admins, Enterprise Admins, or the other protected groups directly (they're shielded by the AdminSDHolder ACL), but it can freely create accounts, add itself to any non-protected group with delegated rights, and reset the password of any account that isn't in a protected group. That is enough for durable, low-visibility persistence even without ever touching a Tier 0 group.

🚨 Danger: none of these four techniques require a vulnerability disclosure, a CVE, or a missing patch. They are the intended, by-design behavior of Windows user rights — the only "bug" is an account being a member of the group.

Detection

Group membership changes and privilege use are both logged natively — the gap is almost always that nobody is watching for it.

Correlate all of the above with interactive or RDP logons (Event ID 4624, logon type 2 or 10) from these four groups on a DC — under any reasonable tiering model, none of them should ever need one. Our Active Directory Monitoring guide to the event IDs that matter covers the audit policy prerequisites for all of the events above. Continuous enumeration tools such as etc-collector, PingCastle, and Purple Knight can also flag non-empty membership of these groups directly, without waiting for a log event to fire.

Remediation

1. Keep all four groups empty. This is the documented default state; treat any addition as an incident-worthy change, not a routine delegation.
2. Delegate narrowly instead of nesting into built-in groups. If a team genuinely needs to create user accounts, grant that right via a scoped OU-level ACL delegation rather than membership in Account Operators, which is domain-wide by design.
3. Move backup jobs off domain-wide privilege. Where the backup product allows it, use a dedicated service account scoped to the specific backup target instead of a human or shared account holding SeBackupPrivilege/SeRestorePrivilege domain-wide via Server/Backup Operators.
4. Apply a tiering model. No Tier 1 or Tier 2 admin, helpdesk, or service account should ever be nested into a Tier 0 group — these four included. Our Privileged Access Drift piece covers how nested membership creeps back in even after a clean audit, and our Hardening Active Directory guide covers where this fits in a broader lockdown sequence.
5. Turn on the audit policy and alert on it. Enable "Audit Sensitive Privilege Use" and "Audit Security Group Management," forward Event IDs 4728/4732/4756/4673 to your SIEM, and alert on any hit involving these four group SIDs.
6. Re-check regularly, not once. These four groups are exactly the kind of finding that a broader review of common Active Directory security misconfigurations tends to surface alongside — run the check as part of every recurring audit cycle, not a one-time cleanup.

How EtcSec Detects This

EtcSec's ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER, and SERVER_OPERATORS_MEMBER checks flag any non-empty membership in these four groups on every AD audit — the same near-zero-tolerance baseline Microsoft documents. PRIVILEGE_SEBACKUP_ABUSE and PRIVILEGE_SERESTORE_ABUSE separately catch cases where SeBackupPrivilege or SeRestorePrivilege has been assigned beyond the built-in defaults via GPO, which is the other way these rights end up in the wrong hands.