Tools · Forensics tools · 11 / 25
YARA: a rule is a claim you can run again
A YARA rule names the bytes you care about and the condition that counts as a hit. A hit means the pattern was present. It is a queue for an examiner, and the meta block is how the next person knows why the rule exists.
The rule is the claim
YARA scans files you already have and reports which rules match. You write the rule before you trust a pile of hits. The rule has a name, an optional meta block, a strings block, and a condition. The name is the identifier you will see in the output, so it should carry the case or the behavior in words a teammate can read. NL_Payroll_Temp_Name is a better identifier than Rule1. The meta block is comments the scanner does not treat as a pattern: author, description, the case number, and a date. Put the reason there. A rule without a reason becomes folklore.
The strings block is the evidence you are willing to search for. The condition says how those strings combine, and it can also talk about file size or, with a module, about structure. A file matches when the condition is true. Matching is not a conviction. Legitimate software and documents contain ordinary words. Your condition is how you keep “xlsx” from matching every spreadsheet on the image.
Name, meta, strings, condition
Keep the four parts in that order so a reader can audit them. Meta is where NL-2026-041 lives, plus one sentence of description. Strings are named with a dollar sign so the condition can refer to them. A string can be text or a hex pattern. The condition is a boolean. all of them, any of them, and a count such as 2 of ($s*) are the combinations you will use most. filesize < 2MB is a brake that keeps a tiny lab pattern from being discussed as if it applied to a 4 GB image file you never meant to scan.
The scanner does what the condition says, including when you meant something narrower. If you write a condition that is only $ext and $ext is the text xlsx, you will match documentation, scripts, and the workbook. Add the temp path fragment and the staged name if those are the bytes that define this question. Every extra string is a promise that a hit is more specific, and it is also a chance to miss a renamed copy. Choose the specificity that matches the question, and write that choice in meta.
rule NL_Payroll_Staged_Name
{
meta:
author = "Northline lab"
case = "NL-2026-041"
description = "Lab rule for the staged workbook name in a small file"
strings:
$staged = "p4.xlsx" ascii
$temp = "\\Temp\\" ascii
condition:
filesize < 5MB and all of them
}Read a hit as a pointer
When the scanner prints a filename under the rule name, open that file in the case and see the bytes that matched. Use the flag that prints the matching strings so you are not guessing which part fired. A hit on a path you already tagged in Autopsy is corroboration that the extract contains the name. A hit on a log file means the log mentions the name, which is a different exhibit from the workbook itself. The rule does not know the difference. You do, because you look.
Save the rule file next to the output. A hit without the rule text is a filename and a slogan. The rule file is the procedure you ran, in the only form that can be rerun. If you edit the rule after the scan, save the new version under a new name or a version in meta, and scan again. Do not quietly replace the text that produced yesterday’s hits.
Scan the collection you were given
Point YARA at the export folder or the mounted image paths that are inside the case. A recursive scan of an entire examiner workstation will walk your mail, your browser, and anyone else’s cases. The lab copy of NL-FIN-14’s tagged extracts is the collection for this exercise. If a rule is useful to the SOC, they will ask you to run it on their sensors under their change process. A good rule in the case folder is the handoff. A scan of a network share nobody named is a new incident, and it is not this lesson.
False positives go back into the rule as a tighter condition, or they stay as a documented exception. Deleting a hit from the output file and leaving the rule loose means the next scan will surprise someone. Write “hit on the office template, ignored, because …” in the case log if you mean it.
Worked case: one rule for the staged name
You write NL_Payroll_Staged_Name, as in the sample, with the case number in meta. You run it against the manifest folder that holds the Temp extract, the Documents extract, and the Autopsy timeline CSV. The two workbook extracts do not contain the text p4.xlsx inside the file body, so they do not hit, and that is fine: the rule was about the name appearing in a small file, not about the spreadsheet format. The timeline CSV hits, because the path is in a cell.
You record the CSV hit as a mention in your own notes, and you keep the rule for the Sysmon export and any script text CyberChef produces later. The rule file is saved as NL-2026-041-staged-name.yar with a one-line log: “version 1, scanned the tagged export folder, one hit in the timeline CSV.”
Diagram
From a case question to a rule you can rerun
- Question
Name the bytes that would answer it. Here, the staged filename and a Temp path fragment inside the case collection.
- Meta
Put the case number, the author, and one sentence of intent where a later reader will see them.
- Condition
Combine the strings so ordinary spreadsheets do not all match, and cap the size if you are scanning mixed exports.
- Output
Save the rule and the hit list together. Open each hit and say whether it is the file or a mention.
NL_Payroll_Staged_Name exports/timeline.csv $staged, $temp # A mention in the notes, not a second workbook.
Check yourself
1. A rule named payroll matches every file that contains the text xlsx. The export folder has forty spreadsheets. What did the rule actually establish?