# mandiant/capa: identifying capabilities in executables with rules, not signatures

> capa scans PE, ELF, .NET, shellcode files and sandbox reports and reports what a program can do, mapped to ATT&CK. It is a triage aid for analysts who already have a suspicious file and want a starting point.

**mandiant/capa** — The FLARE team's open-source tool to identify capabilities in executable files.

- Repository: https://github.com/mandiant/capa
- Website: https://mandiant.github.io/capa/
- Stars: 6,206 · Forks: 726
- Language: Python
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/mandiant-capa

## What capa answers, and for whom

capa detects capabilities in executable files. You run it against a PE, ELF, .NET module, shellcode file, or a sandbox report, and it tells you what it thinks the program can do. The README's own examples are deliberately modest: a file might look like a backdoor, might be capable of installing services, or might rely on HTTP to communicate.

The intended reader is a reverse engineer or malware analyst holding an unknown sample. The output is a table of ATT&CK tactics and techniques plus a second table of capability names and namespaces, so the tool is producing a triage summary rather than a verdict. That framing matters. Every row is the product of static pattern matching, and the README frames the results as suggestions about what the program can do, not proof of what it did on any particular host.

The scope is broader than Windows PE. The README lists PE, ELF, .NET module, shellcode file and sandbox report as accepted inputs, and the dependency list in requirements.txt backs that up: pefile for PE, pyelftools for ELF, dnfile and dncil for .NET, and vivisect as the underlying analysis engine. Rules live in a separate repository, mandiant/capa-rules, which the README points to if you want to inspect or write rules.

## How the rule engine and analysis backends fit together

capa is not a signature scanner. A rule describes a behaviour in terms of features extracted from the file, and the engine matches those features against the program's structure. The feature vocabulary is visible in the dependency list: vivisect supplies disassembly and program analysis, pefile and pyelftools supply format parsing, dnfile and dncil handle .NET metadata and IL, python-flirt handles library identification so that statically linked functions can be recognised, and networkx and intervaltree support graph and range queries over the analysed program.

That layering explains both the strengths and the failure modes. Because features are drawn from disassembly and metadata rather than byte patterns, a rule can fire on a program that shares no bytes with anything previously seen. Because the features come from static analysis, a rule can also fail to fire when the analysis does not reach the code, for example when the sample is packed.

The ATT&CK table in the README output is a mapping layer on top of the capability matches, not a separate detection path. Capabilities are grouped into namespaces such as c2/file-transfer, communication/http/client, data-manipulation/encoding/xor, host-interaction/service/create and persistence/service, and the ATT&CK view rolls those up into tactics. If a rule does not carry an ATT&CK mapping, it can still appear in the capability table.

The sigs/ directory in the repository layout holds signatures used for library and function identification, and rules/ holds the rule set bundled with the checkout. The CHANGELOG.md at the repository root is where release-level changes to the engine and rules are recorded.

## Installing capa and running it on a first sample

The README gives two paths. Download stable releases of the standalone capa binaries from the releases page and run them without installation; capa is a command line tool that should be run from the terminal. Or install the Python package, which is what the installation document covers for library use and integration. The package name on PyPI is flare-capa, and pyproject.toml requires Python 3.10 or newer.

If you install from source or PyPI, the project asks you to install the pinned dependency set first. The comment at the top of requirements.txt states that these constraints are used during development and building the standalone executables, and that for these environments you should run the following before installing capa.

```bash
pip install -r requirements.txt
```

Then install the package itself. This is the distribution name, not the command name.

```bash
pip install flare-capa
```

After installation the command is capa. The README's example invocation passes a single sample path, and the tool prints the ATT&CK table and the capability table to the terminal.

```bash
capa suspicious.exe
```

Expect two tables. The first lists ATT&CK tactics and techniques, for example DEFENSE EVASION with Obfuscated Files or Information [T1027], DISCOVERY with Query Registry [T1012] and System Information Discovery [T1082], and EXFILTRATION with Exfiltration Over C2 Channel [T1041]. The second lists capability names against namespaces, for example read and send data from client to server under c2/file-transfer, or encode data using XOR with a match count under data-manipulation/encoding/xor. Parenthesised counts such as (6 matches) indicate how many places in the program contributed to that row.

To read results interactively rather than in a terminal table, the README points to capa Explorer Web, which runs in the browser, and notes that a standalone HTML file can be downloaded for local offline usage. The web interface directory is web/explorer/ in the repository.

## Where capa stops being the right tool

The project maintains a dedicated Limitations document at doc/limitations.md, which is itself a signal about how the authors view the tool: useful, but bounded. The most consequential bound is static analysis. If a sample is packed or otherwise obfuscated so that the real code is not visible to the disassembler, the features capa needs are not there to match, and the capability table will be thin or empty. An empty result is not evidence of a clean file.

A second bound is format coverage. The README names PE, ELF, .NET module, shellcode file and sandbox report. Anything outside that list is not described as supported. If your sample is a document, a script, a firmware image or a container, capa is not the tool for that job, and the README does not claim otherwise.

A third is interpretation. Capability matches describe what the program is capable of according to the rules, not what it does when executed. A benign administrative utility that creates services and opens sockets will produce rows that look alarming in isolation. The rule set is the ceiling on what can be reported: a behaviour with no rule will not appear, and a rule that is too broad will produce noise. That is why the README sends anyone who wants to change coverage to the separate capa-rules repository rather than treating the engine as the whole system.

Finally, capa does not unpack, does not emulate, and does not detonate. It reads the file you give it. When you need runtime behaviour, a sandbox is the complementary step, and the README's mention of sandbox reports as an input suggests the intended workflow is often capa plus a dynamic run rather than capa instead of one.

## capa compared with YARA and with a sandbox

The closest alternative in most analysts' toolkits is YARA, and the difference is in what gets matched. YARA rules match byte patterns, strings and simple structural conditions in a file. They are fast, they work on any file type, and they are trivial to write for a known family. capa rules match semantic features recovered by disassembly and format parsing, which is why a capa rule can describe a behaviour such as creating a service without knowing anything about the specific binary that implements it, and why capa needs a supported file format and a successful analysis pass before it can say anything at all. The trade is coverage breadth for behavioural generalisation.

Against a sandbox, the difference is time and evidence. A sandbox executes the sample and reports observed behaviour, which is stronger evidence but requires a safe environment, takes minutes, and can be defeated by samples that detect analysis or wait for a trigger. capa runs locally on the file, produces output in seconds to minutes depending on sample size and analysis backend, and cannot be evaded by anti-analysis tricks in the same way, because nothing is executed. What it cannot do is confirm that a code path is ever reached. The two are complementary, and capa accepts a sandbox report as an input, which is the clearest statement of how the project expects them to be used together.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-14, so this is a project that is still being worked on. Releases are frequent enough to matter for planning: v9.3.0 on 2025-11-12, v9.3.1 on 2025-11-20, and v9.4.0 on 2026-04-01. pyproject.toml classifies the project as Production/Stable and targets Python 3.10 and above.

The upgrade cost sits mostly in the rule set and the analysis backends rather than in the CLI, which has been stable enough that the README's example invocation is a single positional argument. requirements.txt pins exact versions of vivisect, pefile, dnfile, dncil, python-flirt and the rest, and the file's own comment explains the reason: in development and standalone-build environments the pins guarantee specific versions are used. If you install flare-capa from PyPI without the pinned requirements first, you get the version ranges declared in pyproject.toml instead, which the file notes are deliberately looser because capa is also consumed as a library by other programs. That distinction is worth knowing before you file a bug about a version mismatch.

Licensing is Apache-2.0, per LICENSE.txt and the classifier in pyproject.toml. The source files carry the standard Apache header, for example the copyright notice at the top of pyproject.toml. Apache-2.0 is a permissive licence with an explicit patent grant and a notice requirement, which matters if you redistribute the tool inside a product. It is not a copyleft licence, so it does not force you to publish your own code. This is a description of the licence text, not legal advice; if redistribution is part of your plan, read LICENSE.txt and the notices in the files you ship.

## Conclusion

capa fits analysts who need a first-pass capability summary of a PE, ELF, .NET module, shellcode file or sandbox report, and who are willing to read the rule matches rather than treat them as a verdict. It is the wrong tool if you need a packed sample unpacked, a behaviour confirmed at runtime, or coverage of a format the engine does not parse. Before adopting it, check the Limitations document in doc/limitations.md, confirm which rules ship with the release you download from the releases page, and run capa -h to see the flags your build actually supports.

## FAQ

### What is the purpose of capa in cybersecurity?

capa detects capabilities in executable files. You run it against a PE, ELF, .NET module, shellcode file or sandbox report, and it reports what it thinks the program can do, such as suggesting that a file is a backdoor or relies on HTTP to communicate.

### What is a capa tool?

It is a command line tool from Mandiant's FLARE team that identifies capabilities in executable files and prints an ATT&CK tactic and technique table alongside a capability table with namespaces.

### Which file types can mandiant/capa analyse?

The README lists PE, ELF, .NET module, shellcode file and sandbox report as accepted inputs. Formats outside that list are not described as supported.

### How do I install mandiant/capa?

You can download a standalone binary from the releases page and run it without installation, or install the Python package named flare-capa, which requires Python 3.10 or newer. The project asks you to install requirements.txt first when installing from source or PyPI.

### Where do I write or inspect capa rules?

The README directs anyone who wants to inspect or write rules to the separate mandiant/capa-rules repository rather than the main capa repository.

## Sources

- [License: Apache-2.0](https://github.com/mandiant/capa/blob/master/LICENSE)
- [mandiant/capa on GitHub](https://github.com/mandiant/capa)
- [Project website](https://mandiant.github.io/capa/)
- [README](https://github.com/mandiant/capa/blob/master/README.md)
- [Releases](https://github.com/mandiant/capa/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mandiant-capa