TL;DR: Backup Operators can read and overwrite protected files, copy ntds.dit through shadow copies, and extract domain secrets without Domain Admin rights, according to Semperis. The governance problem is that local backup privileges become domain-wide exposure when tiering, logon restrictions, and file-level monitoring are weak.
At a glance
What this is: Semperis argues that Backup Operators can become a near-privileged path to domain compromise because backup rights can bypass NTFS protections and expose Active Directory secrets.
Why it matters: This matters because IAM and PAM teams often under-rank backup-related privileges, yet those rights can expose Tier 0 assets, bypass normal audit paths, and widen blast radius across the domain.
Context
Backup Operators is a local Windows identity boundary that can turn into a domain-wide governance problem when it is allowed onto domain controllers. In Active Directory, backup and restore privileges can bypass file permissions, access protected system files, and expose directory secrets that were assumed to be out of reach.
The governance failure is not that Backup Operators resembles Domain Admin. It is that defenders often treat local backup rights as operationally safe even though those rights can reach ntds.dit, registry hives, and backup paths that contain credential material. Once that assumption breaks, the group becomes a Tier 0-adjacent identity that deserves the same scrutiny as higher-privilege administrative access.
Key questions
Q: What breaks when Active Directory backups are not dedicated and isolated?
A: When Active Directory backups are not dedicated and isolated, attackers can use the same environment to plant backdoors, persist malware, or compromise the restore path. That turns recovery into another point of failure instead of a control. Organisations may believe they have resilience, but their restoration process can still be unsafe, incomplete, or too slow to stop ransomware pressure.
Q: Why do Backup Operators privileges increase domain compromise risk?
A: Because on a domain controller the group can reach the files that hold directory secrets, not just perform routine backup tasks. Once ntds.dit and related hives are copied, attackers can work offline to extract hashes and keys. That makes the role a credential-exposure problem, not a simple server-admin convenience.
Q: What are the signs that backup privilege abuse is happening?
A: Look for privileged logons followed by access to ntds.dit, SYSTEM, SAM, or shadow-copy paths, especially when tools such as diskshadow, vssadmin, wbadmin, ntdsutil, or esentutl appear outside normal backup windows. The strongest signal is a protected file read that should not be possible through NTFS alone.
Q: How should teams respond when Backup Operators access a domain controller?
A: Treat the session as high risk until you can prove it was a legitimate backup workflow. Correlate logon type, file access, process creation, and host context, then validate whether the account should have been on that system at all and whether any protected files were exposed.
Technical breakdown
Why backup privileges bypass normal access controls
SeBackupPrivilege and SeRestorePrivilege are Windows rights that override NTFS ACLs for reading and writing, respectively. That means the identity does not need ordinary object permissions if the backup privilege is in place and the system allows the logon. On a domain controller, those rights can expose the AD database, registry hives, service binaries, and scheduled task targets. The technical danger is not just breadth of access, but the fact that file-level assumptions no longer hold once backup semantics are invoked. The account is acting under an alternate authorization path, which bypasses the access model most teams think they are enforcing.
Practical implication: treat backup-privileged accounts as access exceptions that must be tightly constrained to approved systems and paths.
How ntds.dit and shadow copies enable offline credential theft
A shadow copy lets an operator read files that are otherwise locked or in use, which makes it a common way to copy ntds.dit and the SYSTEM hive from a live domain controller. With those files, an attacker can extract NTLM hashes, Kerberos keys, DPAPI-related material, and privileged service-account secrets offline. That is why this path is so dangerous: it bypasses replication-based detection and turns a local privilege into directory-wide credential exposure without requiring Domain Admin. The attack succeeds because the backup workflow provides a legitimate mechanism for high-value file duplication.
Practical implication: monitor shadow-copy tooling and sensitive file reads on domain controllers as if they were credential-access events.
Why restore rights create persistence as well as theft
Restore rights do more than copy data. They can also overwrite protected files, replace service executables, and alter boot or recovery paths in ways that let an attacker preserve access or trigger code as SYSTEM. That turns Backup Operators from a read-only risk into a persistence and execution problem. The core issue is that the same privilege set that restores backups can be used to modify trusted operating system components if controls are weak or logging is absent. This is why the group needs to be governed as a high-risk identity, not a convenience account.
Practical implication: watch for protected-file replacement and service-binary changes from backup-privileged sessions on sensitive servers.
Threat narrative
Attacker objective: The objective is to reach domain-wide control by extracting directory secrets and using restore rights to preserve or expand privileged access.
- Entry occurs when a compromised or misused Backup Operators account lands on a domain controller or backup-capable server with backup and restore rights.
- Credential access follows when the actor creates a shadow copy or copies protected files such as ntds.dit and the SYSTEM hive, bypassing NTFS and normal replication controls.
- Escalation and persistence occur when the actor extracts directory secrets offline or overwrites protected binaries and service paths to maintain privileged access.
- Impact is full domain compromise, including offline theft of hashes and keys, unauthorized access to sensitive servers, and the ability to plant durable backdoors.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Backup privilege abuse is a Tier 0 governance problem, not a low-value local rights issue. The article shows that SeBackupPrivilege and SeRestorePrivilege can bypass NTFS protections and expose directory secrets on systems that were never meant to be treated as ordinary endpoints. That means the governance boundary is not the group name but the blast radius of the files it can reach. Practitioners should classify these accounts by the data they can expose, not by whether they carry a Domain Admin label.
File-level protection fails when backup semantics become an alternate access model. A control set built around ACLs, replication monitoring, and normal logon review assumes the attacker must ask for access through standard paths. Backup Operators can reach ntds.dit, registry hives, and shadow-copy paths through a different mechanism, so the model misses the event class entirely. The implication is that sensitive file access and privileged logon telemetry must be correlated, not reviewed in isolation.
Shadow-copy abuse is the named governance gap: protected directory data was never meant to be movable by a lightly governed local group. The article makes clear that copying the AD database through a snapshot is effectively a DCSync-equivalent outcome without using replication rights. That collapses the assumption that defenders can focus only on directory replication abuse. Practitioners need to treat backup workflows as part of identity governance for Tier 0 assets.
Backup Operators should be managed as a constrained privileged identity, not a broadly trusted administrative convenience. The article’s recommended tiering, local-logon restriction, and advanced auditing reflect a larger truth: operational necessity often masks privileged reach. If a backup identity can touch domain controller files, its lifecycle, exception handling, and monitoring belong in PAM and IGA, not in an operations exception list.
Identity blast radius: the real risk is not the account’s nominal role, but the set of security boundaries it can cross in one session. This article is a clear example of why practitioners must map privilege to reachable assets and not to job descriptions. The practical conclusion is that governance teams should review backup accounts through a Tier 0 lens whenever they can reach directory, credential, or recovery material.
What this signals
Backup Operator governance only works when privilege is tied to specific systems and specific files. The article shows why ordinary group membership checks are not enough. Teams need to understand where a backup identity can log on, what it can read, and which protected paths become reachable once SeBackupPrivilege is present.
Backup workflows belong inside the same review cycle as Tier 0 access. If a backup identity can reach a domain controller, then its monitoring, exception handling, and offboarding need to be treated like privileged access governance, not general operations hygiene. That is especially true where shadow-copy tooling can bypass normal visibility.
Shadow-copy abuse turns file integrity into an identity problem. The meaningful control question is not only whether NTFS is configured correctly, but whether backup-privileged sessions are being watched for access to directory database files, hive files, and protected service paths.
For practitioners
- Empty the Backup Operators group Remove standing membership wherever possible and treat every exception as a high-risk, time-bound approval tied to a specific operational need.
- Restrict where backup accounts can log on Block interactive logon on domain controllers and use Deny log on locally plus Deny log on through Remote Desktop Services for backup-privileged identities.
- Audit access to directory and hive files Place SACLs on ntds.dit, SYSTEM, SAM, and backup repositories so you can correlate privileged logons with successful reads of protected material.
- Alert on shadow-copy tooling Watch for diskshadow.exe, vssadmin.exe, wbadmin.exe, ntdsutil.exe, and esentutl.exe on domain controllers, especially outside approved backup windows or from interactive sessions.
- Reduce blast radius with isolated backup design Use dedicated backup servers, gMSAs, and modern backup tooling with reduced privilege so backup workflows do not share trust boundaries with Tier 0 systems.
Key takeaways
- Backup Operators can become a direct route to domain compromise because backup and restore rights can bypass normal file protections.
- Shadow copies let attackers move directory data offline and extract secrets that replication-focused monitoring may miss.
- Teams should govern backup-privileged identities as Tier 0-adjacent, with strict logon limits, file auditing, and shadow-copy detection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Backup Operators can reach directory secrets through excessive local privilege on servers and domain controllers. |
| NHI-01 — Improper Offboarding | The article recommends keeping the group empty and removing unnecessary membership quickly. | |
| NHI-07 — Long-Lived Secrets | Backup workflows can expose credential material that persists far beyond intended use. | |
| Recommendation — Map backup-privileged accounts to NHI-05 and remove standing access that crosses Tier 0 boundaries. Apply NHI-01 governance to revoke backup-group membership when operational need ends. Use NHI-07 controls to reduce how long privileged backup access can persist on sensitive systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Backup accounts require lifecycle control over credentials and privileged authentication paths. |
| Recommendation — Enforce IA-5 so backup-privileged credentials are managed, rotated, and removed with strict lifecycle control. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Shadow-copy extraction and DC file access are classic credential-access and movement patterns. |
| Recommendation — Map backup-account activity to TA0006 and TA0008 so detections cover file theft and pivoting. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about overbroad access permissions and where they cross trust boundaries. |
| Recommendation — Apply PR.AA-05 to review and constrain backup-account entitlements on Tier 0 systems. | ||
Key terms
- Backup Operators: A built-in Windows Active Directory group that can use backup and restore privileges to access protected files beyond normal NTFS permissions. In practice, it can become a high-risk privileged identity because those rights can expose system state, directory data, and sensitive server files.
- SeBackupPrivilege: A Windows privilege that allows a principal to read files while bypassing normal NTFS access checks. In identity governance terms, it is dangerous because it expands what the account can extract, not just what it can administer, and on domain controllers it can expose high-value identity data.
- SeRestorePrivilege: A Windows privilege that allows a principal to write or overwrite files even when ordinary access controls would block the change. It matters because restore capability can become persistence capability when an identity can replace binaries, alter service paths, or modify protected targets.
- Shadow Copies: Shadow copies are untracked replicas of sensitive content created in collaboration tools, documents, reports, or archived systems. They matter because redacting the original ticket does not remove the copies that keep the exposure alive.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or PAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 30, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org