Neven Marić
Hidden Investigations CTF 2026

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.

  • forensics
  • memory-analysis
  • hex-analysis
  • xor
  • decoy-flag
  • dkom

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

  1. Noticed the dump is only 16 MiB — not a real OS image; dumped strings/hex directly instead of Volatility.
  2. Searched for hiCTF → found only the decoy flag inside a fake audit log.
  3. Hex-walked the fixed-stride process records → spotted winxnet.exe (not in the “ordinary” list) with C2 (c2.darkshadow-apt.org:8443) and OP_SHADOW_LIAR_ACTIVE markers — the hidden/lying process.
  4. Found a ROOT-magic record at 0x35f000 holding key 0x5d, length 0x33, and the encrypted flag at 0x35f010.
  5. XOR-decrypted with 0x5d → real flag.
  6. Submitted → goodFlag (correct).
The flagRevealhiCTF{dk0m_unl1nk_3pr0c3ss_l1st_cr0ss_ch3ck_7c3a9f}

This CTF was possibly solved, and the writeup most likely written by an LLM. Apologies for inconsistencies.