Where to look 🔎
Someone may have copied the AD database using Volume Shadow Copy (VSS). Four files to work with: SYSTEM.evtx, SECURITY.evtx, Microsoft-Windows-NTFS.evtx, and $MFT.
Here’s the lookup table I’d want beside me next time:
| What am I looking for? | Open this | Check |
|---|---|---|
| When did VSS start? | System log, Service Control Manager, 7036 | Volume Shadow Copy entering the running state |
| Which account and process enumerated groups? | Security log, 4799 | VSSVC.exe, caller PID, machine account such as DC01$, Administrators / Backup Operators |
| Was a shadow volume mounted? | Microsoft-Windows-NTFS log | Device name, volume correlation ID, mount/dismount messages |
| Where did the copied database land? | $MFT | NTDS.dit, destination directory, timestamps, nearby registry hive copies |
Small gotcha: 4799 means local groups were enumerated. It doesn’t tell me someone escalated privileges or who was behind DC01$. Also, convert hex PIDs before matching them against decimal ones. Event docs.
Bits worth keeping 📌
- VSS started:
2024-05-14T03:42:16.7831058Z. - Shadow-copy device:
\Device\HarddiskVolumeShadowCopy1. - Usual database location:
C:\Windows\NTDS\NTDS.dit. - Staging-path example I wrote down:
C:\Users\Administrator\Documents\backup_sync_Dc\Ntds.dit. Still needs an MFT check before calling it the confirmed path. - Look for a
SYSTEMhive copy nearby. VSS starting on its own could just be a normal backup.
The flow in my notes:
Staging directory → VSS starts → machine-account group enumeration
→ shadow copy mounted → NTDS.dit and SYSTEM copied → shadow copy dismountedNTFS IDs I kept: 4 (mount), 9/10 (volume stats), 300/303 (dismount). Read the provider and message too; the number alone isn’t enough.
Note to self
Service → account/process → shadow volume → copied files. That’s the order to follow.
Use XML SystemTime for UTC and check the parser’s timezone before comparing MFT timestamps. I saved the exact VSS start, but not the times for the rest of the chain.