A YARA rule is a small text file that describes a pattern and a condition. A scanner checks files or process memory against it and reports a match when the condition is true. Analysts use rules to classify malware samples and to hunt for related files, often by searching for distinctive strings.
The anatomy of a rule
A rule starts with the keyword rule and a name. The name is case sensitive and limited to 128 characters. Optional tags can follow after a colon.
Then come up to three sections:
- meta: optional labels such as author, description or date. Values can be text, integers or booleans, and the condition cannot refer to them.
- strings: optional definitions. Each identifier starts with a dollar sign.
- condition: required. A boolean expression that decides whether the rule matches.
The documentation's simplest valid rule does nothing at all:
rule dummy
{
condition:
false
}
The three string types
Text strings sit in double quotes. Modifiers such as nocase, wide, ascii, xor, base64 and fullword change how matching works. Wide is useful because Windows programs often store text as two byte characters.
Hexadecimal strings sit in curly braces. They support wildcards, jumps like a range of unknown bytes, and alternatives. They are how you match raw byte sequences.
Regular expressions sit between forward slashes, with optional modifiers.
Writing a first rule
Take a harmless test file you made yourself, not live malware. Pick two or three strings that appear in it and nowhere obvious elsewhere. Write a condition that requires all of them. Run the rule against that file, then against a folder of ordinary files to look for false matches.
If a rule matches your own system files, the strings are too common. Make them more specific, or require more of them.
What makes a rule good
- Strings that are distinctive to the thing you describe, not to the compiler or a common library.
- A condition that combines several signals instead of one string.
- Metadata that records why the rule exists and where its samples came from.
- A test set of both matching and non matching files, kept with the rule.
How it relates to the Pyramid of Pain
String based rules usually sit at the tools level. They hurt an attacker more than a hash does, because the tool must change, but less than behavior detection. Use them as one layer.
Reading someone else's rule
When you find a rule in a report, read the condition first. It tells you how many of the strings must appear and in what combination. Then read each string and ask whether it could appear in legitimate software. A rule that matches on one common word is a hunting aid at best.
Check the metadata for a date and a source. Rules age as malware changes, and a rule with no date is hard to trust.
Where rules run
Teams run rules in sandboxes, in endpoint products that accept them, in malware repositories and in scripts that scan file shares. Each place has its own speed and false positive tolerance, so a rule that is fine in a lab may be too slow or too noisy elsewhere.
Quick check
Does YARA only scan files?
The documentation describes rules that apply to files or processes, evaluating patterns in file contents or process memory.
Is meta used for matching?
No. Metadata cannot be referenced in the condition. It is documentation for humans and tools.
Sources
Last reviewed: 19 October 2026.
