YARA Rules for Malware Hunting and Classification

YARA Rules for Malware Hunting and Classification - article cover image Tools & Defense
2026.07.12
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

YARA is a pattern-matching engine, originally written by Victor Alvarez at VirusTotal, purpose-built for identifying and classifying malware. A YARA rule is a small, declarative description of a file or memory region: a set of textual or binary strings to look for, plus a boolean condition over those strings (and over file metadata like size, entrypoint, or PE header fields) that decides whether the sample matches. Unlike a hash-based IOC, which breaks the moment a single byte of the malware changes, a well-written YARA rule can match an entire family across recompiles, packers, and minor code changes, because it targets the parts of the binary that are expensive for the author to change: unique strings, config-decryption constants, import combinations, or structural byte patterns.

YARA sits at the center of most threat-hunting and malware-classification pipelines. Antivirus and EDR vendors ship YARA-based detections; VirusTotal runs every submitted sample against a large public and private rule corpus and lets analysts retro-hunt across its dataset; incident responders write rules from a single confirmed sample and sweep an entire fleet with yara -r or push the same rule into osquery’s yara table or into Velociraptor’s Windows.Detection.Yara artifact for scale. Because rules are plain text, they are also the natural exchange format for sharing detection logic between organizations and CERTs — MISP, OpenCTI, and most TIP platforms treat YARA rules as first-class indicators alongside hashes and network IOCs.

Attack Prerequisites

“Prerequisites” here means what has to be true for a YARA rule to be useful, since YARA is a defensive/hunting tool rather than an exploit:

  • A representative sample or memory image to extract strings and structural features from — strings, a hex editor, or a disassembler (Ghidra/IDA) to find unique constants, mutex names, C2 config markers, or format strings.
  • Enough specificity to avoid false positives — strings shared with legitimate software (common CRT strings, generic PE boilerplate) will make the rule fire everywhere; the rule needs to target the malware-specific bits.
  • The YARA engine itself in the collection path — the standalone yara/yara64 CLI, the yara-python bindings, or a host agent that embeds libyara (ClamAV, osquery’s yara/yara_events tables, Velociraptor, many EDRs) positioned to scan the files or process memory you care about.

How It Works

A YARA rule has three optional sections inside rule name { ... }: meta (free-form key/value metadata — author, date, reference, hash — ignored for matching), strings (a set of named patterns identified with a $ prefix), and condition (a boolean expression that must evaluate true for the file to match). Strings can be plain ASCII/wide text ($s1 = "malicious.dll" wide ascii), regular expressions ($r1 = /cmd\.exe \/c .{0,40}/), or hex byte patterns with wildcards and jumps ($h1 = { 8B 4? ?? 33 C0 [2-4] E8 }), which is how YARA matches instruction sequences or file-format magic bytes even when a handful of bytes vary between samples.

The condition is where the real classification logic lives. It can reference individual strings ($s1), counts (#s1 > 3), offsets (@s1 == 0), sets (any of ($s*), all of them, 3 of ($a,$b,$c)), and built-in facts about the file such as filesize, entrypoint, and PE-module fields once import "pe" is declared (pe.imports("advapi32.dll", "CryptEncrypt"), pe.number_of_sections, section characteristics, digital-signature presence). This is what lets a rule say something precise like “a PE under 2 MB whose entrypoint section is executable-and-writable, that imports VirtualAllocEx/WriteProcessMemory/CreateRemoteThread, and contains this specific base64 config marker” — a much stronger signal than any single string alone.

Matching happens in two places: on-disk files and live process memory. libyara can scan a process’s address space directly, which matters because many loaders and packers only reconstitute the real payload in memory, so a file-only scan misses it — this is why in-memory YARA sweeps are a standard step after a suspicious CreateRemoteThread or reflective-load detection.

Practical Example / Configuration

A compiling, realistic rule for a generic Windows PE loader/stager. It combines a PE sanity check (uint16(0) == 0x5A4D, the MZ magic), a filesize bound to reduce false positives on huge legitimate binaries, an ASCII marker string, a wide-char string (common for Windows UI strings and many malware config blobs), and a hex byte pattern for a short shellcode stub, all tied together with a weighted condition:

rule Suspicious_PE_Stager_Generic
{
    meta:
        author      = "IR Team"
        description = "Generic small PE stager: staging marker, "
                      "shellcode-loader stub, reflective-load imports"
        date        = "2026-07-12"
        reference   = "internal-case-2026-0417"
        tlp         = "amber"

    strings:
        $marker_ascii = "STG_CONFIG_v2" ascii
        $marker_wide  = "STG_CONFIG_v2" wide   // UTF-16LE variant
        $ua           = "Mozilla/5.0 (compatible; stg)" ascii

        // PUSH EBP / MOV EBP,ESP / SUB ESP,imm8 / [gap] / CALL rel32 --
        // typical shellcode-stub prologue
        $stub_hex     = { 55 8B EC 83 EC ?? [0-6] E8 }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 2MB and
        pe.imports("kernel32.dll", "VirtualAllocEx") and
        pe.imports("kernel32.dll", "WriteProcessMemory") and
        pe.imports("kernel32.dll", "CreateRemoteThread") and
        (any of ($marker_ascii, $marker_wide)) and
        (1 of ($ua, $stub_hex))
}
YARA

A second, minimal rule completes the kit: an in-memory-only check that flags reflective PE loading purely from structural evidence — a MZ/PE header pair sitting inside a memory region that should not contain a mapped module — with no dependency on any string content at all:

rule Mem_Reflective_PE_Load
{
    meta:
        description = "MZ/PE header pair in a memory region that should "
                      "not contain a mapped module (reflective-load indicator)"
        scope       = "memory-only"

    strings:
        $mz = { 4D 5A }               // 'MZ'
        $pe = "PE\x00\x00"

    condition:
        $mz at 0 and $pe in (0..1024)
}
YARA

Walkthrough / Exploitation

A typical response/hunt cycle: validate syntax, scan the confirmed-bad sample, then sweep the estate on disk, in memory, and finally at scale via VirusTotal retrohunt:

# Validate syntax without scanning (fails fast on typos)
yarac stager.yar /dev/null 2>&1 | head

# Scan one file, show matched strings + offsets
yara -s stager.yar /cases/case-0417/sample.exe

# Recursive filesystem sweep across an evidence mount
yara -r -f stager.yar /mnt/evidence/quarantine/

# Scan a running process's memory by PID (Linux libyara build)
sudo yara stager.yar 4821

# Fleet-wide via osquery, ad hoc from the osquery shell
osqueryi "SELECT path, matches, count FROM yara "
         "WHERE path LIKE '/opt/staging/%' AND sigfile='/opt/yara/stager.yar';"

# Estate-wide scoping without deploying the rule everywhere: VirusTotal retrohunt
vt retrohunt create stager.yar --notify-if-match
vt retrohunt matches <retrohunt-id>
Bash

Note: Broad ASCII/hex strings without a filesize, PE-magic, or import-table constraint are the number-one cause of noisy rules — a bare $s1 = "http://" will match a large fraction of any binary corpus. Anchor conditions with uint16(0) == 0x5A4D for PE, uint32(0) == 0x464C457F for ELF, and prefer pe.imports()/pe.exports() over string matching on API names, since those survive string obfuscation.

Opsec: Scanning process memory (yara <pid>) requires the same privilege as attaching a debugger to that process (root/SYSTEM in most cases) and can briefly suspend the target; do it deliberately, not as a blanket sweep of every PID on a production host. When distributing a hunting rule externally, strip internal reference/case-number metadata from meta first — TLP markings help, but analysts routinely forget to scrub them.

Detection and Defense

From the defender’s seat, YARA is itself the detection tooling, so the “defense” question is really about deploying it well and keeping rules healthy:

  • Fleet-wide scanning cadence — schedule YARA scans of new/modified files via osquery’s yara_events or Velociraptor’s Windows.Detection.Yara artifact rather than relying on manual sweeps.
  • Memory scanning after loader indicators — trigger an in-memory YARA pass whenever EDR flags CreateRemoteThread or unbacked executable memory, since packed/reflective payloads often never touch disk.
  • Rule quality control — test every new rule against a benign corpus before deployment to catch false-positive strings; keep rules under version control with meta.date/meta.hash for provenance.
  • Feed integration — ingest community rule sets (YARA-Signature-Base, Elastic’s protections-artifacts, abuse.ch) and re-run retrohunts as new intelligence lands.

Logging-wise, treat YARA matches as first-class alerts: forward yara_events rows and hunt results into the SIEM with the matched rule name, string offsets, and sample hash preserved for immediate pivot to full triage.

Real-World Impact

YARA underpins detection content at essentially every major AV/EDR vendor and threat-intel shop; VirusTotal’s retrohunt and Livehunt features are built directly on it, and MITRE ATT&CK-mapped rule repositories (e.g. Neo23x0’s signature-base, Elastic’s protections-artifacts) are consumed by thousands of SOCs. High-profile malware families — from commodity loaders like Emotet and Qakbot to targeted APT implants — have historically been tracked and clustered largely through shared YARA rule matches long before full reverse-engineering reports were published, because a good rule can surface new variants within minutes of upload to a public sandbox.

Conclusion

YARA converts “this looks like the malware I already analyzed” into a precise, testable, shareable boolean expression. The craft is in the condition, not the string list: anchor on structural facts (filesize, PE magic, import combinations) that are expensive for an attacker to change, keep memory-scanning in the loop for reflective loaders, and validate every rule against a clean corpus before it goes into a fleet-wide hunt. Done well, a single rule extracted from one incident becomes the trigger that finds every other host already compromised by the same family.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL