// HackTheBox  ·  writeup

Whisper

HackTheBox Easy regipyPECmdMFTECmdLECmdEvtxECmdsqlite3secretsdumphashcat
DFIR

Scenario

In this Sherlock, players will analyze Windows artifacts to investigate unauthorized activity on a shared company computer. They will examine key system information, such as hostnames, IP addresses, and security identifiers, to piece together the sequence of events. Additionally, players will track user downloads and execution times of programs to uncover how the unauthorized activity was carried out.

Executive Summary

A user on a shared help-desk workstation downloaded a credential-dumping tool through Edge, unpacked it into their profile and ran it. Shortly afterwards they pulled a PowerShell script from a file-sharing site to scan the domain controller, then deleted it from disk about an hour later. They also opened a sensitive spreadsheet on a network share, which left a shortcut in their Recent folder. For persistence they created a second local account that never logged on, and its password hash falls to a common wordlist in seconds.

Artifacts

Timestamp note: Several questions want YYYY-MM-DD hh:mm:ss. Prefetch, $MFT, $J and the browser databases store UTC, while the host itself runs on Pacific time (Q4). Report the UTC values these artifacts hold and don’t convert them.

Discovery

Q1 — What is the hostname of the company computer involved in the unauthorized activity?

The hostname lives in the SYSTEM hive under ControlSet001\Control\ComputerName\ComputerName. A registry parser reads it directly, which is faster than hunting through the Computer field of event logs.

python3 -I reg.py SYSTEM ComputerName
Click flag to reveal HELPDESK
Q2 — What is the IP address associated with the machine?

The same SYSTEM hive holds the network configuration. Walk Services\Tcpip\Parameters\Interfaces and read the address on the active adapter.

python3 -I reg.py SYSTEM Interfaces
Click flag to reveal 192.168.159.199
Q3 — What is the Security Identifier (SID) of the computer involved in the incident?

The machine SID is the shared prefix of the local account SIDs. Read it from the SAM hive under Domains\Account, or take any local user SID and drop the trailing RID.

python3 -I reg.py SAM Users
Click flag to reveal S-1-5-21-953115734-2025219997-3674921352
Q4 — What was the timezone setting of the machine?

TimeZoneInformation under the current control set in SYSTEM stores the standard-time name and bias. Fix this early, because every local-time artifact on the box is shifted by it.

python3 -I reg.py SYSTEM TimeZoneInformation
Click to reveal answer Pacific Standard Time

Credential Access

Q5 — Which tool did the attacker use to escalate privileges and extract sensitive credentials from the system?

Parse the whole prefetch folder and look for known offensive tooling. A MIMIKATZ.EXE-*.pf entry means the binary actually ran, not just that it was downloaded.

PECmd -d prefetch --csv work/o
Click flag to reveal MIMIKATZ.EXE
Q6 — What is the timestamp of the last execution of the credential extraction tool on the system used by the attacker?

Prefetch keeps the last eight run times. Parse the credential tool’s .pf on its own and take the newest. The path recorded inside the file also shows it ran from the Alpha user profile.

PECmd -f MIMIKATZ.EXE-*.pf
Click to reveal answer 2025-01-21 00:21:41
Q7 — What is the timestamp when the attacker first downloaded the credential extraction tool onto the system?

Start with the Edge History database: the downloads table lists the archive and its target path. Then turn to the filesystem for the time the file landed on disk. The USN journal records a FileCreate for mimikatz_trunk.zip in the user’s folder, which is when the download completed there.

sqlite3 History "select target_path, tab_url, start_time from downloads"
MFTECmd -f '$J' --csv work/mft

Gotcha: The $MFT holds earlier timestamps for the same zip under INetCache, and the WebCache database carries an X-Amz-Date header from the CDN. Those are browser cache and request artifacts, not the saved file. Report the creation of the zip in the user folder.

Click flag to reveal 2025-01-21 00:20:15

Execution

Q8 — After using the previously mentioned tool, the attacker downloaded a script to scan the domain controller. What is the URL from which the attacker downloaded this script?

From Q6 we know when the credential tool last ran, so look in the same Edge History database for downloads after that. The downloads table carries the source URL next to the target path.

sqlite3 History "select target_path, tab_url, start_time from downloads"
Click to reveal answer https://mega.nz/file/I31zBZTb#H5aUJamEj2xMroi9baoTKCMjQF1jiV8TK9gbjoNGgkw
Q9 — What is the filename of the script? (Format - Full path of file, starting with drive letter)

The target_path column of the same downloads row gives the full path of the script, DC-Scan.ps1. The $MFT entry for it confirms the parent directory.

MFTECmd -f '$MFT' --csv work/mft
Click flag to reveal C:\Users\Alpha\Downloads\DC-Scan.ps1

Defense Evasion

Q10 — What is the timestamp indicating when the attacker deleted the script after it was downloaded?

Filter the parsed USN journal on the script name. A FileDelete reason on DC-Scan.ps1 is the deletion, and it lands about an hour after the script’s FileCreate, which fits it being used and then cleaned up. The PowerShell Operational log from that window only held PowerView and PowerUp source text, so the script’s own content was not recoverable from it.

MFTECmd -f '$J' --csv work/mft
grep DC-Scan work/mft/*_J.csv
Click to reveal answer 2025-01-21 01:27:47

Collection

Q11 — What is the name of the shared file that the attacker accessed?

Opening a file from a share makes Windows drop a shortcut in the user’s Recent folder that stores the original UNC target. Parse that folder with LECmd and look for a .lnk whose target starts with \\. The one that matters is Secret.xlsx.lnk.

LECmd -d Recent --csv work/lnk
Click flag to reveal \\CYBERUP\Users\Administrator\Desktop\Top-Secret\Secret.xlsx

Persistence

Q12 — To persist, the attacker created a new user account. What is the SID of the newly created account?

The SAM hive lists every local account under Domains\Account\Users, keyed by RID. The newest non-default account is Admin with RID 1002, and its SID is the machine SID from Q3 with that RID appended.

python3 -I reg.py SAM Users
Click to reveal answer S-1-5-21-953115734-2025219997-3674921352-1002
Q13 — How many times has the newly created user logged in?

From Q12 we have the RID. The F structure of that user in SAM holds the logon count, and it is zero. Security.evtx agrees: there is no 4624 for the account.

EvtxECmd -f Security.evtx --csv work/evtx

Tip: The SAM count and the event log agree, so zero is a real answer and not a missing artifact. The account was created but never used.

Click flag to reveal 0
Q14 — What is the password of the newly created user?

The SAM hive and the SYSTEM boot key are both in the collection, so secretsdump can decrypt the NT hashes offline. Admin (RID 1002) comes out as 58a478135a93ac3bf058a5ea0e8fdb71. That hash falls to rockyou.txt with no rules. The plaintext is not in PSReadLine or the PowerShell logs, so cracking is the only route.

secretsdump.py -sam SAM -system SYSTEM LOCAL
hashcat -m 1000 admin.nt /usr/share/dict/rockyou.txt

Gotcha: A hash decrypted with a hand-rolled SAM script was wrong and matched nothing, even through several rule sets, which looked like a strong password. Cross-check hashes from a second tool such as secretsdump before spending time on cracking.

Click to reveal answer Password123

Attack Summary

PhaseAction
DiscoveryHost identified as HELPDESK (192.168.159.199), Pacific time
Credential AccessMimikatz release archive downloaded through Edge, then run from the Alpha profile
ExecutionPowerShell script downloaded from a file-sharing site to scan the domain controller
Defense EvasionScript deleted from disk about an hour later
CollectionSecret.xlsx opened from a network share, leaving a Recent LNK
PersistenceNew local account Admin (RID 1002) created, never logged on
Credential AccessAccount’s NT hash recovered from SAM and cracked with rockyou.txt

IOCs

TypeValue
HostnameHELPDESK
IP192.168.159[.]199
Toolmimikatz.exe, mimikatz_trunk.zip
ScriptC:\Users\Alpha\Downloads\DC-Scan.ps1
URLhxxps[://]mega[.]nz/file/I31zBZTb#H5aUJamEj2xMroi9baoTKCMjQF1jiV8TK9gbjoNGgkw
File accessed\\CYBERUP\Users\Administrator\Desktop\Top-Secret\Secret.xlsx
AccountAdmin (RID 1002)
NT hash58a478135a93ac3bf058a5ea0e8fdb71

MITRE ATT&CK

TechniqueIDDescription
System Information DiscoveryT1082Hostname, IP, SID and timezone established from the registry
OS Credential DumpingT1003Mimikatz executed on the host
OS Credential Dumping: Security Account ManagerT1003.002NT hash of the new account read from SAM
Ingress Tool TransferT1105Mimikatz archive and scan script downloaded through the browser
Command and Scripting Interpreter: PowerShellT1059.001Domain controller scan script
Indicator Removal: File DeletionT1070.004Scan script deleted after use
Data from Network Shared DriveT1039Secret.xlsx opened from a share
Create Account: Local AccountT1136.001Second local account created in SAM

Defender Takeaways

Prefetch plus the USN journal rebuilds download-to-execution on a workstation. Prefetch gave the last run of the tool and $J gave file creation and deletion even after the script was removed. Collect both on every triage, because Edge cache entries alone give misleading earlier times.

A shared workstation needs per-user attribution. Everything here ran from one profile on a shared machine, so who sat at it can’t be answered from the host. Individual logons and a sign-in log are needed.

Flag offensive tooling downloads and execution. A Mimikatz archive landing in a user folder and then running is a one-line detection on file name or hash. Defender or an application control policy should have blocked it, and downloads from file-sharing sites deserve the same scrutiny.

Alert on local account creation, not on first use. An account created through net user (event 4720) with a logon count of zero is a staged backdoor. Its weak password also shows why local accounts need the same password policy as domain ones.

Conclusion

The user ran Mimikatz, scanned the domain controller with a throwaway script, touched a secret file on a share and staged a local account with a trivial password for later. Nothing here required malware sophistication; the case turns on telling browser cache timestamps from the real file creation in the USN journal.