Lion Cipher Lab
Extract a malware C2 config from a binary and pivot on the indicators
- Threat Intel Analyst
- Advanced
- ~90 min
- Free · no account required
Why it matters
One sample, handled well, becomes intelligence. The file hash an attacker changes for free; the C2 host, the campaign id and the key they reuse across a family — those are what let you find the rest of the samples, map the infrastructure, and write detections that survive a recompile. Config extraction is the daily bread of a malware-focused CTI analyst and the reason automated parsers (CAPE, MWCP, Malpedia's YARA-linked extractors) exist. Learning to do it by hand — safely, on a sample you built — is how you understand what those tools do and when they quietly fail.
What you'll learn
- why almost every RAT/loader stores its C2 settings as an ENCODED blob (so strings/AV signatures miss them) and what a 'config' typically contains — C2 host, port, sleep/jitter, campaign/botnet id, URI, key
- static capability triage with capa: reading which capabilities and ATT&CK/MBC techniques a sample maps to WITHOUT running it, to decide where to look
- spotting an encoded config: contrasting `strings` (finds nothing useful) with an entropy/byte scan that reveals a high-entropy region, and locating the decode routine that references it
- reversing trivial-but-ubiquitous obfuscation — a single-byte or repeating-key XOR — and recognising it from the code and the byte patterns
- writing a REUSABLE Python config extractor (stdlib only): find the blob by marker/offset, XOR-decode it, and unpack the fixed struct into named fields with `struct.unpack`
- parsing a binary config layout: byte order, fixed-width fields vs length-prefixed strings, and validating that the decoded values are sane (a printable host, a plausible port)
- PIVOTING on extracted indicators: taking the recovered C2 host and campaign id and using them to cluster sibling samples and seed a detection — indicators that sit far above a file hash on the Pyramid of Pain
- the judgment call — STATIC extraction vs DYNAMIC (sandbox) config recovery: when reversing the encoder beats detonating, when detonation beats reversing, and doing both
- the named limits of static extraction — packing/crypters, position-independent or downloaded-at-runtime configs, per-sample keys, and domain-generation algorithms — and what to reach for then (unpacking, emulation, CAPE/MWCP-style automated parsers)
- the isolated-VM discipline and handling rules that make real-sample config extraction safe
Steps in this lab
- What a 'config' is, and why extracting it is the win
- Build the benign 'implant' with an encoded config
- The source (paste this as implant.c)
- Triage first: prove strings fails, then let capa point you
- Find the blob and confirm the encoding
- Write the reusable extractor
- Pivot: turn one config into intelligence
- When static extraction is the wrong tool — and the limits