In this very easy sherlock, you will learn how to detect NTDS.dit dumping which is one of the most critical Active directory attacks. You will get your hands on event logs and MFT to respond to an attack where the attacker utilized vssadmin utility to dump the NTDS.dit database.
An attacker on a domain controller used vssadmin to create a volume shadow copy, which started the Volume Shadow Copy service and made it enumerate the privileged local groups under the machine account. The snapshot was mounted as a shadow volume, and the locked Active Directory database was copied out of it. About two minutes after the service started, a copy of the database and a copy of the SYSTEM hive were sitting in a folder under the Administrator profile. Together those two files are everything needed to extract every domain credential offline.
SYSTEM.evtx → parse with EvtxECmd, filter the CSVSECURITY.evtx → parse with EvtxECmd, filter the CSV$MFT → parse with MFTECmd, filter the CSVTimestamp note: Questions want
YYYY-MM-DD HH:MM:SS. The MFT CSV carries 7 decimal places, so cut the fraction rather than rounding.
Parse the event logs to CSV first, then grep the System log output for shadow. The Service Control Manager event 7036 records the Volume Shadow Copy service moving to the running state, and that line is the start of the snapshot activity.
EvtxECmd -d evidence --csv work/evtxgrep -i shadow work/evtx/system.csvPivot to the Security log around the Q1 time and look at event 4799, a security-enabled local group membership enumeration. The calling process is VSSVC.exe, it enumerates two groups, and the subject is the domain controller’s machine account, which fits the service validating privileges as the machine rather than as a user. The answer wants the account name without the domain prefix.
grep 4799 work/evtx/security.csvThe same 4799 events carry the caller process ID for VSSVC.exe as hex, so convert it to decimal for the answer.
grep 4799 work/evtx/security.csvGotcha: The log shows the PID in hex (
0x1190) but the question wants decimal.
The NTFS log records the snapshot mount as an event 4 for HarddiskVolumeShadowCopy1. Find that row in the CSV and read its payload. The VolumeId field in the payload is empty, so the GUID that identifies the snapshot is in VolumeCorrelationId.
grep -i shadowcopy work/evtx/ntfs.csvGotcha: The question says “Volume ID”, but the
VolumeIdfield is empty on this event. The value to submit is theVolumeCorrelationId.
The event logs show the snapshot but not where the copy landed, so switch to the MFT. Search the parsed $MFT for ntds; the copy sits in a backup_sync_dc folder under the Administrator profile, well away from the legitimate NTDS folder.
MFTECmd -f '$MFT' --csv work/mft --csvf mft.csvgrep -i ntds work/mft/mft.csvTake the Q5 entry and read its $STANDARD_INFORMATION creation time (Created0x10). It lands about two minutes after the service started in Q1, which fits a dump run straight after the snapshot.
python3 -I filter_mft.py work/mft/mft.csv # rows for ntds.dit / SYSTEM created 2024-05-14 03:4xLook at the other files created in the same folder in the same minutes. A SYSTEM hive appears about twenty seconds after the database. It matters because the boot key inside it is needed to decrypt the secrets in ntds.dit. Read the size from the file size column of the MFT row.
python3 -I filter_mft.py work/mft/mft.csv # same filter, SYSTEM row| Phase | Action |
|---|---|
| Credential Access | Volume Shadow Copy service starts on the domain controller after a vssadmin snapshot request |
| Credential Access | VSSVC.exe enumerates Administrators and Backup Operators as the machine account |
| Credential Access | Snapshot mounted as a shadow volume |
| Collection | ntds.dit copied to a folder under the Administrator profile |
| Collection | SYSTEM hive copied into the same folder |
| Type | Value |
|---|---|
| File | C:\Users\Administrator\Documents\backup_sync_dc\ntds.dit |
| File | C:\Users\Administrator\Documents\backup_sync_dc\SYSTEM (17563648 bytes) |
| Shadow copy correlation ID | {06c4a997-cca8-11ed-a90f-000c295644f9} |
| Process | VSSVC.exe, PID 4496 |
| Technique | ID | Description |
|---|---|---|
| OS Credential Dumping: NTDS | T1003.003 | vssadmin shadow copy used to copy ntds.dit off the domain controller |
| Data from Local System | T1005 | Database and SYSTEM hive staged in a folder under the Administrator profile |
Shadow copy creation on a domain controller should alert. SYSTEM event 7036 for the VSS service and the NTFS shadow volume mount are easy to correlate with a vssadmin process, and on a DC outside backup windows they are rare.
ntds.dit and a SYSTEM hive together outside the NTDS folder is a dump signal. The pair in a user’s Documents folder has no legitimate reason to exist. A file-creation rule on ntds.dit outside its default path catches this directly.
Event 4799 is a useful corroborating event. VSSVC.exe enumerating Administrators and Backup Operators as the machine account fits snapshot creation, but it is only logged if the audit policy for security group management is on.
Treat any exposed ntds.dit as a full domain credential compromise. Restrict who holds Backup Operators and administrative rights on domain controllers, and plan to reset every credential, including krbtgt, if a copy leaves the DC.
The attacker took the domain’s whole credential store using only a built-in utility, and left no malware behind. The signal was the shadow copy sequence and two files in the wrong folder.