reverse-malware-triage

name	reverse-malware-triage
description	Use this skill to perform fast malware or suspicious binary triage, extract high-signal evidence, summarize capabilities, identify likely next pivots, and produce analyst-ready outputs.

Reverse Malware Triage

Use this skill when the task is early-stage reverse engineering, malware triage, or suspicious sample assessment.

Minimum command set

Start with the shortest command set that can falsify bad assumptions:

file sample.bin
sha256sum sample.bin
strings -a -n 6 sample.bin | head -200
binwalk sample.bin             # signature scan only; add -Me to extract

Then add format-specific inspection:

readelf -h -S sample.bin 2>/dev/null
objdump -x sample.bin 2>/dev/null | head -200

One-shot wrapper

If all you want is "give me the snapshot", run the bundled script. It combines identity, headers, packer hints, binwalk signatures, section entropy, and clustered strings into a single compact report:

scripts/quick_triage.sh sample.bin
# set TRIAGE_EXTRACT=1 to also run `binwalk -Me`

Individual helpers (called from quick_triage.sh, also usable directly):

• scripts/entropy.py sample.bin — per-section Shannon entropy with packer/encryption hints. Use --window 4096 on unknown formats.
• scripts/string_clusters.py — reads strings(1) output on stdin and clusters into network, crypto, path, command, build, crate_or_pkg, and fingerprint buckets. Add --json for machine consumption.

strings -a -n 6 sample.bin | python3 scripts/string_clusters.py --limit 40

If ida-pro-mcp is connected, the minimum MCP pass is:

• list_funcs for entrypoints and large functions
• find_regex for domains, paths, commands, and crypto markers
• decompile the main entrypoint or the largest handler
• xrefs_to on suspicious strings or imports

For a structured first-pass prompt ("survey this binary"), see reverse-ida-mcp-driver.

Objectives

Turn a sample into:

1. a fast triage summary,
2. a capability inventory,
3. IOC candidates,
4. next investigative pivots.

Required behavior

Always separate:

• Facts
• Inferences
• Hypotheses

Never claim packing, family attribution, or protocol behavior without evidence.

Workflow

Phase 1: binary survey

Identify:

• file type
• architecture
• stripped vs non-stripped
• static vs dynamic linking
• likely language/toolchain
• obvious crypto/networking/runtime indicators

Phase 2: high-signal evidence

Collect or ask for:

• strings
• imports / exports
• sections
• embedded paths
• domains / IPs / URLs / ports
• public keys
• command words
• filesystem indicators
• persistence indicators

Do not collect raw bulk output without clustering. Group evidence into:

• network and C2
• filesystem and staging
• execution and persistence
• crypto and key material
• build environment and toolchain

Phase 3: capability sketch

Estimate whether the sample likely supports:

• command execution
• file transfer
• discovery
• persistence
• update/self-replacement
• lateral movement
• crypto
• exfiltration

Mark each as:

• confirmed
• likely
• possible
• not observed

Phase 4: next pivots

Recommend the shortest path to reduce uncertainty.

Examples:

• recover more strings
• inspect dispatch points
• inspect crypto initializers
• inspect network bootstrap logic
• run capa or equivalent capability analysis
• inspect panic paths or file paths
• compare with sandbox/network telemetry

If the language/toolchain is clear after triage, hand off immediately:

• Go -> reverse-golang-symbol-recovery or reverse-golang-malware
• Rust -> reverse-rust-malware
• protocol-heavy sample -> reverse-protocol-reconstruction

Output format

Triage Summary

Executive Summary

[2-5 sentences]

Facts

Inferences

Hypotheses

Capability Matrix

• Command execution:
• Persistence:
• Networking:
• Crypto:
• File operations:
• Update path:

IOC Candidates

Recommended Next Actions