HTB Sherlock: CrownJewel-2
On this page
- Task 1: When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process?
- Task 2: Identify the full path of the dumped NTDS file.
- Task 3: When was the database dump created on the disk?
- Task 4: When was the newly dumped database considered complete and ready for use?
- Task 5: Which event source provides database status data like creation and detachment?
- Task 6: Which two groups are enumerated by the ntdsutil.exe process? (alphabetical, comma space)
- Task 7: Using the Logon ID, find the time when the user logon session started.
- Timeline
- Detection notes
HackTheBox Sherlock, blue-team DFIR. NTDS.dit was dumped from a DC and I’ve got the event logs to reconstruct when and how. No shell, just artifacts and task questions.
The dump was done with ntdsutil.exe, the signed, built-in tool for backing up NTDS, which is exactly why attackers reach for it. It can’t copy ntds.dit while the DB is locked, so it spins up the Volume Shadow Copy Service to snapshot the volume first. VSS is the artifact trail.
Three logs carry the story: System (SCM service states), Application (ESENT database events), and Security (logons and privilege checks).
Task 1: When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process?
VSS going to the running state marks the snapshot, which starts right before ntdsutil gets the database. That’s Event ID 7036 (“service entered the running state”) from the Service Control Manager, in the System log.
Filtered System for Shadow Copy, took the most recent transition to running.
Event Viewer’s General tab shows local time; the box wants UTC. Details > System has the raw TimeCreated SystemTime in UTC. Read it off there.
Answer: 2024-05-15 05:39:55 (UTC)
Task 2: Identify the full path of the dumped NTDS file.
ntdsutil writes the snapshot copy of the database to a working directory, and the ESE engine logs that. Pivoted to the ESENT provider (Application log) and filtered for events right after the incident time.
Event ID 325 (“a new database was created”) had the destination path. The attacker dumped to a temp folder, not the real Windows\NTDS location.
Answer: C:\Windows\Temp\dump_tmp\Active Directory\ntds.dit
Task 3: When was the database dump created on the disk?
Same Event ID 325 as Task 2. The “new database was created” event is the creation. Read the timestamp off it (UTC, Details > System).
Answer: 2024-05-15 05:39:56 (UTC)
Task 4: When was the newly dumped database considered complete and ready for use?
Followed the same DB in ESENT past creation. Event ID 327 (“the database engine detached a database”) is the close: once ESE detaches, the file is released, so that’s the dump finished and usable.
Answer: 2024-05-15 05:39:58 (UTC)
Task 5: Which event source provides database status data like creation and detachment?
Already the answer to Tasks 2 to 4. The 325/327 events all came from the same source. Read it off the Source column.
Answer: ESENT
Task 6: Which two groups are enumerated by the ntdsutil.exe process? (alphabetical, comma space)
This is Event ID 4799 (“a security-enabled local group membership was enumerated”) in the Security log. Filtered Security for ntdsutil and the two hits where the calling process was ntdsutil.exe named the groups it checked to validate the account’s privilege.
Answer: Administrators, Backup Operators
Task 7: Using the Logon ID, find the time when the user logon session started.
Back in Security, filtered to the Kerberos authentication events. Most were noise: machine and service accounts, all ending in $. Skipped those and took the first real user account logon, which is the session behind the dump.
Relevant events: 4768 (Kerberos TGT requested), 4769 (Kerberos service ticket requested), 5379 (Credential Manager credentials read).
Answer: 2024-05-15 05:36:31 (UTC)
Timeline
Lined up, the answers are one sequence, and it’s fast:
05:36:31 user logon (Kerberos) 4768 / 4769
05:39:55 VSS enters running 7036
05:39:56 ntds.dit created 325
05:39:58 ntds.dit detached (done) 327The whole NTDS operation is 3 seconds start to finish. And there’s a ~3.5 minute gap between the logon and the dump kicking off.
Detection notes
What stands out for hunting next time:
ntds.ditwritten toC:\Windows\Temp\dump_tmp\instead of a real backup path. A legit backup doesn’t land in Temp.ntdsutil.exetriggering VSS (7036) followed seconds later by ESENT 325/327 for a database outsideWindows\NTDS.- 4799 enumerating Administrators and Backup Operators with
ntdsutil.exeas the calling process, the privilege check it does right before dumping.