Tim Beasley Senior Incident Response Consultant

Not every dangerous group in Active Directory looks risky.

I’ve been doing incident response, identity forensics, and compromise recovery long enough to have a running list of AD groups that get written off as “not a big deal.” Backup Operators. Print Operators. Server Operators. The ones nobody stresses about because they’re not Domain Admins.

Why should you care? Because attackers don’t need Domain Admin. When it comes to these groups, they need just one overlooked group with the right permissions—and nobody watching it.

That’s the pattern this series is built to break.

In each post in this series, we’ll take a closer look at a selected AD security group, and I’ll break down:

  • The specific rights that group has
  • The risks they can introduce
  • How attackers actually abuse them
  • What to check in your own environment today

By the end of this series, you’ll have a real checklist of quiet groups that deserve a second look.

Read this first post on Backup Operators, and you’ll walk away with a concrete audit-and-monitor checklist you can run this week. Then come back for the next group on the list.

Let’s dive in.


What rights does Backup Operators really have?

This is one of those Active Directory groups that sounds boring…but is actually dangerous.

Defenders tend to shrug it off because it’s not flashy like Domain Admins. That’s a mistake. Under the hood, it has rights that can enable serious—and in the wrong hands, catastrophic—abuse.

Members of Backup Operators have:

  • SeBackupPrivilege: Read any file on the system, ignoring NTFS ACLs
  • SeRestorePrivilege: Write or overwrite any file on the system, again ignoring ACLs
  • SeShutdownPrivilege: Shut down the system
  • Ability to log on locally by default on domain controllers and servers

Why Backup Operators privileges create a domain problem—fast

This group’s rights are technically local rights, but on a domain controller they quickly impact the entire domain. A compromised Backup Operator can access a DC, shut it down, or read, write, and overwrite critical files regardless of NTFS permissions. That includes ntds.dit, registry hives, protected binaries, service paths, and scheduled task targets.

ntds.dit is the AD database, so this is where things become “game over.” If an attacker can create a shadow copy of that file and grab the SYSTEM hive, they can extract domain users’ NTLM hashes, Kerberos keys, DPAPI-related secrets, and privileged service-account material offline.

Translation: They own you.

This is basically a DCSync attack…without doing DCSync. Teams on guard against such attacks often watch for replication rights, 4662 activity, or other replication indicators. Backup Operators can bypass those controls by copying the database directly—same end state, different path, and far easier to miss.

Restore rights matter too. An attacker can overwrite protected files, replace binaries such as sethc.exe or utilman.exe, alter service executables, or change scheduled task targets.

In other words, a compromised Backup Operator can steal the keys and plant a backdoor.


Even without Domain Controller access, the risk is still serious

On any server where the account can log on, Backup Operators can read everything—including files owned by SYSTEM. That access can expose registry data, application directories, backup repositories, and anything else written to disk under the assumption that NTFS permissions will protect it. (HA! NOT!)

That often means service-account credentials, stored domain creds used by apps or backup jobs, database connection strings, API tokens, Kerberos material, and certificate private keys are accessible.

Backup Operators is often a steppingstone during attacks—not the end goal.


Escalation paths from Backup Operators

Attackers can also abuse restore rights to write malicious DLLs into protected paths, replace service binaries, modify boot or recovery settings, and force execution as SYSTEM.

Because Backup Operators group accounts are often treated as trusted, they may land on backup servers, escape some hardening controls, or operate with less scrutiny than obvious admin groups.


Why people underestimate Backup Operators group risks

I hear this all the time:

  • “They aren’t admins.”
  • “They can’t change AD objects.”
  • “Backup accounts need broad access.”
  • “Our tooling already watches for replication abuse.”

All of that falls apart once an attacker copies the ntds.dit and registry.


“So what do we do?”

Simple: Empty the group, monitor membership changes, and keep it empty. If nobody is in Backup Operators, nobody can abuse it.

That is the best-case answer and, frankly, the one I wish more teams would accept before a vendor talks them into something reckless.

But it’s rarely that simple. In incident response, I see this constantly:

  • A vendor says their application “requires” Backup Operators.
  • Accounts get dropped into the group.
  • Everyone moves on.

If you’re in that boat, the goal is to reduce the risk as aggressively as possible and stop treating these as low-impact accounts.


First: Enforce tiering

Backup Operator accounts should be treated as Tier 0-adjacent identities. If an account can help an attacker get to your AD database, your privileged secrets, or your most sensitive servers, it’s Tier 0.

  1. Keep the group empty, monitor membership changes, and treat any exception as high risk.
  2. Never allow Backup Operators to log on to domain controllers unless there is no viable alternative. Use Deny log on locally and Deny log on through Remote Desktop Services. And restrict these accounts to specific backup servers only.
  3. Monitor for interactive logons. Backup Operator accounts should behave like service identities, not people at keyboards.
  4. Enable advanced file-access auditing on ntds.dit, the SYSTEM hive, backup repositories, and application config locations. Alert on “impossible reads”—such as 4663—against files the account should not reach through NTFS alone.
  5. Watch for tools such as diskshadow.exe, vssadmin.exe, wbadmin.exe, ntdsutil.exe, and esentutl.exe, especially on DCs, outside backup windows, or from interactive sessions.
  6. Reduce blast radius with gMSAs, application-specific APIs, modern backup tooling with reduced privileges, and dedicated or isolated backup infrastructure where possible.

How to audit SeBackupPrivilege abuse

Auditing SeBackupPrivilege use is tricky because Windows does not log SeBackupPrivilege was used directly.

You can see when special privileges are assigned to a logon, but not a clean event showing the privilege exercised against a specific file. Detection comes from context, file access, process behavior, and correlation.

Start with event 4672, which shows when a user logs on and receives SeBackupPrivilege or SeRestorePrivilege. It tells you when the session started and narrows the hunt window. Backup Operators on DCs, on non-backup servers, or in interactive sessions should stand out immediately.

Then enable advanced file-system auditing and place SACLs on what matters:

  • C:\Windows\NTDS\ntds.dit
  • The SYSTEM hive
  • SAM
  • Backup repositories
  • Application config directories

Events such as 4663 and, where useful, 4656, show what was actually touched.

The strongest signal is the “impossible read”—a successful read against a file the user should not be able to access through NTFS permissions alone. If the account is a Backup Operator, backup privilege is what made that possible.

  • 4672: Who logged on with the privilege
  • 4663: What protected files or snapshot paths were read
  • 4688: What process or tool made it possible
  • Context: Where it happened, when it happened, whether it was interactive, and whether it made operational sense

Process creation telemetry adds the next layer. Enable 4688 with command-line logging and watch for ntdsutil.exe, diskshadow.exe, wbadmin.exe, esentutl.exe, vssadmin.exe, and ‘copy’ or PowerShell commands aimed at sensitive paths. The combination of 4672, 4688, and 4663 is where high-confidence detections start.


How to detect shadow copy abuse

Shadow copy abuse deserves special attention because it is one of the cleanest ways to bypass file locks and quietly copy sensitive data from a live system. On a DC, that usually means ntds.dit and the SYSTEM hive. Elsewhere, it can mean registry hives, application secrets, and backup material.

To detect it well, you need process-creation auditing, file-system auditing on sensitive paths, and privileged-logon visibility. Command-line logging matters because the process name alone does not tell you whether a snapshot was created, exposed, or copied from.

High-signal indicators include vssadmin.exe, diskshadow.exe, wbadmin.exe, ntdsutil.exe, and esentutl.exe run by a non-SYSTEM user, especially on a DC, outside known backup windows, or from an interactive session. DiskShadow scripts launched from temp directories deserve extra scrutiny.

One of the strongest indicators is access to paths containing HarddiskVolumeShadowCopy. Reads from those paths—especially targeting ntds.dit, SYSTEM, or SAM—by a non-SYSTEM user should be treated as abuse until proven otherwise.

  • 4672 showing SeBackupPrivilege assigned to a Backup Operator or similarly privileged account
  • 4688 showing VSS-related tool execution such as diskshadow, vssadmin, wbadmin, ntdsutil, or esentutl
  • 4663 showing reads from a shadow copy path, ntds.dit, the SYSTEM hive, SAM, or another protected target
  • Activity occurring within a short time window, especially on a domain controller or other Tier 0 system
  • Interactive use, ad hoc timing, or execution outside a normal backup schedule increasing confidence further

Bottom line: Backup Operators deserves attention

Backup Operators appears harmless, but in practice sits uncomfortably close to full domain compromise.

Abuse of this group on a DC can expose the directory database, bypass replication-focused detections, harvest credentials offline, and establish persistence through protected file replacement. Even without DC access, the same rights can expose service credentials, application secrets, and escalation paths across the server estate.

The right response is to treat these accounts as highly sensitive. Keep the group empty whenever possible, constrain where the accounts can log on, monitor privileged logons and sensitive file access, watch for shadow copy behavior, and assume compromise is critical until you can rule out access to the data that matters.

Follow the conversation about Backup Operators on LinkedIn.

And if you want expert help finding and closing gaps in your AD security gaps, reach out for an Active Directory Security Assessment. We’re here for you.

Further reading