YARA Rules

YARA is the standard language to describe and detect malware via patterns: you define rules that look for byte sequences, strings, or conditions in files and memory, and YARA tells you which samples match. It’s the bridge between analysis (see Static Malware Analysis/Dynamic Malware Analysis) and detection: once you understand a sample, you write a YARA rule that detects that family across your whole fleet. AV, EDR, sandboxes, and threat hunters use it.

Anatomy of a rule

rule FamilyName_Variant
{
    meta:
        author = "theoffsecgirl"
        description = "Detects family X"
        hash = "sha256..."
        date = "2026-01-01"
    strings:
        $s1 = "characteristic_string" ascii
        $s2 = "C:\\path\\to\\malware" wide
        $hex = { 48 8B ?? ?? E8 ?? ?? ?? ?? }   // bytes with wildcards
        $re = /mutex_[a-f0-9]{8}/               // regular expression
    condition:
        uint16(0) == 0x5A4D and                 // is a PE (MZ header)
        2 of ($s*) and $hex                     // matching logic
}

The components

meta       metadata (author, description, hash, reference) -> documentation
strings    patterns to search:
  "text" ascii/wide/nocase     strings (ASCII/UTF-16/case-insensitive)
  { 48 8B ?? }                 hex bytes, ?? = wildcard, [n-m] = jump
  /regex/                      regular expressions
condition  the boolean logic deciding a match:
  any of them / all of them / N of ($s*)
  uint16(0)==0x5A4D            checks on the file (headers, offsets)
  filesize < 100KB             size conditions
  modules: pe.imports(...), math.entropy(...) -> advanced PE analysis

Writing a good rule

# from analysis you extract the family's UNIQUE patterns:
- characteristic strings (messages, paths, mutexes, user-agents, config)
- byte sequences of its own code (not common libraries)
- imports/structure (pe module: pe.imphash, pe.imports)
# goal: detect the FAMILY (variants included), not just one sample
#   -> stable patterns across variants, avoid strings that change each build
# avoid FALSE POSITIVES:
- don't use generic strings ("error", "http") or compiler/libc code bytes
- test the rule against a benign corpus (goodware) before deploying

Using YARA

# scan files
yara rule.yar sample              ; yara -r rules/ /path/to/scan/
# scan MEMORY (key: the unpacked/decrypted sample has signatures disk doesn't)
yara rule.yar -p <pid>            ; or over a memory dump (see mal-dynamic)
# at scale
yara in EDR/sandboxes, THOR/Loki (YARA-based IOC scanners), VirusTotal Retrohunt

YARA in memory (very powerful)

A packed binary doesn’t match disk signatures because its real code is encrypted. But in memory, once unpacked, it does: that’s why scanning process memory with YARA detects malware that evades static detection (see Obfuscation and Packing).

Relation to other signatures

YARA     files and memory (the "what it is")
Sigma    logs/events (the "what it did") -> behavior detection in the SIEM
IOCs     atomic indicators (hash, domain, IP) -> direct blocking
# the three complement: YARA for the sample, Sigma for the activity, IOCs to block

For the defense

Write rules from analysis: each studied sample → a rule detecting its family.
Deploy YARA in memory and disk (EDR, scanners like Loki/THOR) across the fleet.
Share and consume rules from the community (public YARA rules, threat intel).
Validate against false positives with a benign corpus before production.
Combine with Sigma (behavior) and IOCs for layered detection.

Testing checklist

From analysis, extract unique patterns (strings/bytes/imports)
Write the rule with meta/strings/condition
Prioritize detecting the FAMILY (variants), not one sample
Test against goodware (avoid false positives)
Scan on disk and in MEMORY (unpacked)
Use modules (pe.imphash, math.entropy) if useful
Deploy in EDR/scanners at scale
Combine with Sigma and IOCs