malware-analysis-triage

Malware Analysis Triage (capa / FLOSS / ghidriff)

Overview

Three FLARE/Mandiant defensive CLIs that turn an unknown blob into actionable intelligence in seconds, before you sink hours into IDA/Ghidra:

• capa — what can this binary do? Static capability detection mapped to MITRE ATT&CK and MBC (persistence, C2, injection, anti-analysis, crypto).
• FLOSS — what is it hiding? Recovers stack / tight / decoded strings that plain strings cannot see (C2 URLs, keys, mutexes, config).
• ghidriff — what changed? Headless Ghidra binary diff between two builds, rendered as shareable markdown — for n-day / Patch-Tuesday research and variant hunting.

Framing: This is defensive triage and authorized RE. Use it on samples you are authorized to analyze (your own, quarantined, sandbox-detonated, CTF, or vendor patches). Every capability you find should feed a detection, not an attack — see the Defensive Pairing column below.

When to Use

• You have an unknown/suspicious executable and need a fast behavior summary.
• strings returned nothing useful but the sample is clearly doing something.
• You need MITRE ATT&CK technique IDs to write or validate Sigma/EDR/YARA rules.
• You want to know exactly which functions to reverse first (jump to addresses).
• A vendor shipped a patch and you need to find the fixed code path (n-day).

When NOT to use: dynamic/sandbox detonation (use CAPE/DRAKVUF/VMRay, then feed their JSON to capa); live debugging (use $reverse-engineering-toolkit); deep manual decompilation (these tools point you there, they don't replace it).

Install (Windows, this workspace)

Python 3.14 + pip are on PATH; Ghidra 12.0.3 is installed with GHIDRA_INSTALL_DIR already set (satisfies ghidriff's Ghidra 11.4+ need).

python -m pip install --user flare-capa flare-floss ghidriff

Installed and verified in this workspace: flare-capa 9.4.0, flare-floss 3.1.1, ghidriff 1.0.0 (Python 3.14).

Invocation gotcha (load-bearing): pip install --user puts the console scripts in C:\Users\Prekzursil\AppData\Roaming\Python\Python314\Scripts, which is not on PATH — so a bare capa / floss / ghidriff will not resolve. Use the PATH-independent module form (verified working):

python -m capa.main --version    # capa 9.4.0  (NOTE: capa.main, not -m capa)
python -m floss --version        # FLOSS 3.1.1
python -m ghidriff --version     # ghidriff 1.0.0
echo "$GHIDRA_INSTALL_DIR"        # D:\Program Files\Ghidra\ghidra_12.0.3_PUBLIC

Alternatively add that Scripts dir to PATH (or call the .exe files there directly) to use the bare capa / floss / ghidriff commands shown in the Quick Reference below.

capa needs rules + signatures (load-bearing — pip does NOT bundle them). The flare-capa wheel ships no rules or FLIRT signatures, so a bare capa sample.exe fails with default embedded rules not found! (maybe you installed capa as a library?) and then default signature path ... doesn't exist. Both are already fetched in this workspace (matching v9.4.0):

rules: C:\Users\Prekzursil\.local\share\capa\capa-rules-9.4.0
sigs:  C:\Users\Prekzursil\.local\share\capa\sigs

So every capa run must pass -r and -s (verified working):

python -m capa.main -r ~/.local/share/capa/capa-rules-9.4.0 -s ~/.local/share/capa/sigs sample.exe

To re-provision after a capa upgrade, re-download the matching tag: capa-rules from github.com/mandiant/capa-rules/archive/refs/tags/vX.Y.Z.zip and the sigs/ folder from the capa source tarball github.com/mandiant/capa/archive/refs/tags/vX.Y.Z.zip. The standalone capa binary bundles both rules and sigs, so it sidesteps this entirely — prefer it inside an analysis VM.

Standalone-binary alternative (no Python deps, good for an isolated analysis VM): download the release binaries for capa and FLOSS from their GitHub releases and drop them on PATH. Prefer the standalone build inside the malware VM so you are not adding the sample's dependencies to your Python env.

capa ships its own pinned rule set; refresh periodically with capa --version and pulling the latest flare-capa. For a separate rules checkout use capa -r <rules-dir>.

Quick Reference

capa needs -r RULES -s SIGS (see Install). Shorthand below: set R=~/.local/share/capa/capa-rules-9.4.0 S=~/.local/share/capa/sigs and use python -m capa.main -r "$R" -s "$S" ....

Goal	Command
Capability + ATT&CK report	python -m capa.main -r "$R" -s "$S" sample.exe
Same, with exact addresses per capability	... -r "$R" -s "$S" -vv sample.exe
JSON for tooling / pipelines	... -r "$R" -s "$S" -j sample.exe > caps.json
Ingest a sandbox report (beats packing)	... -r "$R" -s "$S" cape_report.json
All hidden strings	floss sample.exe
Only stack + tight strings	floss --only stack tight -- sample.exe
Skip slow decoded-string emulation	floss --no decoded -- sample.exe
Plain static strings only (fast)	floss --only static -- sample.exe
Diff two builds to markdown	ghidriff old.bin new.bin
Side-by-side HTML diff	ghidriff --sxs old.bin new.bin
Cap RAM on a large binary	ghidriff --max-ram-percent 50 old.bin new.bin

Run capa and FLOSS together on every sample — they are complementary and both cheap.

Defensive Pairing (turn findings into detections)

Tool finding	Defensive action
capa ATT&CK ID, e.g. T1053 "scheduled task"	Confirm you alert on schtasks/Task Scheduler events; write/validate a Sigma rule for that technique.
capa "process injection" / "C2 over HTTP"	Seed an EDR hunt hypothesis; map to existing analytics coverage.
FLOSS-recovered C2 URL / key / mutex	Add IOC to blocklist/feed; build a YARA rule on the constant or decoded string.
ghidriff patched-function delta	Write detection for the pre-patch exploitation primitive before exploits ship.

The whole point: capa's technique IDs are the same IDs you feed to Sigma/EDR, so triage output drives detection engineering directly.

Gotchas

• capa static backend is defeated by heavy packing/obfuscation — pivot to the sandbox-report mode (capa report.json) or unpack first. Rule set is version-pinned to the installed flare-capa.
• FLOSS decoded-string recovery emulates decoder functions and has a time budget; very large/packed binaries may need --no decoded. It is NOT a sandbox — no network/IO is performed.
• ghidriff diff quality depends on Ghidra auto-analysis completing; large binaries are RAM-hungry (tune --max-ram-percent). First run is slow because Ghidra analyzes both binaries. For IDA-bound, microcode-level CVE localization or symbol porting, escalate to Diaphora (AGPL, IDA plugin).
• Always analyze samples in an isolated VM with no host shares mounted. capa and FLOSS do not execute the sample, but you will be handling live malware on disk.

Workflow

1. python -m capa.main -r "$R" -s "$S" -vv sample.exe — read the capability + ATT&CK summary; note addresses of the highest-value capabilities (injection, C2, persistence, crypto).
2. python -m floss sample.exe — pull config/IOCs; record C2, keys, mutexes.
3. Open the sample in IDA/Ghidra/BN ($reverse-engineering-toolkit, $re-ensure) and jump straight to the capa addresses instead of reading the whole binary.
4. If you have an old + new build (patch research): ghidriff old new and read the markdown for the changed functions.
5. Turn every finding into a detection (Defensive Pairing table) — $semgrep, $code-security, Sigma, or YARA.

Related

• references/commands.md — fuller command reference and CI/headless notes.
• $reverse-engineering-toolkit — choosing the next tool after triage.
• $re-ensure, $ghidra-mcp, $ida-pro-mcp — bring up disassembler backends.
• security-kb gems-seclis.md §1-2 — source decision-queue for these gems.