Hackers Stole the NTDS.dit File. What It Means for Active Directory Security

What is NTDS.dit, and why is it so valuable?

NTDS.dit is the primary Active Directory database. It stores user account, group membership, and password hash information. If an attacker obtains a copy of NTDS.dit and the SYSTEM registry hive (a situation often achieved through various means, including social engineering), they will be able to access the password hashes and either crack them offline (using the orthodox method of brute-force) or carry out a haProtect and secure backupssh-based attack to log in to any account as if they are the user. 

This represents a fast track for an attacker to access domain admin credentials and subsequently, unrestricted access to the entire forest. Semperis published an interesting technical report as to why NTDS.dit is important, and NTDS.dit is leveraged when conducting these types of attacks. In short, if you are protecting NTDS.dit, you are protecting the keys to the kingdom.

How attackers usually get NTDS.dit

Attackers seldom “take” NTDS.dit from an arbitrary desktop. The normal pattern of activity is as follows:

1. Initial access to the desktop or via phishing: The hacker gains access to either a typical user account, perhaps one for a contractor.
2. Privilege escalation and lateral movement: The attacker employs tools and now has credentials to pick up higher privileges and pivot in the enterprise.
3. Target the domain controller: Once the attacker has higher privileges, they run backup or copy utilities on a DC to get a copy of NTDS.dit. Often, actors utilize built-in Windows tools to create a volume shadow copy. Following this, the attacker then copies over the database and the SYSTEM registry hive that contains the key to decrypt the BYOH. Reports and research have seen actors use vssadmin, ntdsutil, or backup tools to get these copies.
4. Exfiltration and cracking or reusing hashed password files: Once the above files are outside of the enterprise, the attacker has time to work on the files or use the hijacked hashes to pivot further in the domain.

The above pattern has been observed in numerous incidents or case studies and is documented extensively by multiple security teams.

Real-world examples that show how dangerous this is

Recent incident reports and analysis demonstrate this technique in practice. In one case, an attacker employed a hybrid social engineering, native Windows tool approach to obtain NTDS.dit, and then used the extracted credentials to deploy ransomware across multiple systems. This case and others illustrate that attackers prefer simple and effective methods that leverage trust, or human error, and that use built-in or self-provisioning administrative or operational tools instead of relying on more esoteric or invasive exploits. 

This isn’t an exercise in theory. The attack path works because AD holds domain-based credentials, and many environments allow appropriate administrative access or delegation that permits copying and/or backing up of those files without rigging other controls to authenticate.

How to spot signs that someone may be trying to steal NTDS.dit

Watch for abnormal behavior that could indicate NTDS.dit access:

• Use of a shadow copy or backup commands against a DC. Execution of ntdsutil.exe, vssadmin.exe, wbadmin.exe, or similar operations on a DC is an extremely common sign of an NC. Semperis and Trellix each have included mention of the fact that unusual use of standard tools like these is a very strong indicator. 
• Export of the SYSTEM hive or registry read of the DC’s registry. Copying of the SYSTEM hive is a required step to decrypt the hashes. Be vigilant for unexpected registry extraction from the DC. 
• New service accounts or unexpected use of service accounts or high-privilege accounts. It’s very common for attackers to create or reuse service accounts to back up, copy files, etc. 
• Large file read access to the NTDS.dit path, or extraordinarily large SMB reads from home folders of system folders on a DC. These actions are very noisy and should absolutely trigger alerts. 
• True administration logins or administration logins from new IP addresses at unlikely hours. Attackers will generally obfuscate their movement, but even they will reuse stolen creds and/or avoid typing in passwords to reduce the level of detection possible. 

If you observe a single one of these signs, it could potentially be an action with a benign justification. However, if you witness several at once (shadow copy + SYSTEM hive copy + unexpected admin login), this should be treated as an emergent condition for investigation.

Short-term actions if you suspect NTDS.dit was copied

If you think that NTDS.dit has been accessed or copied, take immediate action and follow an organized process: 

• Immediately isolate any affected systems. If you can do so safely, remove the Domain Controller (DC) from the network. 
• Collect forensic evidence. Take a snapshot, export all relevant logs, and preserve copies of any suspicious files for future investigation. 
• Selectively force password resets for the most compromised credentials. Start with administrative accounts as well as accounts that show suspicious logins. Treat the reset process as an emergency containment of the incident. 
• Look for copy and exfil events. Look for shadow copy events, while also looking for outbound log events showing data transfers, etc. 
• Patch and check for persistence. Look for web shells, scheduled tasks, and the possible backdoors the attacker may have left behind. 
• Bring in and engage incident response experts. Large AD incidents require the attention of specialists to mitigate further damage from your organization’s response. 

These steps give you time to determine and understand the full scope of what has happened with NTDS.dit.

What to fix, so NTDS.dit attacks are much harder

The following are controls that are actionable to limit the possibility of NTDS.dit theft or mitigate its impact. These actions are not carved in stone and are put in an order of magnitude or urgency. 

1. Reduce the number of accounts that can access DCs

Restricting who can log into the domain controllers, all DC users should represent a small, dedicated administrative subset. Daily regular users should have their own separate accounts from admin-dedicated accounts.

2. Use an admin tier model

Divide admin roles into tiers. Put the domain controllers into the highest tier, and prevent lower-tier admins from using their credentials on the domain controller. This will help eliminate lateral escalation.

3. Use dedicated admin workstations

Admin users should manage a DC from dedicated, hardened administrative workstations that do NOT have internet access. This reduces the opportunity for phishing or drive-by malware, or means of intrusion.

4. Lock down tools that can copy NTDS.dit

Control who can run ntdsutil, wbadmin, vssadmin, and other tools that could copy an NTDS.dit file on a DC (beyond the native Windows backup system). Utilize application control or endpoint policies to restrict or log these applications with non-approved accounts.

5. Protect and secure backups

Keep a backup of your DC offline and encrypted. If a backup file is on a network share, an attacker could copy it. Ensure all backups are access-controlled and monitored. 

6. Protect the SYSTEM hive and encryption keys

Control access to the registry and SYSTEM hive. Monitor any tools and scripts that read/export the registry. 

7. Enforce strong passwords and MFA on privileged accounts

Even if they have password hashes, a strong passphrase, and MFA increases cost and friction. Require MFA for administrative access or work done remotely.

8. Monitor and alert on key indicators

Be cautious about anomalous command-line behavior on Domain Controllers. While commands like ntdsutil activate instance ntds ifmand vssadmin createshadowcopy are valid Windows utilities, attackers often leverage them for the purpose of copying the Active Directory database (NTDS.dit). Utilize alerting in your SIEM (Security Information and Event Management) or EDR (Endpoint Detection and Response) solution for increased visibility on these commands or anytime there is an unusually large read on Domain Controller file paths.

9. Audit and log everything

Implement deep logging on the domain controllers and collect logs in a single location to quickly search and correlate events. Track who changed privileges, when backups were created, and who added accounts.

10. Test incident playbooks and backups regularly

Perform regular tabletop exercises (with testing NTDS.dit access); always test your restore process so you know you’ll be able to restore AD if needed.

Detection examples you can implement now

Below are simple, practical checks to add to your monitoring system or EDR rules:

• Alert: Process start for ntdsutil.exe on any DC, unless invoked by a named backup job.

(Use this rule in your SIEM or EDR by monitoring Windows process creation events — Event ID 4688 or Sysmon ID 1.)

• Alert: Process start for vssadmin.exe or wbadmin.exe on DCs by non-backup operator accounts.

(Implement this in your EDR or SIEM to flag shadow copy creation commands when they are unauthorized.)

• Alert: Registry export or reg save of the SYSTEM hive on any DC.

(Monitor this in your EDR or Sysmon logs; attackers perform this activity to extract decryption keys for the AD password hashes.)

• Alert: SMB read of %systemroot%\NTDS\ntds.dit or large reads from system directories on DCs.

(Set this up in your SIEM or file monitoring tool; it provides visibility into data theft where attackers copy the NTDS database.)

• Alert: New service account created with high privileges and immediate activity.

(Monitor this via SIEM with Active Directory event logs, particularly Event IDs: 4720, 4728, and 4732.)

• Alert: Sudden burst of outbound traffic from a DC to an external IP.

(Monitor this through your network security tools or firewall logs; Domain Controllers have little to no communication with external systems, so any jump in traffic should definitely get your attention)

These alerts are not perfect, but they will catch many common attack attempts.

Why service desk and social tricks matter

Some high-profile incidents illustrate that an attacker does not always need a technical exploit. An attacker could conduct social engineering against a help desk team to reset a password or approve access. If a service desk has high privileges and a weak verification process, they can leverage that account to escalate their privileges to an admin level and exfiltrate NTDS.dit. Help desks should tighten their verification, log every account reset for auditing, and limit the privileges of service desk accounts. 

A simple checklist you can run today

Use this short list to check your readiness now:

• Who has access to log on to DCs? Limit to only the most essential accounts. 
• Have you prepared admin workstations that are isolated and hardened? (If not, make this your top priority.)
• Are backup files and DC snapshots disconnected and access-controlled? 
• Are you monitoring for executions of vssadmin, ntdsutil, and wbadmin on DCs?
• Is MFA required on all administrator and remote accounts?
• Do you centrally log and collect DC event logs? 
• Have you exercised AD backups and practiced restoration in the last 90 days?
• Can your help desk verify identity before resetting passwords? If not, reconsider that process. 

If you answered “yes” to most of these, your NTDS.dit theft exposure has been greatly reduced.

How Lepide Helps

Lepide assists organizations in protecting their Active Directory from attacks, such as NTDS.dit theft, by providing visibility into the activity that occurs within AD. With Lepide Auditor, an organization can track every change inside AD in real-time to see who made the change, what was changed, and when it was changed. Any suspicious activity, such as shadow copies being created, privilege escalation, or resetting passwords on domain admin accounts, will generate alerts that allow your team to respond quickly before a breach takes place.

The Lepide Active Directory Security Tool provides visibility into permissions and group memberships so that it is easy to identify the accounts that have unnecessary or excessive rights. This visibility enables organizations to operate under the principle of least privilege, which reduces the attack surface across an organization’s AD environment.

Lepide also enables you to track strange login behavior, failed login attempts, or the creation of new service accounts with its threat detection features. These alerts allow organizations to identify compromised accounts early, often before the attackers can get deeper into the organization’s network.

Additionally, Lepide helps automate regular AD cleanup and auditing, flagging inactive users and unused objects that could otherwise become backdoors. With built-in reports for compliance standards like ISO, GDPR, and HIPAA, security and audit teams can quickly demonstrate that AD activities are being monitored and controlled effectively.

Conclusion

Stealing NTDS.dit is not a new trick, but it continues to be one of the quickest methods for an attacker to take over an organization completely. Most breaches do not happen because the organization does not care, but rather because AD is vast, established, and complicated. If you consider limiting Admin rights, securing Domain controllers, monitoring for change,s and/or implementing necessary tools, your A.D. breach potential can drop considerably.

As a reminder, the quicker you can detect unusual activity in AD environments, the quicker you can stop a full domain compromise. Do not wait for evidence that someone has stolen or compromised your Active Directory structure; make the appropriate adjustments to gain visibility to prevent it from happening.

If you want to discover how you can audit, detect, and secure your Active Directory, download the free trial or schedule a demo with one of our engineers today.