Keypoints
- capa v7.0 can process CAPE sandbox JSON reports to extract program capabilities from runtime API traces, improving analysis of packed/obfuscated samples.
- Usage workflow: run a sample in CAPE, obtain the CAPE JSON report, and run capa against the JSON; capa auto-detects the sandbox format.
- New dynamic analysis flavor adds three scopes—process, thread, and call—complementing the existing static scopes (function, basic block, instruction).
- Rule format updated to be flavor-agnostic: rules can specify multiple scopes under a new scopes key to support both static and dynamic flavors without duplication.
- Dynamic output rendering now includes runtime details such as process/thread identifiers and API argument names as provided by CAPE.
- CAPE was chosen for being open-source and providing extensive reports; example datasets (e.g., Avast CAPE reports) are usable as inputs.
- Limitations: CAPE does not trace .NET API calls (e.g., System.IO.File::Exists), and some static-only features (basic block/instruction subscopes) are unsupported in dynamic flavor.
MITRE Techniques
- [T1543.003] Create or Modify System Process – Used to persist via Windows services (example behavior: ‘…writes a file from its resource section to disk and creates a service to persist on the system.’)
- [T1027.002] Software Packing – Sample is packed with UPX and unpacks at runtime (‘…UPX-packed sample’ and ‘multi-stage malware samples that unravel themselves at run-time.’)
- [T1083] File and Directory Discovery – Malware checks for file existence using APIs such as PathFileExists (‘…a sandbox report must contain a call to the PathFileExists API’).
- [T1106] Native API – Extensive tracing of native OS API calls is used to observe behavior (‘…extracts and abstracts the most relevant capabilities from thousands of data points including 7,390 traced API calls.’)
- [T1105] Ingress Tool Transfer – Dropping or writing files to disk from embedded resources (‘…writes a file from its resource section to disk…’)
Indicators of Compromise
- [File packing] example – UPX-packed sample (used in examples and demonstrations)
- [API names] runtime calls – PathFileExists, System.IO.File::Exists (note: CAPE does not trace .NET API calls like System.IO.File::Exists)
- [Sandbox report] report format – CAPE JSON report (capa processes CAPE results in JSON format)
- [Dataset] sample source – Avast’s CAPE reports dataset (referenced as an example source of CAPE JSON files)
capa v7.0 adds first-class support for analyzing CAPE sandbox JSON outputs so analysts can extract capabilities directly from runtime traces. The practical workflow is: (1) run the sample in CAPE, (2) obtain the CAPE JSON report, and (3) run capa on that JSON; capa auto-detects the sandbox format and applies existing detection rules. This approach exposes API calls and runtime argument values (the authors cite cases with thousands of traced API calls) that static analysis misses, enabling better handling of UPX-packed and multi-stage samples that unpack or execute logic only at runtime.
To integrate dynamic data without duplicating rule sets, capa introduces an analysis “flavor” concept and a flavor-agnostic rule format. The dynamic flavor defines a scope hierarchy of call (individual API calls and arguments), thread (per-execution-thread aggregates), and process (per-process aggregates), while the static flavor retains function/basic-block/instruction scopes. Rules now use a plural scopes metadata key to specify the matching scope per flavor; rule authors must account for unsupported dynamic-only limitations (e.g., no basic block/instruction subscopes or property/read feature in dynamic reports). CAPE-specific notes: CAPE provides API argument names (which may differ from MSDN), and it does not trace .NET API calls such as System.IO.File::Exists.
Output rendering was updated to surface runtime context: matched capabilities include the process, thread, or call identifiers and API argument values/names as reported by CAPE. This enables rapid sandbox-driven triage (for example, identifying a UPX-packed dropper that writes a resource to disk and creates a service for persistence) and lays groundwork for adding support for other sandboxes or time-travel debugger traces in the future.