Tools · Forensics tools · 15 / 25
YARA: test a rule before the hit becomes a finding
A rule earns a place in the report only after a must-hit file hits, a must-not-hit file stays quiet, and the wording of the finding matches the condition you actually wrote.
One file that must hit, one that must not
Before you scan the whole export folder, scan two files. The must-hit file is an extract you already understand, such as cmdline-4812.txt. The must-not-hit file is something close and ordinary, such as the stock powershell.exe or a blank office document from the same image. Run the rule on those two paths with strings printed. If the must-hit misses, the rule is wrong or the file is not what you think. If the must-not-hit matches, the rule is too wide for the sentence you wanted to write. Fix it before the long scan. A long scan of a bad rule produces a long triage of your own mistake.
Keep those two files, or their hashes and paths, in the test list. When you bump the version, rerun the pair. This is a small ritual and it catches the modifier you forgot and the filesize cap you set below the size of the positive sample.
The finding may only say what the condition says
If the condition is two path fragments and a size cap, the finding is “these files contain both fragments.” It is not “these files were uploaded,” and it is not “these files are malware.” The rest of the case may support a stronger sentence. That stronger sentence has to cite the other exhibit: the hash match, the netscan row, the Sysmon event. YARA’s paragraph should be checkable by rerunning the yar file.
Quote the rule name and version in the report the way you quote a plugin name. “NL_Payroll_Staged_Name version 2 matched cmdline-4812.txt, both strings, scan file NL-2026-041-yar-v2.txt.” A reader with the export folder can repeat it. A reader without the folder at least knows which claim was mechanical.
Version the edits
Every edit that changes matches gets a version in meta and a log line that says what changed: added wide, raised the size cap, required both strings. Keep the old yar if a previous output file depends on it, or accept that old output is obsolete and mark it. Quiet replacement is how two examiners argue from different hit lists while believing they ran “the payroll rule.”
Retire a rule by saying so. A rule written for a hypothesis you dropped should not stay in the folder that gets scanned by habit. Move it to a retired path or comment the retirement in meta and stop invoking that file. Dead rules that still run will match on the next case’s unrelated files and look like a live lead.
Worked case: version 2 passes the pair
You point version 2 at cmdline-4812.txt and at powershell.exe before you trust the folder scan you already did. The command-line file hits on both strings. powershell.exe does not hit. You add those two results to the log under “pair test, 15 April, pass.” The report sentence is the one the condition allows: the command-line extract contains the staged name and a Temp fragment. The upload claim, if it ever appears, is tied to Sysmon and the TIME_WAIT row, not to the yar file.
You leave the rule at version 2. There is no third string you have actually seen. The retired-hypothesis file does not exist yet, and you do not create a broader rule just to feel thorough.
Diagram
A pair test before the folder scan
When the rule is allowed to see the whole export folder
Input. The full export folder, including System32 copies and your own notes.
Result. A long hit list you have not compared to a known-good binary.
Finding. Easy to overstate, because the condition was never shown to reject the ordinary file.
Input. One extract that should hit, one stock file that should not.
Result. You edit until that pair behaves, then you scan and label.
Finding. The sentence cites the rule version and stays inside the condition.
Check yourself
1. The must-hit command-line extract matches. The must-not-hit stock powershell.exe also matches. What do you do before a folder-wide scan?