Overview#
A malware reverse engineer at a European defence organisation was analysing firmware extracted from a compromised industrial controller. The binary contained obfuscated strings that matched a known backdoor family, but no existing antivirus signature caught it. Within twenty minutes, she had written a YARA rule targeting the unique XOR key and string constants, uploaded it to Argus, and triggered a retrospective scan across every firmware image the team had analysed in the previous six months. Three additional devices came back positive. The compromised supply chain was far wider than the original incident suggested.
Argus includes a managed YARA rules engine that stores, versions, and applies YARA pattern-matching rules across malware samples, binary files, and process memory dumps analysed within the platform. YARA is the de facto standard for writing malware detection signatures that describe file content, string patterns, byte sequences, and structural characteristics. The Argus rules engine maintains a tenant-specific YARA rule library that can be applied against CAPE Sandbox results, Binwalk firmware extractions, and FKIE FACT firmware analysis outputs, enabling systematic pattern detection across the full spectrum of malware and firmware analysis workflows.
Key Features#
Rule Library Management#
Upsert YARA rules via the upsertYaraRule mutation, providing rule name, YARA source text, description, author, and classification level. Rules are stored in PostgreSQL scoped to the organisation and can be updated or deprecated without deleting historical match records. The rule source text is preserved in its canonical YARA format for portability, meaning rules can be extracted and deployed to other YARA-capable tools without conversion.
Rule Inventory with Classification Filtering#
Query the rule library via yaraRules. Row-level secrecy filtering ensures classified rules, for example those derived from classified intelligence reporting, are visible only to appropriately cleared personnel. This enables a shared rule library across classification boundaries within the same Argus deployment, supporting environments where unclassified and classified analysts work in the same platform.
Integration with Malware Analysis Domains#
YARA rules stored in Argus are designed to be applied against analysis results from CAPE Sandbox (dynamic analysis), Binwalk firmware extraction, and FKIE FACT firmware analysis. Rule match results link back to the analysed sample, enabling pivot workflows from "this YARA rule matched" to "these are all the samples and firmware images that triggered it," giving detection engineers clear visibility into rule efficacy across the full sample corpus.
Statistics#
The yaraStats query returns aggregate rule totals, active-rule counts, and total match volume, supporting the detection engineering lifecycle where rules evolve over time and their ongoing effectiveness needs to be measured.
Use Cases#
- Malware Family Classification: Write YARA rules detecting specific malware family characteristics and automatically classify CAPE Sandbox results and MWDB samples against the rule set, providing immediate family attribution without analyst intervention for known variants.
- Firmware Backdoor Detection: Apply YARA rules targeting known backdoor strings, hardcoded credentials, and suspicious imports against Binwalk or FKIE FACT firmware extraction output. Supply chain security assessments covering dozens of device types benefit significantly from automated YARA scanning.
- Threat Hunting: Distribute YARA rules derived from MISP threat intelligence events across all analysed samples in the tenant, triggering retrospective matches against previously ingested data. This turns new threat intelligence into immediate historical discovery without manual re-analysis.
- Intelligence-Derived Signatures: Convert MWDB-extracted malware strings and config data into YARA rules that detect variants using the same string constants or encryption keys, turning malware analysis artefacts directly into detection assets.
Integration#
Available via GraphQL: yaraRules, yaraStats (queries); upsertYaraRule (mutation). All operations require authentication and organisation scoping.
Works alongside CAPE Sandbox (sample analysis), Binwalk (firmware analysis), FKIE FACT (firmware deep analysis), and MWDB (malware metadata correlation).
Open Standards#
- YARA Pattern Matching Language: The engine stores, versions, and applies rules in their canonical YARA source format, ensuring portability to any YARA-capable tool without conversion; rules targeting byte sequences, string constants, and structural characteristics are authored and distributed in the YARA rule syntax defined by the YARA project specification.
- STIX 2.1 (OASIS): Threat intelligence ingested from MISP and OpenCTI arrives as STIX 2.1 bundles; malware objects, indicator SDOs, and TLP marking-definitions within those bundles are converted to Argus entities that drive YARA rule authorship, directly linking intelligence-derived signatures to the STIX artefact that originated them.
- MITRE ATT&CK: Use-case workflows map YARA rule matches to malware family classifications that align with ATT&CK technique identifiers, and Sigma rules co-managed on the platform carry ATT&CK technique tags extracted via the platform's Sigma adapter.
- Traffic Light Protocol (TLP): Classification-gated rule access uses TLP marking-definition identifiers (TLP:WHITE through TLP:RED) as the secrecy labelling scheme, controlling which analysts can view rules derived from classified intelligence reporting.
- GraphQL (June 2018 specification): All rule management and query operations are exposed exclusively through a GraphQL API, with typed queries (
yaraRules,yaraStats) and a mutation (upsertYaraRule) defined against a strongly-typed Strawberry schema. - JSON Web Tokens (RFC 7519) / RS256: Every GraphQL operation requires a bearer JWT verified against a JWKS endpoint using RS256 asymmetric signing, enforcing authenticated and organisation-scoped access to the rule library.
- SHA-256 (FIPS 180-4): Sample identifiers used when scanning files against YARA rules are SHA-256 digests, consistent with the hash scheme used across MWDB sample tracking and STIX file-hash indicator patterns throughout the platform.
Last Reviewed: 2026-03-18 Last Updated: 2026-04-14