Track 04 — Malware Analysis¶
Understand what malware does, how it works, and how to write detections that stop it. Go from an unknown sample to indicators, ATT&CK mappings, and validated rules — safely.
What you'll be able to do¶
- Stand up a safe, isolated, disposable analysis lab.
- Triage a sample statically and dynamically to understand its behaviour.
- Read disassembly well enough to confirm capability and defeat basic obfuscation.
- Extract IOCs, map to ATT&CK, and write validated YARA/Sigma detections.
Modules¶
| # | Module | What you'll learn | OSS tools |
|---|---|---|---|
| 01 | Analysis Lab Setup & Safety | Isolation, snapshots, network sinks | remnux, inetsim |
| 02 | File Triage & Identification | Formats, hashing, first-look classification | file, pefile, Detect-It-Easy |
| 03 | Static Analysis — Strings & PE | Strings, imports, PE structure | pefile, PEbear |
| 04 | Static Analysis — Capabilities | Mapping behaviour without running it | capa, yara |
| 05 | Dynamic Analysis — Behavioural | Detonating safely; observing the host | cuckoo/CAPE, procmon |
| 06 | Dynamic Analysis — Network | Faking services to capture C2 | fakenet-ng, inetsim |
| 07 | Disassembly Basics | Reading assembly to confirm behaviour | ghidra, cutter |
| 08 | Decompilation & Code Analysis | Following logic in decompiled output | ghidra |
| 09 | Unpacking & Obfuscation | Defeating packers and encoded strings | x64dbg, upx |
| 10 | Anti-Analysis Techniques | Anti-debug/anti-VM and how to bypass | x64dbg |
| 11 | Document & Script Malware | Maldocs, PDFs, and obfuscated scripts | oletools, pdfid |
| 12 | IOC Extraction & ATT&CK Mapping | Turning analysis into intelligence | MISP |
| 13 | Detection Authoring & Reporting | Validated YARA/Sigma + a written report | yara, sigma |
Phases & projects¶
The thirteen modules run in three phases; each ends in a project that integrates its modules (a phase is the substantial, standalone unit — a single module is a few hours). Every project stays inside isolation.
- Phase 1 · Lab & first look (01–04) — Project: a safe, snapshot-able analysis lab plus a
static-triage report on a training sample — format, hashes, strings, imports, PE structure, and a
capa/YARA capability map — with a verdict reached without ever running it. - Phase 2 · Behaviour & code (05–10) — Project: detonate the same sample in the lab, capture host and (faked) network behaviour, then confirm the capability in Ghidra — defeating a packer and one anti-analysis trick — to produce a behaviour report backed by both dynamic and static evidence.
- Phase 3 · Intel → detection (11–13) — Project: the track capstone — handle a maldoc/script vector, extract IOCs and map them to ATT&CK, and ship validated YARA and Sigma rules that fire on the sample and not on benign software, with the analysis report.
Prerequisites¶
Complete Track 00 — Foundations first.
Only analyse malware inside an isolated, disposable VM with networking disabled or routed through a safe sink. Never run samples on a host you care about, and never distribute live malware. Use training corpora (theZoo, MalwareBazaar) per their terms.
Capstone¶
Triage a real, named-family sample end to end — static and dynamic — to IOCs and ATT&CK mappings, then ship validated YARA and Sigma rules that fire on it and not on benign software. Deliverable: the analysis report plus the detection rules, all handled inside isolation.
The starter scaffold and acceptance checks live in
plaintext-labs/malware/capstone/.
Capstone rubric¶
Detections must fire on the sample and stay quiet on benign software — that's the bar. Proficient is the bar to ship.
| Dimension | Developing | Proficient | Exemplary |
|---|---|---|---|
| Safety & isolation | Ran the sample outside isolation, or network not contained | All analysis inside an isolated, disposable VM with networking sinked/disabled; sample never leaves | Snapshot discipline documented; sink (INetSim/FakeNet) captures C2 cleanly; no IOC exfil risk |
| Static analysis | Strings dumped without interpretation | Identified format, key imports, and suspected capability before running it (capa/PE) |
Confirmed capability in disassembly/decompilation; defeated at least one layer of obfuscation |
| Dynamic analysis | Detonated but observations thin | Host and network behaviour observed and tied to capability | Correlated dynamic behaviour with static findings; captured C2/persistence with evidence |
| IOC & ATT&CK | A few IOCs, no mapping | IOCs extracted and mapped to ATT&CK techniques | IOCs split by confidence/durability (hash vs. behaviour), mapped with technique IDs and rationale |
| Detections | A rule that matches a hash only, or untested | YARA and Sigma that fire on the sample, validated against a benign corpus for false positives | Behaviour-based rules (not just hashes) with documented FP testing and a tuning note |
| Report | Disjointed notes | Analysis report a SOC could action | Reads like threat-intel: summary, capability, IOCs, ATT&CK, detections, and confidence |
AI & automation¶
Models accelerate triage — summarising capa output, suggesting deobfuscation, extracting
IOCs, drafting rules. Two rules hold: a model's "this looks benign" is never trusted, and
every generated detection is validated against a known corpus before deployment. And all of
it stays inside isolation.
Standards & further reading¶
- MITRE ATT&CK for behaviour mapping
- YARA and Sigma documentation
- The "Practical Malware Analysis" lab methodology (original techniques)
Comments
Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).