Skip to main content

Azul Plugin Mandiant Capa

An Azul plugin that uses FireEye's CAPA tool to detect capabilities in binaries. This tool statically analyses PE files, ELF files and shellcode, applying rules to determine their capabilities. This plugin creates features that detail these capabilities, along with the relevant MITRE ATT&CK tactics and Malware Behaviour Catalog objectives and behaviours.

Development Installation​

To install azul-plugin-mandiant-capa for development run the command (from the root directory of this project):

pip install -e .

Usage: azul-capa​

Usage on local files:

azul-capa malware.file

Use FireEye's CAPA tool to detect capabilities in binaries.

Installation​

pip install azul-plugin-mandiant-capa

Example Output:

----- Capa results -----
OK

Output features:
    capability: anti-analysis/obfuscation/string/stackstring - contain obfuscated stackstrings
                data-manipulation/encryption/rc4 - encrypt data using RC4 PRGA
                host-interaction/file-system/meta - get file size
                host-interaction/process - get thread local storage value
                linking/runtime-linking - link function at runtime on Windows
                host-interaction/log/debug/write-event - print debug messages
                host-interaction/process/terminate - terminate process via fastfail
     mitre-mbc: Anti-Static Analysis / Disassembler Evasion / Argument Obfuscation - B0012.001
                Process / Terminate Process - C0018
                Cryptography / Generate Pseudo-random Sequence / RC4 PRGA - C0021.004
                Cryptography / Encrypt Data / RC4 - C0027.009
  mitre-att&ck: Defense Evasion / Obfuscated Files or Information - T1027
                Defense Evasion / Obfuscated Files or Information / Indicator Removal from Tools - T1027.005
                Discovery / File and Directory Discovery - T1083
                Execution / Shared Modules - T1129


Feature key:
  capability:  Capability identified by Mandiant's CAPA tool
  mitre-mbc:  Objectives and behaviours from the MITRE Malware Behavior Catalog (MBC)
  mitre-att&ck:  Tactics from the MITRE ATT&CK framework

Disable use of flirt sigs for typelib matching:

azul-capa -c ignore_sigs yes malware.file

Increase timeout for larger/complex samples:

azul-capa -c run_timeout 300 malware.file

Show CAPA internal debug logging:

azul-capa -c see_capa_logging yes malware.file

Automated usage in system:

azul-capa --server http://azul-dispatcher.localnet/

CAPA​

CAPA uses rules to detect patterns matching known capabilities. A public repository of rules is available from https://github.com/mandiant/capa-rules and this plugin requires a copy of those rules, or an equivalent rules repository.

CAPA relies on capa-sigs to identify library code, ensuring the capabilities of included library code is ignored. This detection uses a database of Hexray's FLIRT signatures and can be obtained from https://github.com/mandiant/capa/sigs. This is not included when installing CAPA via pip (pip install flare-capa) and needs to be manually included when doing so. Those signatures were generated by https://github.com/mandiant/siglib.

For more information about CAPA:

CAPA regularly updates the rules in its repos. To avoid regularly breaking this plugin's test cases capa rules will only be updated when the azul-capa plugin is updated to a new version of flare-capa.

Updates to azul-capa​

Updates to newer versions of flare-capa may break the plugin. If you wish to do so, replace capa-rules with a version matching flare-capa. Then make any necessary modifications to the plugin, which will mostly be within do_capa_processing() in azul-capa/utils.py.

A copy of Mandiant's capa-rules project is include with the plugin. These rules are typically not used by the plugin.
Instead a first run of capa produces an optimised version of the rules and cached in file, which are stored in capa-rules-cache.

How to generate cached rules​

Update the version of the installed flare-capa library and update the rules in capa-rules to match this version. Run azul-capa from the command line on a test file using those rules:

azul-capa ANYFILE

As part of the execution process azul-capa will parse the rules and store them in a new .cache file in capa-rules-cache with a .cache extension.

Issues​

When comparing plugin output against the standalone CAPA tool, note that running CAPA without the -v or -vv options can include some extra rule matches that the standard summary excludes. This is due to different filtering applied internally by CAPA. This plugin uses the rules that -v and -vv will show, since it seems to be more complete.
Unsure why CAPA devs chose to do this, it might be a bug, or intentional to filter out some matches that hasn't been encountered in testing.

CAPA will generate false positives when it detects capabilities in statically linked library code that it cannot determine to be library code, for which it relies upon FLIRT signatures. This is especially noticeable with Golang or Rust binaries. A possible solution is to generate FLIRT signatures for those standard libraries somehow.

Adding custom CAPA rules​

If people wish to develop their own CAPA rules, it would be best to incorporate those into Mandiant's public repo and let them put them through their QA process. There could be quite a delay before any new rules actually reach this plugin via that route.

Future work​

  • Continue to update flare-capa and capa-rules as new versions are released, especially for major releases
  • Replace utils.do_capa_processing() with an equivalent function from flare-capa, when they get around to writing one

Python Package management​

This python package is managed using a setup.py and pyproject.toml file.

Standardisation of installing and testing the python package is handled through tox. Tox commands include:

# Run all standard tox actions
tox
# Run linting only
tox -e style
# Run tests only
tox -e test

Dependency management​

Dependencies are managed in the requirements.txt, requirements_test.txt and debian.txt file.

The requirements files are the python package dependencies for normal use and specific ones for tests (e.g pytest, black, flake8 are test only dependencies).

The debian.txt file manages the debian dependencies that need to be installed on development systems and docker images.

Sometimes the debian.txt file is insufficient and in this case the Dockerfile may need to be modified directly to install complex dependencies.