NTDS.dit Theft

Also calledNTDS dump, Directory database copy

Copies a domain controller's database to read every account's keys, krbtgt's included.

Technique: MITRE ATT&CK T1003.003: OS Credential Dumping: NTDS (opens in a new tab)
Needs: Code on a DC
Gives: krbtgt KeyandNT HashandAES KeyandService Key

How the Attack Works

Every writable domain controller keeps every account's NT hash and Kerberos keys, krbtgt's included, in its database file, NTDS.dit, encrypted with a key held in its SYSTEM hive. The directory keeps the file locked while it runs, yet Windows' own tools can copy it, from a volume shadow copy or as an install-from-media backup. Whoever holds a copy and the SYSTEM hive can read every key offline, password history included, without touching the domain again.

Read first Password Hashes and Kerberos Keys, AS Reply: The TGT

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

With Domain Admin rights, a copy of dc-01's database is made, taken off the DC and read offline.Step through it

dc-01 Domain controller

krbtgt key
dana's key
srv-fin-01 key

ws-042 Foothold

Offline

Step 1 of 3, Database Copied, on dc-01
Step 2 of 3, Files Taken off the DC, dc-01 to ws-042
Step 3 of 3, Every Key Read, on Offline

Step 1 of 3: Database Copied
On dc-01 Domain controller
NTDS.dit is copied from a volume shadow copy or an install-from-media backup, with the SYSTEM hive.
Logged
- 216, 325, 326 and 327 A database location change was detected, The database engine created a new database, The database engine attached a database, The database engine detached a database
  On dc-01, in the Application log
  The database engine opening or creating ntds.dit in a shadow copy or a temporary folder
- 4688 A new process has been created
  On dc-01, in the Security log When enabled
  ntdsutil.exe or vssadmin.exe starting on a DC, and the account that started it
What Defenders See
On dc-01, the Application log shows ESENT events 216 and 325 to 327 naming ntds.dit in a shadow copy or temporary folder. A new shadow copy appears, and the Security log shows event 4688 for ntdsutil.exe or vssadmin.exe.
Step 2 of 3: Files Taken off the DC
dc-01 Domain controller to ws-042 Foothold
The copy of NTDS.dit and the SYSTEM hive leave dc-01 for the foothold.
Logged
- 5145 A network share object was checked to see whether client can be granted desired access
  On dc-01, in the Security log When enabled
  The share and file path read, and the address that read them
What Defenders See
Network data shows large SMB reads from dc-01 by ws-042, a workstation, and Defender for Identity raises its Data exfiltration over SMB alert. Where Detailed File Share auditing is on, the Security log on dc-01 shows event 5145.
Step 3 of 3: Every Key Read
Offline, away from the network
Every account's NT hash and Kerberos keys come out, krbtgt's and every computer account's included.
Keys
- Offline now holds krbtgt key (new at this step) dana's key (new at this step) srv-fin-01 key (new at this step)
What Defenders See
No log on any machine in the domain records this step, because it happens offline.

Needs First

What the attacker must already hold for this attack to be possible.

Code on a Domain ControllerAdmin code on a DC, from Domain Admins or Backup Operators, or a copy of its disk or backup.

Comes From

Code on a DC: Golden Ticket, Diamond and Sapphire Tickets, Certificate Services Abuse, noPac (sAMAccountName Spoofing) every attack that gives it: Code on a Domain Controller

Gives the Attacker

What running it hands the attacker to use next.

The krbtgt KeyThe krbtgt key, which forges TGTs for any account, such as golden and diamond tickets.
An NT HashEvery account's NT hash, for pass-the-hash as any account still allowed NTLM.
An AES KeyEach account's Kerberos AES keys, where it has them, for overpass-the-hash.
A Service's KeyEvery service and computer account key, for silver tickets to any service.

Leads To

krbtgt Key: Golden Ticket, Diamond and Sapphire Tickets, DCShadow
NT Hash: Pass-the-Hash, Overpass-the-Hash
AES Key: Overpass-the-Hash
Service Key: Silver Ticket

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
216, 325, 326 and 327 `A database location change was detected, The database engine created a new database, The database engine attached a database, The database engine detached a database` (opens in a new tab) Application log	The computer the database is opened or copied on, usually a domain controller	ntds.dit named in a shadow copy path or a temporary folder, the database engine building a copy outside C:\Windows\NTDS.	Always written
4688 `A new process has been created` (opens in a new tab) Security log	Every Windows computer, domain controllers included	ntdsutil.exe, vssadmin.exe or another shadow copy tool started on a DC, and the account that started it.	Audit Process Creation, with Include command line in process creation events also on to record the command line
5145 `A network share object was checked to see whether client can be granted desired access` (opens in a new tab) Security log	The server that holds the share, named pipes on IPC$ included	A workstation reading files on a DC's shares that look like ntds.dit or a copy of the SYSTEM hive.	Audit Detailed File Share

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Data exfiltration over SMB (opens in a new tab)Raised when data such as ntds.dit is copied off a DC over SMB.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

A copy taken from a DC's backup, or from its virtual disk on the host, never touches the DC and logs nothing there. Guard those as you guard the DC.
ESENT events show the database engine opening a copy, as ntdsutil does, not where the copy went, so pair them with shadow copy creation and file reads on DCs.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyDeviceFileEvents

Needs Defender for Endpoint on every DC. A hit shows a copy written, which install-from-media builds also do. Whether it then left the DC shows in Defender for Identity's exfiltration alert.

KQLDefender XDR, Advanced hunting

// ntds.dit written anywhere outside C:\Windows\NTDS: a copy of the directory databaseDeviceFileEvents| where Timestamp > ago(30d)| where FileName =~ "ntds.dit"| where not(FolderPath startswith @"C:\Windows\NTDS\")| project Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName| order by Timestamp desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Least-privilege administration (opens in a new tab)
Keep Domain Admins and Backup Operators nearly empty, since every member can copy the database.
Hardened domain controllers (opens in a new tab)
Guard DCs, their backups and, for virtual DCs, their hosts and storage as tightly as the database itself.
Tiered administration (opens in a new tab)
Let DC admin accounts sign in only to DCs and their own admin workstations.
krbtgt password reset (opens in a new tab)
After any copy, reset krbtgt twice and every other password, since every key in the copy is known.

How the Attack Works

How It Plays Out

Step 1 of 3: Database Copied

Step 2 of 3: Files Taken off the DC

Step 3 of 3: Every Key Read