scanning-samples-with-yara

Uses YARA to classify and triage samples at scale: applying rule sets, reading matches and string offsets, tuning for false positives, and organizing rules for malware family identification. Activates

SKILL.md

GitHub

Scanning Samples with YARA

When to Use

  • You want to classify one or many samples against known malware-family or capability rules.
  • You need to confirm a family hypothesis with a targeted rule and read which strings matched.
  • You are triaging a directory of files and want to flag the suspicious ones.

Do not use a YARA match as proof of family attribution on its own — public rules vary in quality and can over-match. Corroborate with behavior or code analysis.

Prerequisites

  • yara CLI or yara-python (pip install yara-python).
  • A curated rule set (your own plus vetted public rules). Avoid blindly merging large noisy collections.
  • Samples in neutralized form inside the lab.

Workflow

Step 1: Organize rules

Keep rules in categories (family, capability, packer, anomaly) and compile them once for speed. Tag rules so matches are self-describing.

Step 2: Scan and read matches

python scripts/analyst.py scan rules/ sample.bin
# prints matched rule names, tags, and matched strings with offsets

The matched string offsets matter: they tell you where in the file the signal is (header, overlay, resource), which guides deeper analysis.

Step 3: Triage a directory

python scripts/analyst.py scan rules/ ./samples --recursive --summary

Rank files by number/severity of matches to prioritize analyst time.

Step 4: Tune for false positives

If a rule fires on benign files, tighten it: require multiple strings (2 of ($a*)), anchor to file structure (uint16(0) == 0x5A4D), or raise the condition specificity.

Step 5: Promote good signals to detection

A rule that reliably identifies a family or capability becomes a hunting/detection artifact — hand it to the detection-engineering workflow.

Validation

  • Matches reproduce across runs and tools (CLI and yara-python agree).
  • Each kept rule has an acceptable false-positive rate against a known-clean corpus.
  • Match offsets correspond to meaningful file regions, not incidental byte coincidences.

Pitfalls

  • Merging huge public rule packs without curation — noise and false positives explode.
  • Writing rules on packed bytes that change with every build; prefer unpacked or structural features.
  • Over-broad strings (common library text) that match unrelated software.

References