Jinkies - HTB Sherlock Writeup

You’re a third-party IR consultant and your manager has just forwarded you a case from a small-sized startup named cloud-guru-management ltd. They’re currently building out a product with their team of developers, but the CEO has received word of mouth communications that their Intellectual Property has been stolen and is in use elsewhere.

The user in question says she may have accidentally shared her Documents folder and they have stated they think the attack happened on the 6th of October. The user also states she was away from her computer on this day.

There is not a great deal more information from the company besides this. An investigation was initiated into the root cause of this potential theft from Cloud-guru; however, the team has failed to discover the cause of the leak. They have gathered some preliminary evidence for you to go via a KAPE triage. It’s up to you to discover the story of how this all came to be. Warning : This Sherlock requires an element of OSINT and players will need to interact with 3rd party services on the internet.

Medium - DFIR

The provided archive contained many artifacts from KAPE output, which contained two directories: LiveResponse and TriageData. The first directory contained files displaying useful system information for quick DFIR analysis, such as ipconfig, pslist, autoruns, etc. The second directory contained selected Windows folders including valuable artifacts such as user-owned files, Windows event logs, prefetch files, etc.

Before starting, I downloaded the Zimmerman tool suite from the Get-ZimmermanTools script.

1. Which folders were shared on the host? (Please give your answer comma separated, like this: c:\program files\share1, D:\folder\share2)

Information about shared folders (i.e. shares) can be found in the available registry hives within the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares key. The registry hives are available in the Jinkies_KAPE_output\TriageData\C\Windows\system32\config directory from the extracted archive. To read the registry hives, we will use Registry Explorer from the Zimmerman toolset. Since our key is located inside the SYSTEM hive, we will load that hive into the application:

After that key is selected, we will be prompted for the transaction logs belonging to this hive (.LOG1 and .LOG2 files). Select 'Yes' and add both files:

Then, we can save the clean hive in another directory for an easier future analysis. Now, we can navigate to the key containing the shares information and read which directories are used as shared folders:

The two available shares contain the path to the directory on the Type viewer pane:

1. C:\Users

2. C:\Users\Velma\Documents

These specific folders shouldn’t be shared folders, considering the amount of personal data usually stored inside of them.

2. What was the file that gave the attacker access to the user's account?

Based on the victim's statement, we know that this attack occurred on October 6th. Let's try checking for any new files added to the system on that day using the provided $MFT artifact and reading it with Timeline Explorer:

Once inside, we can use the Last Access 0x10 field to filter for files that were accessed by the machine on October 6th, 2026. Additionally, we know that there was some suspicious activity on the Documents directory, so start by filtering for files inside that directory. After filtering based on these parameters and sorting by Last Access, we can see the last file read by the system inside Documents before the KAPE triage started:

This file is still be available in the provided artifacts inside the Jinkies_KAPE_output\TriageData\C\users\Velma\Documents\Python Scripts + things\web server project\testing\logon website\bk directory. Doing some research, it seems that the .ibd extension refers to a raw MySQL InnoDB database table file. We can read the contents of the file using the strings64.exe executable from Sysinternals, which can be easily downloaded from https://live.sysinternals.com/.

Since this was the last file accessed on the day of the incident, we can assume that the attacker obtained user credentials from this file through the previously discovered shared folders.

3. How many user credentials were found in the file?

All rows appears to contain an email column (e.g. "@gmail.com"). Using some PowerShell utilities, we can count the amount of times the @gmail string appears inside the database to determine how many user credentials were in the table:

PS C:\Users\hiramf0\Downloads\jinkies> ..\strings.exe "C:\Users\hiramf0\Downloads\jinkies\Jinkies_KAPE_output\TriageData\C\users\Velma\Documents\Python Scripts + things\web server project\testing\logon website\bk\bk_db.ibd" /accepteula | sls "@gmail" | measure


Count    : 216
Average  :
[...]

4. What is the NT hash of the user's password?

The information related to NTLM hashes should be located inside the SAM and SYSTEM registry hives. The provided files also contained these hives, which we can use with mimikatz to dump hashes found inside those hives. After downloading the mimikatz binary from GitHub, we can copy the SAM and SYSTEM hives into the same directory as the executable and run lsadump::sam /system:SYSTEM /sam:SAM to dump all hashes inside these hives:

5. Is the user's computer password the same as the password found in the ibd file? (Yes or No)

Let's find the password of the user inside the .ibd file using sls:

PS C:\Users\hiramf0\Downloads\jinkies\Jinkies_KAPE_output\TriageData\C\users\Velma\Documents\Python Scripts + things\web server project\testing\logon website\bk> C:\Users\hiramf0\Downloads\strings64.exe /accepteula .\bk_db.ibd | sls velma

Tvelma
peakTwins2023fcvelma.dinkley@gmail.comvelmavelma dinkley

The password of the user is peakTwins2023fc. Let's use an online tool to calculate the NT hash of that password and compare it the hash we obtained previously from Mimikatz.

As we can see, this is the same hash as before, so we can confirm how the attacker was able to login as the Velma user using their creds.

6. What was the time the attacker first interactively logged on to our user's host?

We should be able to find login events in the day of the incident through Windows Event Logs artifacts and focusing on Event ID 4624 logs. First, let's parse all Windows Event Logs with EvtxECmd for easier analysis with Timeline Explorer:

PS C:\Users\hiramf0\Downloads\Get-ZimmermanTools\net9\EvtxeCmd> .\EvtxECmd.exe -d "C:\Users\hiramf0\Downloads\jinkies\Jinkies_KAPE_output\TriageData\C\Windows\system32\winevt\logs" --csv "C:\Users\hiramf0\Downloads\jinkies" --csvf "evtxecmd-out"

Now, let's filter the logs to find any login events based on Windows Event ID 4624:

We can filter down these login events based on the Logon Type. According to official documentation, the LogonType 2 (Interactive) and LogonType 5 (Service) appear to correspond to normal login activity, including a user logging in physically or a normal system service. Let's filter these events out and see what other events are available:

The first 3 events correspond to a successful login over the network, whereas the last one corresponds to a successful login through a remote service like RDP. The last 2 login events have very close timestamps, with the last event having a RemoteInteractive logon type, which would make sense considering there's a remote attacker.

7. What's the first command the attacker issues into the Command Line?

Inside the parsed Windows Event Logs, we can filter for events that happened on the day of the incident that contain the cmd.exe inside one of the payload fields (Payload Data6). The commands executed by the attacker appear on the Executable Info column.

8. What is the name of the file that the attacker opens in VSCode shortly before launching the web browser?

Looking at Sysmon Event ID 1 events that mention the Code.exe executable, we can see a Python file being opened by the attacker:

This file is not available in the Desktop directory inside our provided artifacts, but we can assume that it helped the attacker gain a better foothold into the compromised system. After this interaction with Code.exe, the attacker opened the chrome.exe executable at 2023-10-06 17:18:42.

9. What's the domain name of the location the attacker likely exfiltrated the file to?

Looking back into the provided artifacts, we can find the user's Chrome history by going to Jinkies_KAPE_output\TriageData\C\users\Velma\Appdata\Local\Google\Chrome\User Data\Default and opening the History file. This file is a SQLite database file, which can be opened using DB Broswer for SQLite. After opening the file using that program, selecting the Browse Data tab, and filtering by IDs on reverse order, we will be able to see the latest URLs visited by the user:

The pastes.io domain is a Pastebin-like website that could have been used to exfiltrate text-based data. Since the attacker did some research on Incognito later, the History artifact doesn't contain any more data regarding exfiltration of files.

10. What is the handle of the attacker?

Let's look deeper into the files that the attacker interacted with after visiting the Pastes.io website. The timestamp shown in the History file is a Chrome/WebKit timestamp, which can be converted into UTC using this website. This is the UTC timestamp of the visit to Pastes.io:

Let's look at events after 17:19:38. Filtering for FileCreate events, we can see an interesting file being created in a directory owned by the Velma user:

This file isn't available inside the artifacts collected by KAPE. However, this file is mentioned inside the $MFT records:

I tried using the MFT Explorer GUI to read more information about this file, but it took too long to load. We can use the CLI version of this tool to see additional information about this file based on the Entry Number: 78533.

PS C:\Users\hiramf0\Downloads\jinkies> ..\Get-ZimmermanTools\net9\MFTECmd.exe -f "C:\Users\hiramf0\Downloads\jinkies\Jinkies_KAPE_output\TriageData\C\`$MFT" --de 78533

Inside, we can find a note left behind by the attacker, containing the handle of the attacker.