HTB Sherlock: CrownJewel-1

The 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.”

What will you learn? In this easy "Sherlock" challenge, you’ll dive into detecting NTDS.dit dumping, a critical Active Directory attack technique. Using event logs and the Master File Table (MFT), you'll learn to track an attack where the attacker leveraged the vssadmin utility to dump the NTDS.dit database—a key skill for Active Directory defense. This is my first Sherlock writeup with a lot of hand-holding from IPPSEC, very excited to get experience with this type of blue team stuff and I am looking forward to doing more.

The questions we will be answering per the analysis of the artifacts provided in this scenario:

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.

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 two user groups the volume shadow copy process queries and the machine account that did it.

3) Identify the Process ID (in Decimal) of the volume shadow copy service process.

4) Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.

5) Identify the full path of the dumped NTDS database on disk.
6) When was newly dumped ntds.dit created on disk?

7) A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?

Let’s begin with our analysis:

We can start with unzipping the artifacts provided to us by using the password provided to do so next to where we download the archive. The archive includes event viewer files (.evtx) and an MFT (Master File Table) file. The MFT is a file in the file system that stores information about all files and directories, that is critically important for forensic investigators because it allows us to retrieve information about deleted files (file size, creation date, access date, permissions, metadata info, etc).

We can use a tool called Chainsaw to parse through our (.EVTX) files. Chainsaw is a command-line tool for quickly parsing, searching, and analyzing Windows Event logs (EVTX files). It's designed to help incident responders and cybersecurity professionals quickly sift through large volumes of log data to identify potential threats: https://github.com/WithSecureLabs/chainsaw/releases. Here are the detection rules to also build out the tool we’ll be using: git clone https://github.com/SigmaHQ/sigma. We can use the tool from within the working directory containing all the forensic artifacts.

The CreateExplorerShell event with UnelevatedTask is often a false positive because it’s linked to routine Windows operations, like starting Explorer during login, and it runs without admin rights. It can also result from user actions or automated scripts. Generally, low privilege and regular activity make it low-risk—worth investigating only if combined with other suspicious signs. It is important to note though that in the event data we can see the ‘Subject'UserName’, ‘SubjectUserSID’, and the ‘ClientProcessID’ among other things that are helpful for us right now to parse through data.

This may be an easier task to achieve through the Windows event logs GUI tool but Chainsaw offers a unique perspective and ability to do so from Linux. We are able to search against the ‘ClientProcessID’ of 6264 mentioned from our previous query to investigate this anyways.

I circled a lot of key information that we want to generally check against with higher priority, though, in these scenarios we want to be very granular with looking for anomalies and clear indicators of compromise / malicious activity. The user, SID, time /date, Windows Security Event ID, Task Name, Command, Arguments (NoUAC), and what exactly is getting triggered. Windows Event ID 4698 logs the creation of a new scheduled task, showing details like task name, creator, and timing. It’s useful for spotting potential persistence tactics, especially if created by unexpected accounts.

We can use Chainsaw to create a JSON dump file of the event log files we have. This will help us comb through the data.

Now we can make our dump file into a more grep file friendly version by using a technique I saw IPPSEC showed. This is really cool because it puts everything on its own line instead of a list.

Using more bash kung-fu we can actually extract a list of Event IDs with the number of times they occurred. Then we can feed that information into something like ChatGPT to tell us exactly what each ID is to create a more detailed listing of what we have. This is a cool way to parse data and great way to implement AI into a workflow, something I love about IPPSEC’s content are the learning opportunities like this.

After asking ChatGPT to include a third parameter explaining what each event ID is we are able to extract something really valuable for investigating what happened in this scenario. I do not think mine was as verbose but it definitely helped with the concept in mind.

Then we can do the same against the Security logs and create another text file containing what we’d be looking for.

So now we have both the System and Security relevant logs, we now can also obtain the NTFS Operational Logs.

Storing the information for us to use later.

The System, Security, and NTFS Operational logs each serve important functions in Windows environments. System logs track events related to the operating system and hardware, including driver issues and service status changes. Security logs monitor user access and security events, detailing logon attempts and policy modifications, which are essential for detecting unauthorized access. NTFS Operational logs focus on file system activities, recording events like file creation and deletion. Together, these logs provide a comprehensive view of system health and security, aiding in troubleshooting and compliance efforts.

Now we can start answering questions with all the information we have:

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.

We can run this command to search for 7036 against our Events.JSON file: cat events.json| jq '.[].Event | select(.System.EventID == 7036)'. This tells us more information about the state- we can filter based on “param1” which seems to hold the title of the event as to narrow down the Volume Shadow Copy service information we’re looking for.

Pay attention here, we’re able to sort on the unique entries of the service names in Param1 and then verify either by manually searching or adding grep in order to find Volume Shadow Copy does exist here.

Now we can narrow down our search to just entries concerning the Volume Shadow Copy and find out the time this event occurred to answer our first 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 two user groups the volume shadow copy process queries and the machine account that did it.

We can look back into our security.txt file and look for entries that seem suspicious where accounts may be related. Event ID 4799 is the most relevant.

We can take that Event ID and start querying the events.JSON file we have to see what information it has pertaining to that ID. We can see the Event Data mentioning the user, machine account, and Process names. This is stuff we can more granularly filter on.

We can see a lot going on including dfrs.exe is the executable for the Distributed File Replication Service in Windows Server, responsible for replicating files and folders across servers to ensure data consistency. We also see LSASS (where all credentials are stored in process memory), VSSVC (Volume Shadow Copy Service), svchost (system process for running dynamic-link library (DLLs)).

We can filter on the entries pertaining to the Volume Shadow Copy Service (SSVC). We can start by filtering on the service, then event data, and finally the target users.

Now our answer to the question will be starting with the groups: Administrators, Backup Operators, DC01$ (machine account).

3) Identify the Process ID (in Decimal) of the volume shadow copy service process.

We did get this information when we were querying just the .EventData. We can take the CallerProcessID which is in Hexadecimal and use Python to turn that into the numerical presentation we’d prefer.

4) Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.

We are able to use grep based on the expected answer from the Hack The Box page. As it is expecting: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} we can use a regular expression to find occurrences that meet those parameters. We also could look back into our NTFS.TXT file that has the carved out events.

Below we have the NTFS Operational log information from before. We would want to look into Event ID 500 (Volume Shadow Copy Created) as this details information about the creation of a VSC, which would include information such as the Volume ID/GUID assigned during creation to help us identify the snapshots unique identifier when it was mounted.

We can find the GUID (Volume Correlation ID) value we’re looking for by filtering on data pertaining to EventData and the word shadow among it, searching for data that matches the regular expression we provided too. We’re also able to use JQ to better organize the results and return all the occurrences to us.

5) Identify the full path of the dumped NTDS database on disk.

To identify the full path of the dumped NTDS.dit database on disk, we could refer to Event ID 9 (File/Folder Created) or Event ID 300 (Metadata File Accessed) as they log actions involving new files or metadata associated with access, both which may include the path information of the NTDS.dit file when dumped.

Now we can actually take advantage of the MFT artifact (Master File Table) and use Chainsaw to dump the information for us. We need to rename the $MFT file to mft.bin or something else so it does not conflict due to the naming convention: mv \$MFT mft.bin. We will create a dump in a JSON format to cooperate with our intentions to carve out data with other command line utilities. This should take some time to dump a couple directories up where we’ve been working.

The Master File Table contains a record of all the files on disk. We can filter on the file we just created mft.json and search for occurrences concerning the ntds.dit and after seeing all of the outputs filter on the Full Path itself to look for anomalies. There is one entry that stands out, we can flip the slashes around and prepend the full path with C:\ to get Hack The Box to accept the answer.

6) When was newly dumped ntds.dit created on disk?

Where the ‘when’ of this event is concerned we had that information already, we can find the one where the anomaly was present and take the timestamp out.

7) A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?

We know the folder where this NTDS dump occurred is BACKUP SYNC DC so we can filter on that phrase to find all the entries relevant.

We can scroll through the results and see in the Full Path of one ‘SYSTEM’ is present. SAM, SYSTEM, and SECURITY are common hives. That is our answer along with the allocated amount of bytes there too from the entry we find below.

Hope you enjoyed walking through this Sherlock challenge! Tackling NTDS.dit dumping and diving into event logs and the MFT is just one step closer to mastering Active Directory defense. Keep sharpening those skills, and remember—every new challenge brings you closer to uncovering the next big mystery in cybersecurity. Happy hacking!