The ESENT Trail Left Behind When NTDS.dit Walks Out the Door

A domain controller landing in my triage queue is never the part of the shift I look forward to. When one does, the first question I ask isn’t whether somebody dumped credentials. It’s whether they touched ntds.dit, and if they did, where they left the smudge. That single file is the whole directory: every account, every hash, every trust relationship. In ATT&CK terms it’s T1003.003, and it’s one of the few credential-access techniques where the boring Windows plumbing is firmly on our side.

The thing people forget is that ntds.dit is an Extensible Storage Engine database. It’s the same JET engine that backs a bunch of Microsoft products, and that engine is chatty. It writes its own events to the Application log whether or not you asked it to. So an attacker who copies the AD database off a DC is quiet on the network but leaves a paper trail in a log nobody watches. Our job is to start watching it.

The four ways I usually see it happen

There’s a small menu of methods, and each one has a slightly different fingerprint. A shadow copy plus a file copy is the classic: run vssadmin create shadow /for=C:, then copy ntds.dit and the SYSTEM hive out of the snapshot path. The vssadmin route is old but it still works on Server 2022 and it still shows up on real DCs. The second is ntdsutil with its “IFM” (Install From Media) mode, which is a supported admin feature that happens to snapshot the database and drop a clean copy wherever you point it. The third is diskshadow driving the same VSS machinery from a script. The fourth is esentutl abused to copy the locked file directly.

I’m deliberately leaving DCSync out of this one. Pulling hashes over the replication protocol is a different beast with a different trace (Directory Service Access, Event ID 4662, with the replication GUIDs). This post is about someone grabbing the file itself.

Where the ESE engine writes it down

Here’s the part I wish more people knew. When ntds.dit gets copied, snapshotted, or mounted somewhere it doesn’t normally live, the ESE engine notices, and it writes to the Application log under the source “ESENT”. The events I key on are 325 (the engine created a new database), 326 (attached a database), and 327 (detached a database). There’s also 216, which flags a database location change. On a healthy DC the ntds instance attaches once at boot and stays put, so a fresh 325 or 326 pointing at a path like C:\Temp\Active Directory\ntds.dit is not something normal operations produce. That path in the event detail is the tell. It’s the attacker naming the folder they staged the copy into.

In my lab, a Server 2022 DC running an ntdsutil IFM export dropped a tidy little cluster of 327 and 326 events referencing the export directory. The vssadmin-then-copy path is quieter on ESENT because you’re copying a frozen snapshot rather than mounting it, so that method leans more on the VSS and process side. Which is the honest caveat here: no single log source catches all four methods. You want a couple of them stacked.

The process and shadow-copy side

This is where Sysmon earns its keep. Process creation (Event ID 1) for ntdsutil.exe, vssadmin.exe, diskshadow.exe, wbadmin.exe, or esentutl.exe on a domain controller is already a short list of things worth a second look, because none of those run on a DC during a normal Tuesday. Tie that to the command line and it gets sharp fast: ntdsutil with “ifm” or “create full” in the arguments, vssadmin with “create shadow”, esentutl with /y or /vss. File creation (Event ID 11) writing a file literally named ntds.dit outside C:\Windows\NTDS\ is about as close to a smoking gun as file telemetry gives you.

If you run object-access auditing with a SACL on the NTDS folder, Event ID 4663 will show you the handle opens against ntds.dit too, though I’ll be honest, most shops don’t have that SACL configured and it’s noisy to stand up. I treat it as a nice-to-have, not the primary catch.

Turning it into detections

I don’t build one giant rule for this. I build three narrow ones and let them corroborate. The first watches the Application log on DCs for ESENT 325, 326, or 327 where the referenced path is anything other than the real NTDS directory. The second watches Sysmon Event ID 1 on DCs for that short list of process names with the incriminating arguments. The third watches Sysmon Event ID 11 for a file named ntds.dit created anywhere off the golden path. Any one of them firing is worth a look. Two firing inside the same few minutes on the same host is an incident, not an alert.

Modern EDR closes some of this for you. Defender for Endpoint ships built-in logic around sensitive AD database access, and on MDE-covered DCs I’ve seen it flag the file copy on its own. I still keep my own rules running, partly because coverage gaps happen during onboarding and sensor outages, and partly because I want the ESENT angle, which the EDR doesn’t always surface in a way I can pivot on.

The false positives you’ll actually hit

Backups are the big one. A DC being backed up by a VSS-aware agent will generate shadow copies and can touch the ESE engine in ways that look adjacent to what an attacker does. The difference is context: your backup agent runs on a schedule, from a known service account, writing to a known destination, and it does this every single night. Tune the ESENT rule to exclude the backup software’s staging path and the noise mostly evaporates. Genuine DC promotions and demotions will also light up ntdsutil, so if your build pipeline stands up DCs with automation, allowlist that host and that window. Everything left over after those two exclusions has been worth reading, in my experience. Not always malicious, but always worth reading.

Two closing notes. This technique is loud only if you’re collecting the Application log off your domain controllers, and a surprising number of SIEM pipelines quietly drop it to save license volume. Check that first. And if you want to walk the credential-access story further, the ProcDump and Task Manager LSASS writeup covers the memory side of the same goal, while the blue-side Kerberoasting detection covers what an attacker reaches for when they can’t get to the DC at all.