YARA Rules

A YARA rule is a detection you own. You describe what a file looks like on the inside, save the rule, and Stairwell tells you which files satisfy it: the files it already holds as well as the ones that arrive afterward. This section takes you from never having written a rule to running a set of rules you trust, and covers the rule feeds Stairwell maintains on your behalf.

If you do not yet know what a YARA rule is, read What is a YARA rule? first. It is the concept; this section is the practice.

Where should I start?

What happens when I save a rule?

Saving an active rule is what produces the answer. You do not schedule a scan and you do not wait for the next collection cycle: Stairwell runs the rule across the files it holds, so the matches you get back include files that arrived long before the rule existed, and the rule keeps matching new arrivals from then on. Stairwell calls this Warpspeed.

Three things happen on the way, and all three are visible in the product:

1. Stairwell checks the rule before it saves. The editor reports errors as you type, and the save action stays unavailable until the rule is free of errors. Advisory warnings do not block a save.
2. The rule is measured against known-good files. Until that check finishes, the Rules list shows the rule as not yet checked. A rule that matches too many sources of known-good software is excluded from scanning, and the list says so rather than sending you a wave of matches.
3. Progress is reported while the rule works through your history. The rule panel shows how far along it is, and the My objects and Malware objects columns in the Rules list fill in with match counts you can click through to.

How do rules here differ from plain YARA?

YARA is an open language, and a rule you write in Stairwell is the same artifact you would write anywhere else. Four differences are worth knowing before you paste in a rule from elsewhere, because each of them is otherwise discovered by having the rule fail:

• You do not write import lines. Every rule already has the pe, elf, cuckoo, hash, math, dotnet, time, and magic modules available. Modules outside that set are not supported, and an import of one is the line to delete.
• Rules cannot reference other rules. Every rule stands alone, so a shared helper rule has to be inlined into each rule that used it.
• One rule per save. Bulk-load a multi-rule file rather than pasting it into the editor.
• Hashes in the metadata become reference files. Record the sample you wrote the rule against and that file, along with files resembling it, is looked at sooner.

Writing Your First YARA Rule covers all four in the place where they come up.

Is a rule match a detection?

No. A match is evidence, and evidence is not a verdict. A rule that fires on a legitimate remote administration tool has produced a match, not a detection, and the same is true of packers, credential utilities, and penetration-testing frameworks, because attackers use exactly those tools.

So treat a match as a starting point and weigh the file against the things a rule cannot know: how rare it is (see Prevalence), what the automated verdict says, which of your assets have seen it, and whether your team has already recorded an opinion about it. This is a load-bearing idea in rule writing, not a caveat at the end of it. It is also why the craft of rule writing is the craft of being specific, which is the subject of YARA Rule Best Practices.

Who can create and edit rules?

Creating, editing, deleting, and enabling rules require write access to the environment the rule lives in. Rules that reach you from a shared rule set or from another environment are read-only: to modify one, copy its body into a new rule of your own. See Environments for how that boundary works.

What should I read next?

• Writing Your First YARA Rule, if you want a working rule in the next ten minutes.
• Hunting and Search, for finding the files a rule matched and pivoting from them.
• An EDR Alert Just Fired, for what a match looks like in the middle of real work.