agentsclimarketplace

Scanning samples with yara

Skill meltedinhex/analyst-ai-pack/skills/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 for requests to scan files with YARA, apply YARA rules, or classify samples by signature.From its SKILL.md

Install
npx -y skills add meltedinhex/analyst-ai-pack --skill scanning-samples-with-yara

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.2 KB, 558 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 3 files

4.1 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.