Why this matters

MITRE ATT&CK describes T1003.003 (OS Credential Dumping: NTDS) as adversaries accessing or creating a copy of the Active Directory domain database to steal credential information, along with details about users, devices and access rights. By default the file is %SystemRoot%\NTDS\Ntds.dit on a domain controller, and MITRE notes adversaries may also look for backups containing the same data.

From our own knowledge (MITRE does not say this), the live file is locked while Active Directory runs, so attackers need a way around the lock. The common routes leave distinct traces, which is what the rules below target. We cover the closely related replication technique separately in our DCSync detection guide.

The four common extraction routes

MITRE names Volume Shadow Copy, ntdsutil, secretsdump and esentutl among the tools used. The exact command syntax, and the diskshadow and WMI variants below, are from the author’s knowledge. The rules in this article have not been run against live telemetry, so test and tune them before production use.

  1. ntdsutil IFM: ntdsutil "activate instance ntds" ifm "create full C:\Temp\x" quit quit writes a copy of the database and registry hives for “install from media”.
  2. Volume Shadow Copy: create a shadow copy with vssadmin create shadow /for=C: (or WMI or diskshadow), then copy Windows\NTDS\ntds.dit and the SYSTEM hive out of the snapshot path.
  3. esentutl: esentutl.exe /y /vss C:\Windows\NTDS\ntds.dit /d C:\Temp\n.dit copies the database through the shadow copy mechanism.
  4. Remote tooling: tools such as Impacket’s secretsdump can pull the same data remotely, which, in our understanding, shows up as the above activity on the DC or as replication (the DCSync case).

Sigma rule: process command lines

title: NTDS.dit Extraction via ntdsutil, vssadmin, esentutl or diskshadow
id: 6f1c2f4e-5b0a-4c55-9e0e-3d7a1f9a0b11
status: experimental
description: Detects command lines commonly used to copy the Active Directory database
logsource:
  category: process_creation
  product: windows
detection:
  ntdsutil_ifm:
    Image|endswith: '\ntdsutil.exe'
    CommandLine|contains|all:
      - 'ifm'
      - 'create'
  vss_create:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all:
      - 'create'
      - 'shadow'
  esentutl_copy:
    Image|endswith: '\esentutl.exe'
    CommandLine|contains:
      - 'ntds.dit'
      - '/vss'
  diskshadow_script:
    Image|endswith: '\diskshadow.exe'
  ntds_copy:
    CommandLine|contains|all:
      - 'ntds.dit'
      - 'copy'
  condition: 1 of them
falsepositives:
  - Domain controller backup software and scheduled VSS-based backups
  - Administrators performing IFM promotion of a new domain controller
level: high
tags:
  - attack.credential_access
  - attack.t1003.003

Microsoft Sentinel / Defender KQL

let dcs = dynamic(["dc01", "dc02"]);   // replace with your domain controller names or a watchlist
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName has_any (dcs)
| where (FileName =~ "ntdsutil.exe" and ProcessCommandLine has_all ("ifm", "create"))
   or (FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("create", "shadow"))
   or (FileName =~ "esentutl.exe" and ProcessCommandLine has_any ("ntds.dit", "/vss"))
   or (FileName =~ "diskshadow.exe")
   or (ProcessCommandLine has "ntds.dit" and ProcessCommandLine has_any ("copy", "xcopy", "robocopy"))
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Populate dcs from your own domain controller inventory so the rule only runs where the NTDS database lives.

File-level view: a copy of ntds.dit written anywhere other than the live path is suspicious. This query matches the file name only, so a renamed copy (such as n.dit in the esentutl example) is missed; the process rules above cover that case.

DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName =~ "ntds.dit" and ActionType in ("FileCreated", "FileRenamed")
| where not(FolderPath startswith @"C:\Windows\NTDS")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessCommandLine, FolderPath

Splunk SPL

Using Windows Security 4688 with command-line auditing, or Sysmon Event ID 1:

index=wineventlog (EventCode=4688 OR source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
| eval cmd=coalesce(CommandLine, Process_Command_Line)
| eval img=lower(coalesce(Image, New_Process_Name))
| where (like(img,"%ntdsutil.exe") AND like(lower(cmd),"%ifm%") AND like(lower(cmd),"%create%"))
   OR (like(img,"%vssadmin.exe") AND like(lower(cmd),"%create%") AND like(lower(cmd),"%shadow%"))
   OR (like(img,"%esentutl.exe") AND (like(lower(cmd),"%ntds.dit%") OR like(lower(cmd),"%/vss%")))
   OR like(img,"%diskshadow.exe")
| table _time host user img cmd

Field names differ between the Security log and Sysmon add-ons, so confirm the extracted fields in your environment.

Supporting telemetry

  • Sysmon Event ID 11 (file create): ntds.dit or *.dit created outside C:\Windows\NTDS.
  • Windows Security 4688: requires process creation auditing and “Include command line in process creation events” enabled by policy.
  • Shadow copy creation on a DC outside your backup window is rare enough to alert on by itself.
  • Staging and exfiltration: follow-on archive creation (7z, rar, tar) of the extracted files or outbound transfers from a DC.

Tuning and response

All three process rules alert on any diskshadow.exe execution, since the script file is not visible on the command line in every case. Expect more noise from backup tooling than from the other branches. Attackers can also abbreviate ntdsutil sub-commands, which a rule requiring the literal word create would miss (our suggestion: add the abbreviated forms after testing).

Baseline first: backup agents legitimately create shadow copies and may invoke vssadmin or diskshadow. Allow-list by parent process, service account and schedule, not by command alone. Treat a hit on a domain controller from an interactive or remote-shell session as high priority.

If confirmed, assume all domain credentials are compromised. Our assessment is that this requires a coordinated response: isolate the DC and the staging host, preserve the extracted files for scoping, reset the krbtgt account twice with appropriate gap, rotate service account and privileged credentials, and hunt for persistence such as Golden Tickets.

References