What a Ransomware Case Taught Me About the Risks of NTDS.dit

The NTDS.dit file is the database of an Active Directory domain — essentially the gold vault of your kingdom, a core component of the domain, but also an often overlooked high-value target. In an unusual environment, when an attacker can reach this file, they have already compromised your domain. In my case, the attackers exploited a less common but quite effective path: pulling the NTDS.dit from an unprotected backup.

In this post, I'll explain what NTDS.dit is, why this file matters, and how to better harden your environment — through the lens of a real ransomware case I worked on. In that incident, attackers quietly pulled the file from a backup, cracked a weak password, and used an existing user account to escalate privileges and move laterally, all without triggering alerts.

We'll break down what the file contains, how it's typically accessed, the path attackers took, and what practical steps you can take to defend your domain.

What Is NTDS.dit, and Why Should You Care?

The NTDS.dit file is the main Active Directory database used by NT Directory Services, introduced with Windows 2000. It contains critical domain information, including:

• Accounts and computer objects, including usernames, SIDs, and legacy attributes
• Group objects and membership relationships
• Password hashes for all domain accounts (NT hashes based on MD4, and legacy LM hashes if enabled)
• Kerberos authentication secrets, including the krbtgt account hash used to sign Kerberos tickets
• Replication metadata to synchronize domain controllers (USNs, timestamps, etc.)

This file serves as a database used throughout the domain. In most cases, if someone obtains this file, they already have access to your domain.

Typically, NTDS.dit is accessed from a domain controller by high-privileged accounts, such as Domain Admins or SYSTEM. However, if you left your backups on a file server in a public folder and a threat actor compromises a user's system and finds those files — they can quietly extract the required files to crack the hashes.

The only two files needed are NTDS.dit and the SYSTEM registry hive (which contains the encryption key). With both in hand, they can dump all domain password hashes offline, with no logons, no service creation, and no detectable activity. Just a complete list of users, computers, groups, and credentials ready to crack.

Theory Meets Reality: Active Directory 101 Didn't Cover This

This is precisely the kind of scenario that quietly unfolded during the early stages of an attack I found myself involved in. At the time, we didn't realize it, but access to a backup VHD containing the domain controller appeared to be part of the attackers' reconnaissance. Not long after that backup was touched, we began seeing valid logins from long-unused Active Directory accounts that had never been disabled.

While I couldn't confirm exactly how those credentials were obtained, the timing strongly pointed to offline extraction from that backup — likely involving the NTDS.dit file and SYSTEM hive. From there, the attackers moved laterally, escalated privileges, and staged additional attacks. By the time the final payload was deployed, nearly every server and most workstations were compromised.

As part of a post-incident review, I retraced their steps to understand their methods and where we went wrong. This experience taught me that protecting Active Directory isn't just about access — it's about safeguarding everything that interacts with it, especially backups.

To Understand the Enemy, You Must First Become the Enemy

Now that you know what NTDS.dit is, let's look at why it's so dangerous. To demonstrate how easy it is to misuse, I spun up a test environment with a few fake user accounts and security groups.

Extracting NTDS.dit from a live system differs from an offline one. From a live system, a domain admin can extract it with a simple command:

Warning: Modern EDRs worth their salt will quarantine you for this command. Do not run on a machine you cannot access physically.

Extracting these files from a backup image — like one created using VSS (Volume Shadow Copy) — is even easier, as no credentials are then needed. The files can be found at C:\Windows\NTDS and C:\Windows\System32\Config\SYSTEM, respectively.

Once you have those two files, you can pass them through tools like secretsdump.py to extract the details.

No Login Required: Just Add the Boot Key

With an extracted NTDS.dit and a copy of the SYSTEM registry hive, external tools let you crack it open and see what's inside. In my test environment, using ImPacket Python tools, I ran a few simple commands to view the contents.

The output shows a copy of the user accounts found. The general format per line is:

• Domain\User
• RID
• LM Hash (legacy, used in older versions of AD)
• NT Hash

The LM hash is showing a default value, which is expected unless you're on a legacy domain controller. What matters is the NT Hash. I set one account with a straightforward password on purpose — the others use Microsoft's security requirements, which you won't find in a hash database.

Taking that hash and running it through a HashMap, we get a match.

In this test case I don't have any computer account objects — but imagine if I did. An attacker could use those to map out the domain's computer objects and identify potential targets. While computer account passwords are effectively uncrackable (long, randomly generated values), the hostnames themselves reveal servers and workstations that can be probed for remote access or lateral movement.

In just a few minutes, I had enough data to enumerate users, password hashes, hostnames, and security groups — complete visibility into the domain, without triggering any meaningful alerts, logons, or high-confidence security events that an XDR or SIEM would typically flag. All from two small files.

Crack Prevention 101: Don't Be That Domain

In my incident, you can see some obvious security standards that were not followed. Even with five years of experience, I've seen far too many environments fall into this same avoidable trap:

• Backups stored on a general file server — due to budget constraints, legacy decisions, or oversight
• Backups not encrypted — just never considered
• User account passwords with no complexity — common, way too common
• Invalid network share permissions — shares not completely locked down
• No event alerts or SIEM events — simple event logging would have caught these actions

Here are everyday steps you should take to harden your domain. These are simple actions you can start doing today.

Regular Cleanup of Active Directory Accounts

Employees leave the company, but their accounts remain active or are left in place "just in case." Regularly reviewing and disabling unused accounts is critical. In my case, had every AD account been properly reviewed and retired, the attackers wouldn't have had access to an unused account for lateral movement.

BitLocker, Encrypted Backups, and Isolation

All servers (and workstations — it's 2025) should be using BitLocker full disk encryption. Backups should also be isolated in a near-DMZ environment so they cannot be easily compromised. Encryption at rest is non-negotiable.

Enforce Password Complexity

Active Directory has the capacity for complex password requirements. Your users don't need to change passwords every other day, but modern policies should be followed so accounts can't be instantly compromised from simple rainbow tables or hash lists.

Alert Monitoring and Group Change Auditing

The Windows event log is extensive and powerful. Use a SIEM to back up your logs and watch for suspicious commands. Simple event tracking — unusual group membership changes, privileged account logons at unusual hours, and commands like ntdsutil and vssadmin — should always be reviewed and understood.

Summary

The NTDS.dit file holds the keys to your entire Active Directory domain, but it's not a file most admins think much about until it's already too late. I shared how I came to understand just how dangerous this file can be, after seeing it quietly pulled from a backup during the early stages of an attack. Even without touching a live domain controller, the attackers were able to extract credentials, escalate privileges, and map the domain.

The lesson? NTDS.dit may not be an obvious target, but in the right hands — and the wrong environment — it can lead to full domain compromise. Treat your backups like production data: encrypt them, isolate them, and never assume they're safe just because they're offline.