YARA Rule Syntax

A YARA rule has a name and up to three sections: meta, strings, and condition. The condition is the only mandatory section, but real rules use all three.

meta holds descriptive metadata that does not affect matching but is vital for triage and maintenance.

• author, date, description
• reference — report or advisory link
• hash — sample(s) the rule was built from
• tlp — sharing classification

Values are strings, integers, or booleans. Treat meta as documentation: the next responder relies on it.

The strings section defines identifiers (starting with $) bound to patterns. The simplest is a quoted text string.

Modifiers refine matching:

• nocase — case-insensitive
• wide — UTF-16 (two bytes per char, common in Windows)
• ascii — ASCII (default; combine with wide to match both)
• fullword — match only as a whole word

For binary patterns, use a hex string in braces. These match raw bytes, ideal for opcodes, magic numbers, and structures.

Hex strings support flexibility:

• ?? — wildcard nibble/byte
• [n-m] — a jump of n to m arbitrary bytes
• ( A | B ) — alternatives

YARA supports regex patterns delimited by slashes, with the same modifiers as text strings. Use regex when a pattern varies but follows a structure, like a config marker or a generated mutex name.

Regex is powerful but costly; prefer fixed strings or hex when possible, and anchor regex tightly to avoid scanning the whole file.

condition is a boolean expression that decides a match. Reference string identifiers directly; a bare $a is true if the string was found.

Combine with and, or, not, and parentheses. This is where you encode the logic that separates a real family hit from a coincidence.

YARA offers expressive quantifiers over string sets:

• any of them / all of them
• 2 of ($s*) — at least two of a group
• #a > 3 — count of matches of $a exceeds 3

These let you require, say, three of five family markers, balancing sensitivity against false positives.

Conditions can reference where a match occurs and the file's size:

• $a at 0 — match must be at offset 0
• $a in (0..1024) — within a byte range
• filesize — total size, e.g. filesize < 200KB
• uint16(0) == 0x5A4D — read an integer at an offset (here the MZ header)

Anchoring matches to position dramatically cuts false positives and speeds scanning.

YARA modules expose structured, format-aware data so conditions can reason about parsed fields instead of raw bytes.

• pe — PE imports, sections, entry point, signatures, imphash
• hash — compute md5/sha256 of regions
• math — entropy and statistics
• elf, dotnet, magic

Importing pe, for example, lets you match on imported functions or a specific imphash, far more robust than a literal string.

For richer logic, YARA supports loops over collections with for. You can express conditions like at least two of these offsets satisfy a property, or any section name matches a pattern.

This is essential when working with module data such as PE sections or imports, where you must inspect a variable-length list rather than a single value.

Rule-level keywords organize a ruleset:

• global rule — its condition gates all other rules in the file (e.g. only scan PE files)
• private rule — reusable building block, not reported on its own but referenceable by other rules
• tags after the rule name classify hits (e.g. for filtering output)

Reason about a condition's robustness.

YARA rule syntax in one view:

• A rule = meta + strings + condition
• Text strings with nocase/wide/ascii/fullword modifiers
• Hex strings with wildcards ??, jumps [n-m], alternatives
• Regex for structured variable patterns (use sparingly)
• condition combines strings with and/or/not
• Quantifiers: any/all/N of, and count #a
• Anchoring: at, in, filesize, uint reads
• Modules (pe, hash, math) match structured data and imphash
• global, private, and tags organize rulesets

Next: practical hunting with strings and hex.