Skip to content
yararules.org
Menu

Writing YARA rules for incident response

Use YARA during incident response: scoping, writing a rule from a sample, choosing unique strings, confidence scores, hunting across hosts and memory, and sharing.

Published 3 min read

During an incident, YARA turns one analysed artefact into a question you can ask of every host: "where else is this?" Rules written under time pressure have different priorities from rules written for a public repository — speed and precision matter more than elegance — but the same fundamentals apply.

Scoping: what to scan

  • Files on disk. Payloads, droppers, web shells, scripts, tools left behind by the attacker.
  • Triage collections. Targeted collections (for example from Velociraptor or KAPE) are much smaller than full images and scan quickly.
  • Memory. Process memory, or full memory images, reveal implants that are only decrypted at runtime, injected code and reflective loaders.
  • Archives and mail. Phishing attachments, ZIPs and ISO images in mail stores or download folders.

Decide early whether a hit means "confirm and contain" or "investigate further": that decides how aggressive the rule can be.

Writing a rule from a sample

  1. Collect candidate strings. Run strings (ASCII and UTF-16) or a disassembler over the sample. Look for mutex names, PDB paths, custom user agents, configuration markers, command names, error messages, unusual export names.
  2. Remove the noise. Drop strings that come from the compiler runtime, the standard library, packers or common frameworks. They will match thousands of clean files.
  3. Add code. When strings are encrypted, use the decryption loop, a configuration parser or a distinctive API-hashing routine as hex patterns, with operand bytes wildcarded.
  4. Structure the condition. Guard with file type and size, then require one highly specific indicator or several weaker ones.
  5. Test. At least on the sample itself, and on a set of clean files from the affected environment.
rule MAL_IR_Example_Implant
{
    meta:
        description = "Implant found on FIN-WKS-07 during case 2026-042 (example)"
        author = "IR team"
        date = "2026-09-29"
        reference = "internal case 2026-042"
        score = 80
        hash = "0000000000000000000000000000000000000000000000000000000000000000"
    strings:
        $x1 = "Global\\svc_backup_sync_mtx" ascii wide
        $x2 = "C:\\build\\agent\\Release\\svcagent.pdb" ascii
        $s1 = "/api/v2/beacon" ascii
        $s2 = "Mozilla/5.0 (Windows NT 10.0; SvcAgent)" ascii
        $s3 = { 8B 4D ?? 33 C0 8A 04 0E 34 5A 88 04 0F }
    condition:
        uint16(0) == 0x5A4D and filesize < 3MB and
        (1 of ($x*) or 2 of ($s*))
}

Confidence and scoring

Not every rule should trigger the same response. Record your confidence:

  • score (0–100) in meta: high for unique mutexes or PDB paths, lower for behavioural combinations.
  • Naming: MAL_ for confirmed malware, SUSP_ or HUNT_ for hunting leads (see the style guide).
  • Tags for routing, such as memory for rules meant for memory scans only.

Hunting across the estate

Distribute rules with whatever tool already reaches your endpoints: EDR custom-IOC features, THOR-style scanners, or Velociraptor artifacts such as Windows.Detection.Yara.Process (process memory) and Generic.Detection.Yara.Glob (files matching a glob). Start with a small pilot group to catch false positives before running estate-wide, and limit file size and paths to keep the load acceptable.

Memory versus disk

  • In memory, strings are often decrypted and code is unpacked: rules that fail on disk may match there, and vice versa.
  • Memory regions do not start with file headers, so uint16(0) == 0x5A4D guards and filesize limits do not apply in the same way. Write separate memory rules without file-header checks.
  • Mapped images of legitimate DLLs are large and numerous: prefer highly specific strings.

Documenting and sharing

When a rule leaves the incident team, add what the next analyst needs: description, reference, sample hashes, date, and a licence. Choose a TLP level for internal distribution and a licence such as the Detection Rule License for public release; the public rule sets guide explains how licences affect redistribution.

Fast feedback loop

For quick iterations without uploading evidence anywhere, paste the rule into the editor, drop the sample on the test pane, then run the scanner over a ZIP of clean files from the affected host type. Both run YARA-X locally in the browser.

FAQ

How do I write a YARA rule from a malware sample?
Extract strings and code sequences unique to the sample, discard anything that comes from compilers, runtimes or common libraries, combine a few highly specific indicators with a file-type guard, and test against clean files.
Should I scan disk or memory during an incident?
Both, when possible. Disk scans find dropped files and persistence; memory scans find implants that only exist decrypted in running processes.
What does the score meta field mean?
It is a convention, used by YARA Forge and several scanners, expressing from 0 to 100 how strongly a match indicates malicious activity.