Lion Cipher Lab
Read FLOSS output: the strings a malware author tried to hide
- Digital Forensics & IR (DFIR)
- Intermediate
- ~40 min
- Free · no account required
Why it matters
When a suspicious file lands on an analyst's desk, the first cheap question is 'what does it say about itself?' Running the classic `strings` utility answers part of it — but modern malware deliberately hides its most incriminating text (the server it phones home to, where it installs itself, the command it runs) by building those strings a byte at a time or decrypting them at runtime, so plain `strings` shows you nothing but noise. FLOSS, Mandiant's free tool, closes that gap by emulating the sample's own string-decoding code and recovering what it hid. But the tool only pays off if you can…
What you'll learn
- reading a FLOSS report and telling its four string buckets apart (static, stack, tight, decoded)
- understanding why FLOSS recovers strings that plain `strings` cannot — it emulates the sample's own decoding routines
- pulling IOCs (C2 URL, persistence path, mutex, dropped file) out of the decoded bucket
- cross-referencing recovered strings to likely malware behaviour and MITRE ATT&CK T1027
- judgment: when FLOSS beats plain strings, and where FLOSS itself falls short
- authorized, isolated-lab handling of malware artifacts
Steps in this lab
- The setup: one suspicious file, and the first cheap question
- What FLOSS is, and its four buckets
- The report — read the whole thing first
- Bucket 1 — read the STATIC strings (what plain strings also sees)
- Bucket 2 & 3 — STACK and TIGHT strings (assembled at runtime)
- Bucket 4 — the DECODED strings are the goldmine
- WHY FLOSS finds what plain strings can't — emulation, not magic
- The third rule — WHEN FLOSS wins, its LIMITS, and HOW a pro reads it
- Do it for real (optional) — and clean up your thinking