WorkFromHome
Hack The Box Sherlock Writeup
Created by chicken0248|Released November 13, 2025|First Blood: lukasLUKCZ in 0H 56M 55S
When remote work security goes terribly wrong - tracing a complete attack chain from phishing through RDP access, privilege escalation, DLL hijacking, and persistence to defacement.
Review
This scenario has you review a single workstation after a suspected compromise at a fictional company. The brief points you at desktop wallpaper abuse, but the real work is building a timeline from several independent data sources.
I liked how the case rewards correlation instead of tunnel vision on one artifact family. Browser data, host logs, NTFS change journals, and defender telemetry each tell part of the story, and none of them is sufficient on its own.
A few prompts expect you to connect indirect signals to behavior, which can feel fuzzy until the chain clicks. Once it does, the narrative is coherent and the skills map cleanly to real triage work.
Summary
The timeline shows an employee account interacting with a typosquat login host, then remote desktop activity from an external address. The same period shows browser history and download metadata consistent with staged tooling and blocked transfers, followed by host-resident download paths that bypass the browser stack.
Volume-level privilege abuse appears next, then USN activity and defender telemetry line up with replacement of a printer driver DLL and later detection of trojaned content. A second DLL name surfaces under the WMI service directory, and a startup script ties user logon actions to WMI-hosted execution.
Registry and shell artifacts show a public image path applied as wallpaper, and subsequent logon-focused telemetry marks when the legitimate user returns. Taken together, the artifacts describe phishing-linked access, tool staging, privilege abuse, dual DLL hijack patterns, persistence, and visible defacement.
Key Learning Takeaways
USN Journal Preserves Deletion Timestamps
What: The USN Journal ($Extend\$J) records all file system operations including FILE_DELETE events with precise timestamps. These records persist even when $MFT entries are reused after file deletion.
Why it matters: When investigating file deletions, $MFT records may have been overwritten, losing the original timestamps. The USN Journal is often the only artifact that preserves the exact deletion time.
Key pattern: Always check the USN Journal for FILE_DELETE operations when $MFT lacks deletion timestamps. Parse USN_RECORD_V2/V3 structures to extract timestamps and file references.
LOLBIN Abuse Leaves CryptnetUrlCache Traces
What: When attackers use certutil.exe to download files, Windows creates entries in CryptnetUrlCache with hash-based filenames. These cache files have creation timestamps that correlate with download activity.
Why it matters: Browser downloads may be blocked by Safe Browsing, but LOLBINs bypass these protections. CryptnetUrlCache provides evidence of successful downloads even when browser artifacts show failures.
Key pattern: Search $MFT for CryptnetUrlCache entries created during the attack window. The Content subdirectory contains downloaded files, while Metadata contains URL information.
DLL Search Order Hijacking Requires Process Understanding
What: Windows searches for DLLs in a specific order starting with the application directory. By placing a malicious DLL in the same directory as a target process, attackers ensure it loads first.
Why it matters: Understanding which process loads a hijacked DLL requires tracing execution chains. A seemingly unrelated command (like systeminfo) may trigger WMI queries that load WmiPrvSE.exe, which then loads DLLs from its directory.
Key pattern: When a DLL is placed in an unusual location, identify processes that run from that directory. WmiPrvSE.exe runs from System32\wbem\, making it vulnerable to DLLs placed there.
Windows Defender MPLog Contains Post-Quarantine Hashes
What: MPLog files record detailed analysis including SDN (Security Definition Network) queries that include SHA1 and SHA256 hashes of analyzed files. These logs persist even after files are quarantined or deleted.
Why it matters: When malicious files are removed from the filesystem, MPLog files may be the only source of file hashes needed for IoC extraction or threat intelligence correlation.
Key pattern: Search MPLog files for SDN query entries matching detected file paths. The hash values are embedded in the log entries even if the files are no longer accessible.
Browser Downloads Table Reveals Blocked Attempts
What: Chrome's downloads table includes danger_type and interrupt_reason fields that explain why downloads failed. These fields persist even for blocked downloads.
Why it matters: Understanding why a download was blocked helps explain attacker behavior. If browser downloads fail, attackers pivot to LOLBINs, leaving different artifact traces.
Key pattern: Query Chrome downloads table for interrupt_reason values. Code 41 indicates USER_SHUTDOWN, which may be triggered by Safe Browsing protection rather than actual user action.
Multiple NTFS Artifacts Provide Different Perspectives
What: $MFT, $LogFile, and USN Journal each contain different types of file system metadata. $MFT has file records, $LogFile has transaction logs, and USN Journal has change records.
Why it matters: No single NTFS artifact has complete information. Correlating across multiple sources provides a complete picture of file operations, especially for deleted files.
Key pattern: Always check multiple NTFS artifacts when investigating file operations. Deletion timestamps may only exist in USN Journal, while creation timestamps are in $MFT.
Investigation
Initial Access: Phishing & RDP
Identifying the Phishing URL
Chrome stores visited sites in the History SQLite database under the user profile. Typosquat pages often appear next to legitimate intranet or mail flows, so sorting by recency and visually comparing host labels is a quick first pass.
The urls table exposes the full URL, page title, and last-visit timestamp in Chrome time (converted here to Unix epoch seconds for readability).
$ sqlite3 "files/extracted/C/Users/otello.j/AppData/Local/Google/Chrome/User Data/Default/History" "SELECT url, title, datetime(last_visit_time/1000000-11644473600,'unixepoch') AS last_visit_utc FROM urls WHERE url LIKE '%wowza%' ORDER BY last_visit_time DESC LIMIT 10;"
http://intranet.wowzainc.co.th/landing.php|Intranet Landing Page|2025-05-25 10:36:59
http://login.wowzainc.co.th/login.php|Login|2025-05-25 10:36:55
http://login.wowzalnc.co.th/logon.php|Login|2025-05-25 10:36:42
https://login.wowzalnc.co.th/logon.php|Login|2025-05-25 10:36:42
http://mail.wowzainc.co.th/inbox/email_content1.html|Important Update|2025-05-25 10:36:31The lookalike host differs by a single confusable character in the company token compared to surrounding legitimate URLs, which matches credential-harvesting setups that blend into normal browsing.
Chrome Timestamp Conversion
Chrome stores timestamps as microseconds since 1601-01-01 (Windows FILETIME epoch). To convert to Unix time in SQLite: datetime(timestamp/1000000 - 11644473600, 'unixepoch'). The constant 11644473600 is the number of seconds between 1601-01-01 and 1970-01-01. This same conversion applies to urls.last_visit_time, downloads.start_time, and downloads.end_time.
Typosquatting Detection
Compare the suspicious host string to nearby corporate hosts in the same session. Homoglyph and confusable-character swaps (for example Latin l versus capital I) are common in fake login pages.
Task 1: Phishing URL = http://logi***c.co.th/logon.php
Confirming RDP Access
Remote Desktop logons appear in the Security log as event ID 4624 with logon type 10 (remote interactive). Offline copies parse the same way as a live system if you avoid vendor-specific shortcuts and read the XML payload.
The snippet below uses python-evtx to walk the exported Security.evtx and print 4624 rows where LogonType equals 10, which isolates RDP from other session types.
$ python Temp/q_rdp.py
('2025-05-27 11:59:57.658051+00:00', 'otello.j', '192.168.189.129', 'WORKSTATION6')
('2025-05-28 12:28:05.976364+00:00', 'otello.j', '192.168.189.129', 'WORKSTATION6')The earliest tuple is the first RDP session in this capture. The IP and workstation name fields give you the remote endpoint naming used during the session.
Event 4624 Logon Type Quick Reference
Type 2 - Interactive (local console). Type 3 - Network (SMB, RPC). Type 4 - Batch. Type 5 - Service. Type 7 - Unlock. Type 10 - RemoteInteractive (RDP/TS). Type 11 - CachedInteractive (domain creds, offline).
RDP sessions produce a Type 3 network logon first (for authentication), then a Type 10 a few seconds later when the desktop session starts. Filtering on Type 10 isolates the actual desktop session from the preliminary network handshake.
Task 2: First RDP access = 2025-05***11:59:57
Work File Access
Windows keeps a Recent folder of shortcut (.lnk) files for opened documents. Each LNK file contains structured metadata including the original target path, timestamps, and volume information. Parsing them with a proper shell link library (here LnkParse3) extracts the resolved target from the link info header, which is more reliable than raw byte scanning.
Enumerating all Recent shortcuts reveals which files the RDP session touched during the intrusion window, including work documents the attacker opened for reconnaissance.
$ python Temp/lnk_parse.py
Proposal to CFO.lnk C:\Users\otello.j\Desktop\Working\Proposal to CFO.pptx
Script.lnk C:\Users\otello.j\Desktop\Working\Script.txt
Working.lnk C:\Users\otello.j\Desktop\Working
Wowza Budgeting.lnk C:\Users\otello.j\Desktop\Working\Wowza Budgeting.xlsxThe CFO presentation shortcut embeds the full original path. The other shortcuts confirm the attacker browsed the entire Working directory, accessing budget spreadsheets and scripts alongside the presentation.
Task 3: PowerPoint path = C:\Users\otel***oposal to CFO.pptx
Privilege Escalation
SeManageVolumePrivilege Exploitation
The Chrome History database also contains a downloads table plus downloads_url_chains for final URLs. Joining those tables gives you local paths, remote URLs, Safe Browsing fields, and UTC times without exporting to CSV first.
The first-stage EXE name in this case mirrors a well-known sensitive privilege used for raw volume operations, which narrows what to search for in policy and token evidence next.
$ sqlite3 "files/extracted/C/Users/otello.j/AppData/Local/Google/Chrome/User Data/Default/History" "SELECT d.target_path, u.url, d.danger_type, d.interrupt_reason, datetime(d.start_time/1000000-11644473600,'unixepoch') FROM downloads d JOIN downloads_url_chains u ON d.id=u.id AND u.chain_index=0 ORDER BY d.start_time;"
C:\Users\otello.j\Downloads\SeManageVolumeExploit.exe|http://freehackingtool.com/tools/SeManageVolumeExploit.exe|0|0|2025-05-28 12:43:33
C:\Users\otello.j\Downloads\PrintConfig.dll|http://freehackingtool.com/tools/PrintConfig.dll|7|41|2025-05-28 12:44:01
C:\Users\otello.j\Downloads\a.vbs|http://freehackingtool.com/a.vbs|0|0|2025-05-28 12:55:05The first row shows a completed EXE pull from the same host that later supplies DLLs. The filename matches the privilege name the challenge asks for, and the second row already foreshadows the blocked DLL attempt.
SeManageVolumePrivilege
This privilege allows raw disk access, enabling attackers to bypass file permissions and replace protected system files. The exploit tool likely uses this privilege to delete and replace DLLs in protected directories like System32.
Task 4: Special privilege = SeMana***Privilege
Task 5: Exploit executable = SeMana***Exploit.exe
Safe Browsing Block and LOLBIN Bypass
The same SQLite export shows a non-zero danger_type for the DLL row and a non-zero interrupt_reason while received_bytes stays at zero. That combination is typical when protective features stop a transfer after metadata is recorded.
When the browser path fails, operators often fall back to signed OS binaries that fetch remote content. Those downloads still leave filesystem evidence, commonly under CryptnetUrlCache, which you can anchor with the USN journal instead of trusting GUI-only triage.
$ sqlite3 "files/extracted/C/Users/otello.j/AppData/Local/Google/Chrome/User Data/Default/History" "SELECT target_path, tab_url, danger_type, interrupt_reason, received_bytes FROM downloads WHERE target_path LIKE '%PrintConfig%';"
C:\Users\otello.j\Downloads\PrintConfig.dll|http://freehackingtool.com/tools/|7|41|0Interrupt code 41 maps to Chromium's DOWNLOAD_INTERRUPT_REASON_USER_SHUTDOWN. Chrome's downloads UI surfaces that enum as the plain-language phrase "The user shut down the browser," even when the underlying event was protective rather than a literal user power action.
Chrome Downloads: danger_type and interrupt_reason Reference
danger_type: 0 = safe, 1 = dangerous file type, 2 = dangerous URL, 3 = dangerous content, 4 = uncommon content, 5 = user-validated, 6 = dangerous host, 7 = potentially unwanted. A value of 7 means Safe Browsing flagged the download but did not outright block it.
interrupt_reason: 0 = none, 1 = FILE_FAILED, 10 = NETWORK_FAILED, 20 = SERVER_FAILED, 30 = USER_CANCELED, 40 = USER_SHUTDOWN, 41 = BROWSER_SHUTDOWN. Code 41 triggers the description "The user shut down the browser" in the UI. In forensic context, this often means the download was aborted by a protective mechanism rather than the user literally closing Chrome.
$ python Temp/usn_resolve.py PrintConfig.dll
2025-05-28 12:45:37.538317 FILE_CREATE .\Users\otello.j\Downloads\PrintConfig.dll
2025-05-28 12:45:37.539648 DATA_EXTEND|FILE_CREATE .\Users\otello.j\Downloads\PrintConfig.dll
2025-05-28 12:45:37.540877 DATA_EXTEND|FILE_CREATE|CLOSE .\Users\otello.j\Downloads\PrintConfig.dll
2025-05-28 12:47:06.369746 FILE_DELETE|CLOSE .\Windows\System32\spool\drivers\x64\3\PrintConfig.dll
2025-05-28 12:47:55.129565 RENAME_OLD_NAME .\Users\otello.j\Downloads\PrintConfig.dll
2025-05-28 12:48:29.394445 RENAME_NEW_NAME .\Windows\System32\spool\drivers\x64\3\Printconfig.dll
...The USN parser resolves each record's parent MFT reference to a full directory path. The timeline reveals: certutil deposited a fresh copy in Downloads at 12:45:37 (after the browser attempt failed), the legitimate DLL was deleted from the printer driver directory two minutes later, and the malicious copy was renamed into its place. This is the classic LOLBIN download-then-replace pattern.
USN Reason Flags Quick Reference
0x100 FILE_CREATE - new file or directory created. 0x200 FILE_DELETE - file removed. 0x1000 RENAME_OLD_NAME - source of a rename. 0x2000 RENAME_NEW_NAME - destination of a rename. 0x8000 BASIC_INFO_CHANGE - timestamps or attributes modified (includes hidden flag toggling). 0x80000000 CLOSE - handle closed, often OR'd with the primary action.
Flags combine as bitmasks: FILE_DELETE|CLOSE (0x80000200) means a file was deleted and the handle closed in the same operation. The usn_resolve.py script decodes these to readable names and also resolves the parent MFT reference number to a full directory path.
Task 6: Blocked DLL URL = http://free***ool.com/tools/PrintConfig.dll
Task 7: Safe Browsing reason = The user sh***the browser
Task 8: LOLBIN used = cert***l.exe
Task 9: DLL downloaded = 2025-05***12:45:37
DLL Hijacking Attack
Legitimate DLL Replacement
The full PrintConfig.dll timeline from the previous USN output shows the three-step sequence: FILE_CREATE in Downloads, FILE_DELETE of the legitimate copy in the printer driver directory, and RENAME_NEW_NAME placing the malicious copy. The MFT record for the deleted legitimate DLL was reused after deletion, which means a standard MFT parse returns no results for this filename. The USN Journal is the only NTFS artifact that preserved the deletion record with its precise timestamp.
The resolved directory path .\Windows\System32\spool\drivers\x64\3\ comes from the parent MFT reference in the USN record, not from hardcoding. This confirms the legitimate DLL location as the standard print driver path.
Critical: USN Journal vs $MFT
The $MFT record for PrintConfig.dll had been reused after deletion, losing the original timestamps. The USN Journal preserved the precise FILE_DELETE timestamp that $MFT could not provide. Always check multiple NTFS artifacts for file operation timestamps.
Task 10: Legitimate DLL path = C:\Windows\syst***rs\x64\3\PrintConfig.dll
Task 11: Legitimate DLL deleted = 2025-05***12:47:06
Malware Detection and Hash Extraction
Windows Defender MPLog files mix SDN hash lookups with DETECTIONEVENT lines that include the on-disk path and the service string Defender associates with the alert.
Plain-text search is enough to recover SHA1 values even when the binary is later quarantined, as long as the support log bundle was collected during triage.
PS> Select-String -Path "files/extracted/C/ProgramData/Microsoft/Windows Defender/Support/MPLog-20250528-145950.log" -Pattern "SDN:Issuing SDN query.*PrintConfig.dll" | Select-Object -First 1
... 1006:2025-05-28T15:19:28.421 SDN:Issuing SDN query for \\?\C:\Windows\system32\spool\drivers\x64\3\PrintConfig.dll (sha1=916564984e38f8bb91921cd4e40b64156a72142b, sha2=09130eeeb53a41a5b765915c5a45558486823a4a7e6214e658d71a4827600f45)
PS> Select-String -Path "files/extracted/C/ProgramData/Microsoft/Windows Defender/Support/MPLog-20250528-145950.log" -Pattern "2025-05-28T15:19:35.421 DETECTIONEVENT.*PrintConfig"
... 1021:2025-05-28T15:19:35.421 DETECTIONEVENT MPSOURCE_SYSTEM Trojan:Win64/Meterpreter.E file:C:\Windows\system32\spool\drivers\x64\3\PrintConfig.dll;service:PrintNotify;The SDN line supplies the hash for IOC export, and the DETECTIONEVENT line supplies the wall-clock detection time that maps to the challenge answer.
Task 12: Malware detected = 2025-05***15:19:35
Task 15: SHA1 hash = 9165***8bb91921cd4e40b6***72142b
COM Object and Service Association
PowerShell session transcripts on the workstation show explicit CLSID activation calls. Those strings tie the hijacked DLL path to a COM activation path without opening a registry hive in a GUI.
The same MPLog detection line already names the Windows service context (service:PrintNotify), which matches the object behind that COM server.
PS> Get-Content "files/extracted/C/Users/otello.j/AppData/Roaming/Microsoft/Windows/PowerShell/PSReadline/ConsoleHost_history.txt" | Select-Object -First 5
dir
$type = [Type]::GetTypeFromCLSID("{854A20FB-2D44-457D-992F-EF13785D2B51}")
$object = [Activator]::CreateInstance($type)
dir
reg add "HKCU\control panel\desktop" /v wallpaper /t REG_SZ /d "C:/Users/Public/Pictures/gg.bmp" /fTask 13: CLSID = {854A***57D-992F-EF***2B51}
Task 14: Service/object = Print***ify
Persistence Mechanisms
Second DLL Hijacking
Dropping a DLL next to a service binary that loads early in the search path is a classic search-order hijack. The WMI host (WmiPrvSE.exe) runs from System32\wbem\, so a malicious tzres.dll there loads before the legitimate copy in System32 when the process resolves imports.
The USN journal with MFT-backed path resolution reveals the complete staging sequence, including an intermediate deletion and re-creation that shows the attacker refined their placement.
$ python Temp/usn_resolve.py tzres.dll
2025-05-28 12:47:30.806133 FILE_CREATE .\Users\otello.j\Downloads\tzres.dll
2025-05-28 12:47:30.873189 DATA_OVERWRITE|DATA_EXTEND|FILE_CREATE|SECURITY_CHANGE|BASIC_INFO_CHANGE|CLOSE .\Users\otello.j\Downloads\tzres.dll
2025-05-28 12:49:15.181343 RENAME_OLD_NAME .\Users\otello.j\Downloads\tzres.dll
2025-05-28 12:49:15.181343 RENAME_NEW_NAME .\Windows\System32\wbem\tzres.dll
2025-05-28 12:51:56.076346 FILE_DELETE|CLOSE .\Windows\System32\wbem\tzres.dll
2025-05-28 12:54:23.044467 FILE_CREATE .\Windows\System32\wbem\tzres.dll
2025-05-28 12:54:23.048601 DATA_EXTEND|FILE_CREATE|CLOSE .\Windows\System32\wbem\tzres.dllThe path-resolved output shows the DLL was first downloaded to Downloads, renamed into .\Windows\System32\wbem\, deleted, then re-created at 12:54:23. The final FILE_CREATE timestamp is the answer for Q17, and the resolved parent directory confirms the wbem placement that targets WmiPrvSE.exe's DLL search order.
WMI Execution Chain: systeminfo to DLL Load
The VBScript runs cmd.exe /c systeminfo. The systeminfo command queries WMI classes (Win32_OperatingSystem, Win32_ComputerSystem, etc.) to collect hardware and OS data. These WMI queries cause the WMI service to spawn WmiPrvSE.exe (WMI Provider Host) from %SystemRoot%\System32\wbem\.
When WmiPrvSE.exe starts, it searches for its DLL dependencies using the standard Windows DLL search order. Because the process directory (System32\wbem\) is checked before System32\, a malicious tzres.dll placed in wbem\ loads instead of the legitimate time zone resource DLL in the parent directory.
This three-step chain (VBS -> cmd -> systeminfo -> WMI -> WmiPrvSE.exe -> tzres.dll) gives the attacker both persistence (StartUp folder) and execution (DLL search order hijack) through seemingly benign commands.
Task 16: Second DLL path = C:\Windows\Sys***em\wbem\tzres.dll
Task 17: Second DLL downloaded = 2025-05***12:54:23
Task 21: DLL loading process = WmiP***E.exe
VBScript Startup Persistence
All-users startup items under ProgramData\...\StartUp run when accounts log on interactively. A short VBScript that shells out to cmd.exe /c systeminfo triggers WMI queries, which cause WmiPrvSE.exe to load DLLs from System32\wbem\, executing the dropped tzres.dll.
The USN journal with path resolution traces the script from its download landing in Downloads through its rename into the StartUp directory. The later BASIC_INFO_CHANGE record at 12:56:11 marks the moment the hidden attribute was toggled, hiding the script from File Explorer.
PS> Get-Content "files/extracted/C/ProgramData/Microsoft/Windows/Start Menu/Programs/StartUp/a.vbs"
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "cmd.exe /c systeminfo", 0, False$ python Temp/usn_resolve.py a.vbs
2025-05-28 12:55:10.627990 RENAME_NEW_NAME .\Users\otello.j\Downloads\a.vbs
2025-05-28 12:55:54.204427 RENAME_OLD_NAME .\Users\otello.j\Downloads\a.vbs
2025-05-28 12:55:54.204427 RENAME_NEW_NAME .\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\a.vbs
2025-05-28 12:56:11.419536 BASIC_INFO_CHANGE .\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\a.vbs
2025-05-28 12:56:11.424055 BASIC_INFO_CHANGE|CLOSE .\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\a.vbsTask 18: VBScript path = C:\ProgramData\Micro***grams\StartUp\a.vbs
Task 19: VBS command = cmd.exe***systeminfo
Task 20: Hidden attribute set = 2025-05***12:56:11
Defacement
Wallpaper Change
The PowerShell history already captured the reg add that points the wallpaper value at a bitmap under the public pictures tree. Separately, the USN journal shows when the bitmap file first landed, and KAPE copy metadata records precise UTC stamps for the history file itself.
For the post-compromise user session, interactive logons appear in Security 4624 with logon type 2 and loopback as the network address when the session is local.
$ python Temp/usn_resolve.py gg.bmp
2025-05-28 12:58:24.551620 FILE_CREATE .\Users\Public\Pictures\gg.bmp
2025-05-28 12:58:24.551620 DATA_EXTEND|FILE_CREATE .\Users\Public\Pictures\gg.bmp
2025-05-28 12:58:24.553585 DATA_EXTEND|FILE_CREATE|CLOSE .\Users\Public\Pictures\gg.bmpPS> Select-String -Path "files/extracted/2025-05-28T16_02_07_5343926_CopyLog.csv" -Pattern "ConsoleHost_history.txt" | Select-Object -First 1
... ConsoleHost_history.txt,...,2025-05-28 12:59:30.8921304,2025-05-28 12:59:30.8921304,...$ python Temp/q_all_4624.py
...
('2025-05-28 15:04:41.627171+00:00', '2', '127.0.0.1')The USN-resolved path .\Users\Public\Pictures\gg.bmp matches the reg add value in the PSReadLine transcript. The bitmap was not preserved in the KAPE collection, but the wallpaper message is visible in the scenario description and confirmed by the desktop defacement context.
Wallpaper Timestamp: Why CopyLog, Not File Modified Time?
The PSReadLine ConsoleHost_history.txt is written each time a command runs. The reg add for the wallpaper was the last command in the history, so the file's last-modified timestamp approximates when the wallpaper was set. KAPE's CopyLog.csv records ModifiedOnUtc at sub-second precision from the original filesystem, which is more accurate than querying the copied file's metadata (which reflects copy time). When the original file is no longer accessible, the CopyLog is the best available source for its pre-collection timestamps.
Task 22: Image path = C:\Users\Pub***tures\gg.bmp
Task 23: Wallpaper changed = 2025-05***12:59:30
Task 24: Victim login after = 2025-05***15:04:41
Task 25: Wallpaper message = HACKE***NARCHY
Answer Summary
| Q | Question | Answer |
|---|---|---|
| 1 | Phishing URL | http://logi***c.co.th/logon.php |
| 2 | First RDP access | 2025-05***11:59:57 |
| 3 | PowerPoint path | C:\Users\otel***oposal to CFO.pptx |
| 4 | Special privilege | SeMana***Privilege |
| 5 | Exploit executable | SeMana***Exploit.exe |
| 6 | Blocked DLL URL | http://free***ool.com/tools/PrintConfig.dll |
| 7 | Safe Browsing reason | The user sh***the browser |
| 8 | LOLBIN used | cert***l.exe |
| 9 | DLL downloaded | 2025-05***12:45:37 |
| 10 | Legitimate DLL path | C:\Windows\syst***rs\x64\3\PrintConfig.dll |
| 11 | Legitimate DLL deleted | 2025-05***12:47:06 |
| 12 | Malware detected | 2025-05***15:19:35 |
| 13 | CLSID | {854A***57D-992F-EF***2B51} |
| 14 | Service/object | Print***ify |
| 15 | SHA1 hash | 9165***8bb91921cd4e40b6***72142b |
| 16 | Second DLL path | C:\Windows\Sys***em\wbem\tzres.dll |
| 17 | Second DLL downloaded | 2025-05***12:54:23 |
| 18 | VBScript path | C:\ProgramData\Micro***grams\StartUp\a.vbs |
| 19 | VBS command | cmd.exe***systeminfo |
| 20 | Hidden attribute set | 2025-05***12:56:11 |
| 21 | DLL loading process | WmiP***E.exe |
| 22 | Image path | C:\Users\Pub***tures\gg.bmp |
| 23 | Wallpaper changed | 2025-05***12:59:30 |
| 24 | Victim login after | 2025-05***15:04:41 |
| 25 | Wallpaper message | HACKE***NARCHY |
Attack Chain
Reconstructed from correlated artifacts (browser SQLite, Security.evtx, USN $J, Windows Defender MPLog, and user profile data). Timestamps below are UTC.
2025-05***11:59:57 UTC
T0 - Remote Interactive Logon (RDP)
Source: Security.evtx Event 4624 LogonType 10
First remote desktop session to the victim account from external IP 192.168.189.129. Follows credential use consistent with earlier browser activity against a lookalike login host.
IoC: ATT&CK T1078 (Valid Accounts), T1021.001 (RDP)
2025-05-28 12:43 to 12:48 UTC
T1 - Tooling Download and DLL Staging
Source: Chrome History, USN Journal, CryptnetUrlCache
Chrome download rows show SeMan***Exploit.exe pulled successfully, a blocked DLL pull with Safe Browsing fields set, then USN FILE_CREATE entries in Downloads confirming successful LOLBIN (cert***l.exe) delivery followed by rename into the printer driver directory.
IoC: ATT&CK T1105 (Ingress Tool Transfer), T1218.001 (certutil)
2025-05***12:47:06 UTC
T2 - Legitimate DLL Removed
Source: USN Journal with MFT-resolved parent paths
FILE_DELETE|CLOSE against the legitimate PrintConfig.dll in the printer driver directory immediately before replacement activity tied to the same basename.
IoC: ATT&CK T1574.001 (DLL Search Order Hijacking)
2025-05***12:54:23 UTC
T3 - Second Hijack Under WMI
Source: USN Journal
USN FILE_CREATE with resolved path .\Windows\System32\wbem\tzres.dll aligns with a search-order load by the WMI provider host when helper commands run.
IoC: ATT&CK T1574.001 (DLL Search Order Hijacking)
2025-05-28 12:55 to 12:56 UTC
T4 - VBScript Persistence and Concealment
Source: USN Journal, a.vbs
USN records show a VBScript renamed from Downloads into the all-users StartUp directory, followed by a BASIC_INFO_CHANGE entry consistent with the hidden attribute being set. The script triggers WMI activity on each logon, loading the second hijacked DLL.
IoC: ATT&CK T1547.001 (Startup Folder), T1059.005 (VBScript), T1564.001 (Hidden Files)
2025-05***12:59:30 to ~15:04 UTC
T5 - Defacement and Return Logon
Source: PSReadLine, Registry, Security.evtx
User profile and shell history artifacts show a public bitmap applied as wallpaper (HACKE***NARCHY), then a later interactive logon timestamp for the victim after the intrusive activity window.
IoC: ATT&CK T1491 (Defacement)
Additional Resources
MITRE ATT&CK Mapping
| ID | Technique | Evidence in This Case |
|---|---|---|
| T1566 | Phishing | Typosquat login page in Chrome history |
| T1021.001 | Remote Services: RDP | Security.evtx 4624 LogonType 10 from external IP |
| T1078 | Valid Accounts | Harvested credentials used for RDP access |
| T1105 | Ingress Tool Transfer | Chrome downloads + certutil file transfers |
| T1218.001 | Signed Binary Proxy: certutil | CryptnetUrlCache entries, USN FILE_CREATE after browser block |
| T1574.001 | DLL Search Order Hijacking | PrintConfig.dll in spool driver path, tzres.dll in wbem |
| T1059.005 | VBScript Execution | a.vbs in StartUp folder running cmd.exe /c systeminfo |
| T1547.001 | Boot/Logon Autostart | VBS script placed in all-users StartUp directory |
| T1564.001 | Hidden Files and Directories | USN BASIC_INFO_CHANGE on a.vbs (hidden attribute) |
| T1491 | Defacement | Registry wallpaper change to custom BMP via reg add |
Forensic References
| Topic | Resource |
|---|---|
| USN Journal Structure | Microsoft Docs - Change Journals |
| DLL Search Order | Microsoft Docs - DLL Search Order |
| LOLBIN Catalog (certutil) | LOLBAS Project - Certutil |
| Chrome Download Internals | Chromium Source - interrupt_reasons.h |
| Windows Event 4624 | Microsoft Docs - Event 4624 |
| Defender MPLog Format | CrowdStrike - MPLog Forensic Investigations |
Tools
| Tool | Purpose | Usage in This Writeup |
|---|---|---|
| LnkParse3 | Windows Shell Link (.lnk) parsing | Enumerating Recent shortcuts for file access history |
| python-evtx | Windows Event Log parsing | Security.evtx 4624 logon events (RDP + local) |
| sqlite3 | SQLite database queries | Chrome History (urls, downloads, downloads_url_chains) |
| Custom USN parser (usn_resolve.py) | USN Journal + MFT path resolution | File lifecycle tracking with directory reconstruction |
| Eric Zimmerman's Tools | NTFS and event log analysis | MFTECmd, EvtxECmd (alternative CLI approach) |
| KAPE (KapeFiles) | Artifact collection and triage | Evidence package with CopyLog metadata |