Author YARA-X Rules
Overview
Create rules that detect the validated property the evidence supports, not a broader malware-family claim. Prefer structural combinations over unique-looking strings copied from one sample.
Read references/yara-x-rule-quality.md before selecting patterns or declaring coverage.
Workflow
- Define the detection objective and non-goals.
- Build the fixture set.
- Preserve representative positive samples and near-miss benign negatives with hashes and provenance.
- Use synthetic or redistributable fixtures for repository tests.
- Select discriminators.
- Prefer format/module facts, byte structures, stable code/config fragments, and combinations of independently meaningful strings.
- Avoid mutable infrastructure, compiler boilerplate, paths, timestamps, or one generic API name as decisive evidence.
- Author metadata and conditions.
- Include purpose, author, date, source/evidence reference, scope, confidence, and known limitations.
- Bound file type and size where it improves correctness or performance.
- Validate with current YARA-X.
- Record version; compile/lint the rule; test all positives, negatives, malformed inputs, and a bounded benign corpus.
- Investigate timeouts, warnings, and module-undefined behavior.
- Review false positives and coverage.
- Tune by improving evidence combinations, not by accumulating arbitrary exclusions.
- Preserve regression evidence.
- Store allowed fixtures or deterministic generators, expected matches/non-matches, and rule revision.
Output
Return the rule, objective, evidence basis, fixture results, performance notes, known misses/false positives, and deployment limits.
1---2name: author-yara-x-rules3description: Author, test, tune, and document YARA-X rules from validated artifact evidence. Use when suspicious files, scripts, documents, or binary features need local detection with stable patterns, fixtures, performance checks, and regression tests.4---56# Author YARA-X Rules78## Overview910Create rules that detect the validated property the evidence supports, not a broader malware-family claim. Prefer structural combinations over unique-looking strings copied from one sample.1112Read [references/yara-x-rule-quality.md](references/yara-x-rule-quality.md) before selecting patterns or declaring coverage.1314## Workflow15161. Define the detection objective and non-goals.172. Build the fixture set.18 - Preserve representative positive samples and near-miss benign negatives with hashes and provenance.19 - Use synthetic or redistributable fixtures for repository tests.203. Select discriminators.21 - Prefer format/module facts, byte structures, stable code/config fragments, and combinations of independently meaningful strings.22 - Avoid mutable infrastructure, compiler boilerplate, paths, timestamps, or one generic API name as decisive evidence.234. Author metadata and conditions.24 - Include purpose, author, date, source/evidence reference, scope, confidence, and known limitations.25 - Bound file type and size where it improves correctness or performance.265. Validate with current YARA-X.27 - Record version; compile/lint the rule; test all positives, negatives, malformed inputs, and a bounded benign corpus.28 - Investigate timeouts, warnings, and module-undefined behavior.296. Review false positives and coverage.30 - Tune by improving evidence combinations, not by accumulating arbitrary exclusions.317. Preserve regression evidence.32 - Store allowed fixtures or deterministic generators, expected matches/non-matches, and rule revision.3334## Output3536Return the rule, objective, evidence basis, fixture results, performance notes, known misses/false positives, and deployment limits.
gaelic-ghost