Summary

This challenge was a memory-forensics exercise rather than a live malware execution problem. The evidence was all in memory.lime: process artifacts, shell history, embedded configuration values, and enough source fragments to rebuild the crypto path used by the malware.

The objective was to recover the malware’s internal parameters, validate the correct machine identifier, and decrypt the final vault payload without running the malware itself.

Analysis

I started with basic triage. Simple string extraction from the memory image immediately surfaced names such as ram_vault_beacon, paths like /opt/ctf_vault, and several internal variables. That confirmed the dump contained more than just process memory; it also contained the environment data and request material needed for the crypto reconstruction.

Next I used Volatility 3 to confirm the process tree. The chain pointed to a shell wrapper, a controller script, and the malware process itself. That gave confidence that the interesting values in memory were not random leftovers, but part of the actual challenge execution.

From the memory image I recovered:

  • TASK_ID
  • KDF_SALT
  • STAGE_ARGS_B64
  • an HTTP request body with ts, fp, and hmac
  • enough code fragments to identify the vault format and crypto primitives

Those clues made the rest of the solve mostly a reconstruction exercise.

Exploitation

The solve path was:

  1. Extract the key strings from memory.lime.
  2. Confirm the process tree with Volatility.
  3. Rebuild the request parameters and verify the HMAC.
  4. Derive the correct machine-id by matching the SHA-256 preimage.
  5. Locate the encrypted vault blob in memory.
  6. Derive the final key and decrypt the vault.

The reconstructed vault format and key derivation were the important parts. Once the request parameters and machine identifier matched, the decryption step was deterministic.

A few of the useful commands from the solve:

1
2

strings -a -n 10 memory.lime | egrep 'TASK_ID=|KDF_SALT=|STAGE_ARGS_B64=|beacon\.ctf\.local|ram_vault_beacon|/opt/ctf_vault'
XDG_CACHE_HOME=$PWD/.cache ./.venv/bin/vol -f memory.lime linux.psaux.PsAux

The recovered plaintext was the flag itself.

Flag

CTF{55eb337497c226fadcd74648227da4831106f06439145d500bb383b47bfa8745}

Tags: memory-forensics volatility malware