Protecting NTDS.dit From Credential Theft (T1003.003)

NTDS (T1003.003) is a credential access sub-technique for Windows. Adversaries try to access or copy the Active Directory domain database to steal credential information, and to learn about domain members such as devices, users and access rights. By default the file sits at %SystemRoot%\NTDS\Ntds.dit on a domain controller.

This is the single most valuable credential file in a Windows domain. Protecting it is not optional.

How attackers use it

MITRE lists the techniques at a high level: Volume Shadow Copy, secretsdump.py, the built-in ntdsutil.exe utility, and Invoke-NinjaCopy. A common thread is that the live file is locked, so the approaches work around that by taking a copy through a snapshot or by reading the volume directly.

MITRE also points out that adversaries do not only look at live domain controllers. They search for backups that contain the same or similar information. A backup that anyone can read is as good as the database.

How to detect it

MITRE's analytic focuses on three signals on domain controllers:

• Shadow copy creation.
• Suspicious access to the NTDS.dit file path.
• Use of ntdsutil.exe or volume management APIs.

Sources to use:

• Process creation events with command lines on every domain controller. Few administrators run ntdsutil or vssadmin on a DC outside of planned maintenance, so each hit is worth a ticket.
• File auditing on the NTDS folder, with exceptions for the directory service itself and your backup agent.
• Volume shadow copy events and service starts related to the volume shadow copy service.
• Access logs on wherever you keep Domain Controller backups.

Treat any unscheduled shadow copy on a domain controller as an incident until proven otherwise.

How to reduce the risk

MITRE lists these mitigations:

• Encrypt Sensitive Information: ensure Domain Controller backups are properly secured. Encrypt them, restrict who can read them, and store them away from general file shares.
• Password Policies: complex, unique local administrator passwords across systems.
• Privileged Account Management: do not put domain accounts into local administrator groups across systems unless tightly controlled, and follow administrative tiering so privileged accounts log on only to the systems they manage.
• User Training: do not reuse passwords across accounts.

Add an operational rule that is not on MITRE's list but follows from it: keep the number of people who can log on to a domain controller small and named.

Why domain controllers need their own rules

A domain controller is not a normal server. It holds the identity data for everything else. Give it stricter rules than anything else you run:

• No browsing, email or general admin tooling on it.
• A short, named list of accounts that can log on.
• Administration from dedicated admin workstations, not from the servers people use for everyday work.
• Tight outbound filtering. A domain controller has little reason to reach the internet.

With rules this strict, detection gets easier. Almost anything unusual stands out, because the baseline is so small.

Backups deserve the same care

MITRE's attention to backups is a hint about priorities. Backup systems often have wide access, and their data is often readable by many administrators. Ask who can restore a domain controller backup, who can mount it, and where copies live. If the answers are wider than for the domain controller itself, tighten them. Encrypt backups, separate the keys from the media and log every restore.

If you suspect a copy of the database left

The response is large because the exposure is the entire directory. Prepare it in advance. A plan includes rotating the highest-value secrets in a safe order, resetting privileged accounts, planning for the Kerberos ticket granting account, and checking for persistence. Many teams rehearse it in a test environment so the steps are known. Do not discover the sequence during an incident.

Check your own environment

• Who can log on locally or through remote desktop to your domain controllers? Write down the list and check it against the people who should.
• Where are DC backups stored, and who can read them?
• Do your DCs log process creation with command lines?
• Does anyone review shadow copy activity on DCs?

To see current shadow copies on a Windows host, run this read-only command from an elevated prompt (vssadmin):

vssadmin list shadows

On a domain controller, shadows you cannot explain, or that appear outside your backup window, deserve follow-up.

Quick check

Sources

• MITRE ATT&CK T1003.003: NTDS