HackTheBox — CrownJewel-1 Sherlock Walkthrough
Investigating a Compromised Domain Controller with Windows Event Logs and MFTECmd
Introduction:
Imagine this: You’re on the front lines of an organization’s security team when suddenly, alerts start firing from a domain controller about suspicious use of the Volume Shadow Copy Service and a potential dump of the NTDS.dit database containing the domain’s secrets. You need to dive into the artifacts, investigate the logs, and triage this incident. If this sounds exciting to you, you’ve stumbled on the right blog!
Welcome to my weekly walkthrough! This week, we’re tackling the CrownJewel-1 challenge from Hack The Box! In this digital forensics and incident response (DFIR) challenge, we defenders will explore the NTDS.dit database and how it was accessed via the Volume Shadow Copy Service. Our goal is to uncover critical details such as the start time of the service, the accounts that were enumerated, the process ID of the service, the GUID of the volume, and the path and file sizes of the dumped file on the disk through the Master File Table (MFT). To do this, we’ll leverage the domain controller’s Windows Event logs and Eric Zimmerman’s MFTECmd tool.
While this challenge is geared toward beginners, it’s a fantastic lab to get some hands-on time with MFTECmd and practice log analysis for all skill levels. So, let’s grab our magnifying glasses and get ready to investigate!
And if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey.
Thanks for reading!
Challenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-1
Challenge Scenario:
Forela’s domain controller is under attack. The Domain Administrator account is believed to be compromised, and it is suspected that the threat actor dumped the NTDS.dit database on the DC. We just received an alert of vssadmin being used on the DC, since this is not part of the routine schedule we have good reason to believe that the attacker abused this LOLBIN utility to get the Domain environment’s crown jewel. Perform some analysis on provided artifacts for a quick triage and if possible kick the attacker as early as possible.
Setup the Analysis Environment & Extract the challenge file:
Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, since this is a Windows-based lab, I’m using FLARE-VM for this challenge and walkthrough.
To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but if you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.
Okay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!
Question 1: Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state.
Let’s start the triage process! Personally, I find that it’s always a good practice to familiarize myself of what artifacts are available for analysis. Let’s take a quick look at what we have been provided first:
All right, we have three Windows Event Logs and the $MFT. We’ll go into each one of these in more detail as they come up during the investigation, but this gives us at least some idea of how we’ll investigate this incident.
Next, let’s gain a better understanding of what we are investigating and why. For this, let’s check out the MITRE ATT&CK knowledge base to gather some intelligence about the technique of dumping the NTDS.dit file (T1003.003.)
According to MITRE ATT&CK:
Adversaries may attempt to access or create a copy of the Active Directory domain database in order to steal credential information, as well as obtain other information about domain members such as devices, users, and access rights. By default, the NTDS file (NTDS.dit) is located in
%SystemRoot%\NTDS\Ntds.ditof a domain controller.[1]In addition to looking for NTDS files on active Domain Controllers, adversaries may search for backups that contain the same or similar information.[2]
The following tools and techniques can be used to enumerate the NTDS file and the contents of the entire Active Directory hashes.
Volume Shadow Copy
secretsdump.py
Using the in-built Windows tool, ntdsutil.exe
Invoke-NinjaCopy
Well, that’s not good! But now that we have some background, we can start to build a timeline by identifying when the attacker started the Volume Shadow Copy service. To do this, open the SYSTEM.evtx file found in Artifacts folder. The SYSTEM log includes various details, including the start and stop states of services which are logged as Windows Event 7036. If you’re in a Windows environment, this will open with the Windows Event Viewer.
Once the SYSTEM log is opened, we’ll filter it for the relevant events we want by pressing Filter Current Log and entering Event ID 7036 into the field.
With the results now filtered, press Find and enter the keyword “Volume” — this will help us to find the correct Volume Shadow Copy service event.
Finally, let’s check the event Details > XML View > TimeCreated SystemTime to get the exact time the service was started.
If that’s too much reading, here is a GIF of the process to summarize.
Question 2: When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the User groups it enumerates, the Subject Account name, and also identify the Process ID(in decimal) of the Volume shadow copy service process
Okay, to answer Question 2, we’ll pivot over to the SECURITY.evtx log. The key word in the question is “enumerate,” which means we’ll want to filter our log by Event ID 4799 — A security-enabled local group membership was enumerated.
Once we’ve filtered the log, let’s look for events with the same timestamp as the service event that we found in Question 1– 8:42:16 PM.
The first event we find has the Group Name “Administrators,” and moving up to the next event in the list, the Group Name is “Backup Operators”. Both events will have the will the same subject account name, DC01$, the Domain Controller’s machine account.
Now that we’ve uncovered both groups enumerated by the Volume Shadow Copy Service (VSSVC.exe), and which machine account the service ran with, let’s submit the answer and move on to the next question.
Question 3: Identify the Process ID (in Decimal) of the volume shadow copy service process.
Looking at the same event from Question 2, let’s focus on the Process Information section. Here we see the Process ID and the Volume Shadow Copy Service Executable Process Name (VSSVC.exe) that we are looking for.
This gives us half of our answer, but we need to do some extra legwork. The Windows Event log displays Process IDs in hexadecimal, but to answer Question 3 we need the Decimal value. No problem, let’s just use a simple online calculator to convert it:
Hex to Decimal Converter (rapidtables.com)
Question 4: Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.
Now that we’ve already looked over the SYSTEM.evtx and SECURITY.evtx, let’s move on to the third provided event log from the Artifacts folder, Microsoft-Windows-NTFS.evtx.
This event log holds the operational events of the Windows NTFS file system on the victim’s device. Once we open this log, we’ll continue with our method of looking at the first event following the timestamp of the Volume Shadow Copy service events from the previous questions.
The first event with a timestamp after the VSS service was started contains an interesting reference to VolumeShadowCopy1. Let’s click into the Details tab and gather some additional information:
Inside of the Details view, we can see some additional event data including the VolumeCorrelationId GUID — this GUID is the value we need to answer Question 4!
Question 5: Identify the full path of the dumped NTDS database on disk.
To uncover the answer to Question 5, we’ll need to pivot away from the Windows Event Logs since they won’t have the artifacts that we need.
But remember the fourth piece of evidence we had, the $MFT file? It’s time to use it! But first, let’s gain a foundational understanding of what the MFT is to figure out how it can help us find the path of the dumped NTDS database.
According MITRE ATT&CK:
Every New Technology File System (NTFS) formatted partition contains a Master File Table (MFT) that maintains a record for every file/directory on the partition.
Okay, very interesting! With this background, it seems promising that we could discover the NTDS file path. So how do we find the information then? One option is to use Eric Zimmerman’s MFTECmd to parse the provided MFT file and export the results to a CSV file.
Once the tool is installed in your analysis environment, we can use the below syntax to have MFTECmd to parse the file:
MFTECmd.exe -f "<Path-to-$MFT>" --csv "<Path-to-Output.csv>"
Now that we have the output from the tool, we can use any CSV application to check the results. However, for the purposes of this walkthrough, I recommend using another of Eric Zimmerman’s tools, Timeline Explorer, to easily view, search, and sort the output data. In Timeline Explorer, search for NTDS.dit.
Looking at the timestamps of the returned results, only one matches the time period (Question 1) of the incident and it has the full path of the file in the Parent Path column!
Question 6: When was newly dumped ntds.dit created on disk?
Fortunately, we already found the answer in the previous question. We just need to copy the timestamp from the Created0x10 column:
Question 7: A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?
Okay, last question! The theory here is that a second file, a registry hive, was dumped at the same time and into the same directory as the NTDS database. So, let’s continue working with Timeline Explorer to see what else we can find within the parsed $MFT file.
To do this, we’re going to filter the results with the same Parent Entry Number as the dumped ntds.dit that we located in Question 5. This should allow us to see other files with the same parent directory or location within the NTFS volume.
On the Parent Entry Number column, you can either click the filter icon and select the corresponding number of the ntds.dit we found, or we can simply type the number into the field. In this example, the Parent Entry Number is 42.
Once we apply the filter, we will see two files: the ntds.dit and the SYSTEM registry hive. To get the file size, we just need to copy the value from the File Size column, and voilà!
Conclusion:
Let’s wrap up this investigation of CrownJewel-1 with a quick recap: Using the Windows Event logs, we determined more details about the abused service, including the start time, process ID, and the mounted volume GUID. Then, with the help of MFTECmd, we identified the file path of the dumped NTDS database and even a second file that the adversary targeted. Great job with the triage!
A big thank you to Hack The Box for the fun and realistic challenge! This was my first lab with this platform and it was an excellent experience. While this challenge is geared toward beginners, the narrative and triage process were very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!
If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don’t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We’re in this together. Thanks for the support!
Until next week’s challenge — stay curious and be safe out there!
Tools & References:
FLARE-VM: https://github.com/mandiant/flare-vm
MITRE ATT&CK — OS Credential Dumping: NTDS (T1003.003): https://attack.mitre.org/techniques/T1003/003/
Microsoft Learn — Volume Shadow Copy Service: https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
Microsoft Learn — Event 4799: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799
Hex Calculator: https://www.rapidtables.com/convert/number/hex-to-decimal.html
MITRE ATT&CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/
Eric Zimmerman’s Tools — MFTECMD: https://github.com/EricZimmerman/MFTECmd
Eric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md
