ForensicsHidden Investigations CTF 2026
Memory Liar
A "physical memory capture" (memory.raw, exactly 16 MiB) was provided. An automated process audit reported the host clean.
What this one teaches
- A tiny memory dump (16 MiB) is not a real OS image — skip Volatility and hex-walk directly.
- Planted decoy flags and 'clean' audit logs are deliberate misdirection; cross-check process records against expected Windows service names.
- Encrypted blobs next to plaintext headers that contain the key and length are a common CTF pattern — check adjacent fields before brute-forcing.
Task description
A critical workstation on the financial management subnet was suspected of being compromised by an advanced persistent threat (APT). Our tier-1 triage team collected a physical memory capture and ran an automated process audit.
The automated audit reported everything clean: all running processes appear ordinary, can you retrieve the flag?
- Category: Forensics | Points: 56 | Author: otolk1
- ID: c7150717-fd46-4206-9784-bbe6afe2631e
Key observation
The dump is only 16 MiB and not a genuine Windows image — Volatility is not needed. It is a hand-crafted/synthetic layout: a set of fixed-stride records each holding a process name string:
0x30b174 System 0x33b174 svchost.exe
0x313174 smss.exe 0x343174 svchost.exe
0x31b174 csrss.exe 0x34b174 explorer.exe
0x323174 wininit.exe 0x353174 notepad.exe
0x32b174 services.exe
0x333174 lsass.exe
0x35d174 winxnet.exe <-- the hidden/masqueraded process
winxnet.exe masquerades as a Windows networking service. Nearby strings
confirm the malicious nature:
0x35f050 c2.darkshadow-apt.org:8443
0x35f070 OP_SHADOW_LIAR_ACTIVE
A decoy flag is planted in a fake “incident log” to waste time:
0x3550d3 Forensics Verification Token: hiCTF{th1s_1s_4_f4k3_d3c0y_fl4g_f0r_n00bs_883a1c}
Status: System integrity validated. No hidden tasks or hooks found.
The real flag
At 0x35f000 there is a small record with a ROOT magic header followed by
parameters (one of which is 0x5d = 93) and a 51-byte (0x33) encrypted blob
starting at 0x35f010:
0035f000 52 4f 4f 54 39 05 00 00 5d 00 00 00 33 00 00 00 ROOT9...]...3...
0035f010 35 34 1e 09 1b 26 39 36 6d 30 02 28 33 31 6c 33 54...&96m0.(31l3
...
XOR-decrypting the 51 bytes with key 0x5d:
0x35 ^ 0x5d = 'h',0x34 ^ 0x5d = 'i',0x1e ^ 0x5d = 'C'… →hiCTF{
data = open('memory.raw', 'rb').read()
blob = data[0x35f010:0x35f010 + 51]
print(bytes(b ^ 0x5d for b in blob).decode())
# hiCTF{dk0m_unl1nk_3pr0c3ss_l1st_cr0ss_ch3ck_7c3a9f}
The XOR key 0x5d is literally stored in the ROOT record header, and 0x33
is the blob length.
Steps
- Noticed the dump is only 16 MiB — not a real OS image; dumped strings/hex directly instead of Volatility.
- Searched for
hiCTF→ found only the decoy flag inside a fake audit log. - Hex-walked the fixed-stride process records → spotted
winxnet.exe(not in the “ordinary” list) with C2 (c2.darkshadow-apt.org:8443) andOP_SHADOW_LIAR_ACTIVEmarkers — the hidden/lying process. - Found a
ROOT-magic record at0x35f000holding key0x5d, length0x33, and the encrypted flag at0x35f010. - XOR-decrypted with
0x5d→ real flag. - Submitted →
goodFlag(correct).
The flagReveal
hiCTF{dk0m_unl1nk_3pr0c3ss_l1st_cr0ss_ch3ck_7c3a9f}This CTF was possibly solved, and the writeup most likely written by an LLM. Apologies for inconsistencies.