$npx -y skills add meltedinhex/analyst-ai-pack --skill generating-capability-reports-with-capaUses capa to identify malware capabilities from a binary: running rule-based
| 1 | # Generating Capability Reports with capa |
| 2 | |
| 3 | ## When to Use |
| 4 | |
| 5 | - You want an automated, rule-based read of what a binary can do before manual reversing. |
| 6 | - You need capabilities mapped to MITRE ATT&CK and the Malware Behavior Catalog (MBC). |
| 7 | - You are prioritizing which functions to reverse based on detected capabilities. |
| 8 | |
| 9 | **Do not use** capa results as a behavioral guarantee — it detects *potential* capabilities from |
| 10 | code patterns; packed samples must be unpacked first or capa sees only the stub. |
| 11 | |
| 12 | ## Prerequisites |
| 13 | |
| 14 | - `capa` installed; the sample handled inertly in the lab. |
| 15 | - For packed samples, an unpacked dump (see the unpacking skills) before running capa. |
| 16 | |
| 17 | ## Safety & Handling |
| 18 | |
| 19 | - capa performs static analysis; it does not run the sample. Still handle the sample inertly. |
| 20 | - Keep the sample password-protected at rest and reference it by hash. |
| 21 | |
| 22 | ## Workflow |
| 23 | |
| 24 | ### Step 1: Confirm the sample is analyzable |
| 25 | |
| 26 | Verify it is not packed (entropy/imports). If packed, unpack and run capa on the dump, not the |
| 27 | stub. |
| 28 | |
| 29 | ### Step 2: Run capa and capture results |
| 30 | |
| 31 | Generate the capability report, ideally in JSON for programmatic use plus the human view. |
| 32 | |
| 33 | ```bash |
| 34 | capa -j sample.exe > capa.json |
| 35 | python scripts/analyst.py summarize capa.json |
| 36 | ``` |
| 37 | |
| 38 | ### Step 3: Map to ATT&CK and MBC |
| 39 | |
| 40 | Group matched rules by ATT&CK technique and MBC behavior to see the sample's capability profile |
| 41 | (e.g., persistence, injection, C2, anti-analysis). |
| 42 | |
| 43 | ### Step 4: Prioritize deeper analysis |
| 44 | |
| 45 | Use the function addresses capa reports to jump straight to the most interesting code in your |
| 46 | disassembler. |
| 47 | |
| 48 | ## Validation |
| 49 | |
| 50 | - capa was run on unpacked code, not a packer stub. |
| 51 | - Detected capabilities are corroborated by imports/strings before being trusted. |
| 52 | - The ATT&CK/MBC mapping focuses subsequent manual reversing on real functionality. |
| 53 | |
| 54 | ## Pitfalls |
| 55 | |
| 56 | - Running capa on a packed sample and concluding "few capabilities". |
| 57 | - Treating a capa match as confirmed behavior rather than potential capability. |
| 58 | - Ignoring the reported addresses that pinpoint where to reverse. |
| 59 | |
| 60 | ## References |
| 61 | |
| 62 | - See [`references/api-reference.md`](references/api-reference.md) for the capa summarizer. |
| 63 | - capa and MBC (linked in frontmatter). |