← Glossary

Threat Intel Concepts

YARA Rule

Also: YARA · YARA rule · YARA signature · malware detection rule

Last reviewed:

In one sentence

YARA is a pattern-matching language for describing files — you list the strings, bytes or regexes that characterise a piece of malware and a boolean condition over them, and the YARA engine flags any file that matches, which is how analysts hunt for a malware family across a fleet.

Why it matters

A file hash catches exactly one file — recompile the malware and the hash changes, and your IOC is useless. YARA solves the durability problem: instead of "this exact file", a rule says "any file containing these characteristic strings arranged this way". That describes a malware family or an author's habits, so one good rule keeps matching across recompiles, minor variants and packers — the whole point of hunting rather than blocklisting.

It is the shared language between malware analysts and everyone downstream. Threat researchers publish YARA rules; incident responders sweep disks and memory with them; VirusTotal and EDR platforms run them at scale. Where Sigma describes suspicious log events, YARA describes suspicious files and bytes — the two cover different halves of detection.

Strings and the condition

A rule has three parts — metadata, strings, and a condition:

rule Suspicious_Downloader {
    meta:
        author = "analyst"
    strings:
        $s1 = "http://" nocase
        $s2 = { 4D 5A }            // MZ header bytes
        $re = /powershell.{0,20}-enc/ nocase
    condition:
        uint16(0) == 0x5A4D and any of ($s*)
}
  • Strings come in three flavours: plain text, raw hex byte sequences, and regex. Modifiers refine text matching — nocase, wide (UTF-16), ascii, fullword, plus xor and base64 for obfuscated data.
  • The condition is boolean logic over the strings: any of them, all of them, 2 of ($s*), counts like #s1 > 2, and file facts like filesize and uint16(0) for magic bytes.

The performance rule of thumb that separates a usable rule from one that grinds a scan to a halt: bound it — put a filesize limit or a magic-byte anchor in the condition so the engine can reject most files instantly instead of scanning every byte of every file.

Try it yourself hands-on

Build a rule from a suspicious sample and test it before you deploy it.

  1. Open the YARA Rule Builder. Add a couple of text strings you saw in the sample (say a suspicious URL and a mutex name), toggle nocase, and add a hex string like 4D 5A for the MZ header. The YAR Preview renders valid syntax live as you go — everything is client-side, no sample leaves the page.
  2. Set the condition. Start with any of them, then tighten to uint16(0) == 0x5A4D and any of them so the rule only fires on PE files. Note the builder's warning if you forget a filesize bound — that is it steering you away from a rule that would hammer a real scan.
  3. Use the Quick Tester: paste a sample line or decoded payload and run the rule. It evaluates your text and regex strings and a subset of conditions right there, showing MATCH or no match so you catch a too-broad or too-narrow rule before it reaches production.
  4. Feed it good inputs: defang and normalise indicators from a report with the IOC Defanger, and confirm a sample's true type with the File Signature Identifier so your magic-byte condition is correct.

Result: a syntactically valid, performance-bounded YARA rule you have already test-matched — not a rule you find out is broken only when the scan returns nothing.

Common misreadings

  • Broad strings cause false positives. A rule that fires on "http://" alone will match half your disk. Combine several distinctive strings and anchor with file facts.
  • Unbounded rules are slow. Without a filesize or magic-byte gate, the engine scans every byte of every file — painful at fleet scale. Always bound the condition.
  • YARA matches files, not behaviour. It cannot see what a process does at runtime; pair it with Sigma / EDR telemetry for the behavioural half.