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

NTDS.dit: The Critical File I Never Thought Would Be Exploited

The NTDS.dit file is the database of an Active Directory domain, essentially the gold vault of your kingdom, a core component in a domain, but also an often overlooked HVT. In an unusual environment, when an attacker can reach this file, they have already compromised your domain, but 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 (Otherwise known as Windows NT). It contains critical domain information, including:

• Accounts and computer objects, including usernames, security identifiers (SIDs), and legacy attributes
• Group objects and membership relationships
• Password hashes for all domain accounts (typically 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, the NTDS.dit file is accessed from a domain controller by high-privileged accounts, such as Domain Admins or SYSTEM. However, if you were unfortunate enough to leave your backups on a file server in a public folder, and a threat actor compromises a user's system and finds these files. They can quietly extract the required files to crack the hashes.

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

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 and prep work. 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, effectively bringing operations to a halt.

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 the NTDS.dit file is, let's look at why it's so dangerous. To demonstrate how easy it is to misuse, I spun up a test environment. Created a few fake user accounts and some security groups.

To extract the NTDS.dit file from a live system is different from an offline system. From a live system, we can extract this as a domain admin with a simple command like,

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, but an attacker is most likely going to try to extract the entire VHD so they can safely analyze it. The files can be found in C:\Windows\NTDS and C:\Windows\System32\Config\System, respectively.

Once you have extracted these two files, you are then able to pass them through other tools to extract the details, like secretsdump.py

No Login Required: Just Add the Boot Key

Now with an extracted NTDS.dit , and a copy of the system registry hive, using external tools, you can crack it open and see what is under the hood. In my test environment; using ImPacket Python tools, which include an example copy of secretsdump.py, we can run a few simple commands to view the contents.

In this image, we are seeing a copy of the user accounts found. The general format is

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

With this output, we are able to see the LM hash is using a default value, which is expected unless you're on a legacy domain controller. What we will do instead is look at the NT Hash. If you were to look specifically at this account highlighted, I set it with a straightforward password on purpose; the others use Microsoft's security requirements which you won't find sitting in a hash database.

If we take that hash and put it through a HashMap, we are able to find 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 (they use long, randomly generated values), what's valuable here isn't the password, it's the hostname. From that, an attacker could identify servers and workstations and begin probing for remote access or lateral movement opportunities.

In just a few minutes, I had enough data to enumerate users, password hashes, hostnames, and security groups. I had complete visibility into the domain, and I did it 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 poor 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 are on a file server? Why? Budget constraints, legacy decisions, or oversight.
• Backups are not being encrypted? Just never considered as an option.
• I had a user account password that had no complexity. Common, way too common.
• Invalid network sharing. Network shares are not being completely locked down.
• No event alerts or SIEM events. Simple event logging would have caught these actions, but for some reason, nobody set it up.

Here are some everyday steps you should take to harden your domain and increase security. While my incident was a specific case, the underlying issues are common and preventable. These are simple actions you can (and should) start doing today.

Regular cleanup of Active Directory user accounts

This is a problem I see far too often: employees leave the company, but their accounts remain active or are left in place “just in case.” Sometimes they're kept for archiving and then forgotten. 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 user account, which may have triggered alerts or blocked their lateral movement entirely.

BitLocker, encrypted backups, and isolation.

All servers (And workstations, it is 2025!) should be using BitLocker full disk encryption. This will protect your drives, and server BitLocker will help keep your VSS copies secure. The backups should also be isolated on a different, almost DMZ for the backups, so they cannot be easily compromised.

Password complexity rules should be in place.

Active Directory has the capacity for complex requirements. Your users do not need to change their passwords every other day, but modern password policies should be followed so they cannot be instantly compromised from simple rainbow tables or hash lists.

Alert monitoring & group changes.

The Windows event log is extensive and profound. Using a SIEM system to back up your logs, and also watching these event logs for questionable commands, like using an XDR (Extended Detection & Response) along with a SIEM (Security Information and Event Management) to keep records of machines to help build logs, and possible cases. Simple event tracking, like unusual group membership changes, privileged account logon at unusual hours, and commands like ndsutil and vssadmin, should always be read 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. In this post, 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 not online.