Yara Rule Writing

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

YARA is the standard language for pattern-matching malware — rules that describe the byte sequences, strings, and structure that identify a malware family, then match them across files, memory, and repositories. A good YARA rule catches the whole family (including new variants), not just the one sample you analysed; a bad one either misses variants or false-positives on legitimate files. This skill covers writing rules that generalise well and stay precise.

When to use it

After analysing a sample, to turn that analysis into a durable, family-level detection (feeds detection-engineering, threat-hunting, and IR scanning). It's how malware analysis produces detection that catches the next sample from the same actor, not just the one you have.

Procedure

1. Analyse first, then generalise. A rule is only as good as your understanding of the family. From analysis (static/dynamic/code), identify what's characteristic and stable across the family versus what's specific to this one sample. You want to match the former.
2. Choose distinctive, stable features — the art of good YARA:
   • Unique strings — distinctive strings the malware author wrote (a custom mutex name, an unusual error message, a C2 URL pattern, a PDB path) that are unlikely in benign files.
   • Code/byte patterns — a distinctive sequence of bytes from a characteristic routine (a decryption stub), using wildcards for the parts that vary (addresses, registers).
   • Structure — PE characteristics, section names, imports combinations. Avoid features that are common to many programs (they cause false positives) or that trivially change between variants (they miss them).
3. Write the rule with a good condition. Combine features so the rule is specific but not brittle — e.g. "N of these M distinctive strings" tolerates variant differences while staying precise:

   rule Family_X {
     strings:
       $a = "distinctive_mutex_name"
       $b = { 8B 45 ?? 33 D2 F7 75 ?? }      // code pattern, wildcards for variable bytes
       $c = "unusual C2 path pattern"
     condition:
       uint16(0) == 0x5A4D and 2 of them      // PE + at least 2 of the 3 features
   }
   

4. Test against both malware and benign corpora — mandatory. Run the rule against a set of the family's samples (does it catch them, including variants?) and a large set of known-good files (does it false-positive?). A rule untested against goodware is a false-positive incident waiting to happen.
5. Balance breadth and precision. Too specific (matches only your one sample) misses variants; too broad (matches common patterns) false-positives. Tune toward "catches the family, matches nothing benign".
6. Add metadata and share. Author, date, family, reference, and confidence in the rule's meta block, so others can use and trust it. Contribute to shared rule sets where appropriate.

Cheatsheet

analyse -> identify what's STABLE across the family vs specific to this sample
           (match the stable, characteristic features)

good features (distinctive + hard to change)
  unique author strings: custom mutex, odd error msg, C2 pattern, PDB path
  code/byte patterns from a characteristic routine (wildcard the variable bytes)
  structural: section names, import combos, PE traits
avoid: common strings/patterns (false positives) | trivially-varying bytes (misses variants)

condition tips
  uint16(0) == 0x5A4D          // is a PE (MZ)
  N of ($a,$b,$c)              // tolerate variant differences, stay precise
  $x at 0 / in (0..1024)       // position constraints

TEST both ways (mandatory)
  vs family samples + VARIANTS  -> does it catch them?
  vs large GOODWARE corpus      -> does it false-positive?

balance: too specific = misses variants ; too broad = false positives
meta: author, date, family, reference, confidence -> shareable + trusted

Reading a rule's quality

• Catches the family including variants you didn't train on = a good, generalising rule; the whole point of family-level (not sample-level) detection.
• Matches only the exact sample you analysed = too specific; it's really just a hash with extra steps and misses the next variant. Generalise to stable features.
• False-positives on the goodware corpus = too broad or built on common features; unusable in production and erodes trust. This is why testing against benign files is mandatory, not optional.
• Built on author-written distinctive strings + a wildcarded code pattern = the durable core; these are hard for the author to change without effort (Pyramid-of-Pain thinking applied to signatures).
• An N of them condition = tolerant of variant differences while staying precise; usually better than requiring all features.
• A tested, metadata-rich rule that catches the family and nothing benign = the deliverable — durable detection from your analysis.

Pitfalls

• Writing a rule that matches only your one sample. Overfitting to sample-specific bytes gives you a glorified hash; match the family's stable, characteristic features so it catches variants.
• Not testing against goodware. The single biggest YARA mistake — an untested rule false-positives on legitimate files in production. Always test against a large benign corpus.
• Using common strings/patterns. Features shared with benign software guarantee false positives; choose distinctive, author-specific ones.
• Rigid byte patterns. Matching exact bytes that vary between variants (addresses, registers) misses them; wildcard the variable parts.
• No metadata. A rule without author/family/reference is hard for others to trust or maintain; fill the meta block.

References

• YARA documentation (virustotal.github.io/yara)
• yarGen / rule-generation tools (as a starting point, then hand-tune)
• The extracting-iocs, static-triage, and detection-engineering skills
• MITRE ATT&CK and the threat-intel pyramid-of-pain skill (durability thinking)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.