0.5 What a Match Is Worth

A match is one sentence: the bytes described by this rule are present in this file. Everything else a match seems to say is something the reader supplied, and the gap between the sentence and the reading is where most YARA mistakes live. This section is about that gap. It matters most at the end of a hunt, when an empty result or a page of hits has to become a sentence in a report that somebody acts on, and the words available are considerably stronger than the evidence behind them.

What a match establishes

Precisely this: the pattern described by the rule was found in the file, at some offset, by this engine, on this scan.

That is a fact about bytes. It is genuinely useful, it is cheap to obtain across a large estate, and it is the entire output of the tool. Three things follow from it that are worth having explicitly, because each is a step people take without noticing.

It establishes that somebody's rule considers this file a member of some set. Whose rule, and how good, are separate questions, and with a public rule set the answer to both may be unknown to you.

Public rule sets are worth using and worth reading before you trust them. They are written by people with different corpora, different estates and different tolerances for noise, and a rule that is well tuned for its author's environment can be badly wrong for yours. None of that is visible from a hit; all of it is visible from thirty seconds spent reading the rule body.

It establishes that the file is worth looking at. That is the honest role of a hit: a pointer, not a verdict.

Framing a hit as a pointer changes what you do next, and the change is practical rather than philosophical. A verdict closes an investigation; a pointer opens one. If the next action after a YARA hit is containment rather than a look at the file, the hit has been read as something it is not, and the cost of that mistake scales with how much authority the person reading it has.

It does not establish anything about what the file did, who put it there, whether it ran, or whether the rule's name is accurate.

Those four are worth naming because they are the four readings that actually cause damage, and the rest of this section takes them one at a time. None of them is an unreasonable inference; each is the sort of thing a competent person concludes at two in the morning from a console showing a hit, which is exactly why they need saying out loud.

It does not mean malicious

The rule matched because the bytes were there. Whether their presence means the file is harmful depends entirely on how good the rule is, and the rule is a hypothesis written by a person from one sample.

Prove it to yourself rather than taking it. Write a rule describing genuine capability, point it at software you trust completely, and count.

yr scan dual_use.yar /usr/bin/ | wc -l
44
yr scan dual_use.yar /usr/bin/ | head -4
Dual_Use_Networking /usr/bin/Xvfb
Dual_Use_Networking /usr/bin/busctl
Dual_Use_Networking /usr/bin/dbus-daemon
Dual_Use_Networking /usr/bin/curl

Forty-four hits on system software, from a rule requiring three networking strings together. Every one is a true positive against the rule as written: the rule asked whether the file contains all three, and the files contain all three. Nothing malfunctioned.

What failed is the inference somebody would draw from a console showing forty-four hits on a rule named for network capability. And the important part is that no amount of care in writing that rule fixes it, because network capability is not a property that distinguishes malicious software from curl. curl is a network tool. The rule is describing a category the target belongs to along with a great deal of legitimate software, and that is a choice of pattern rather than a bug.

The habit worth building now: when a rule fires, read the rule, not the rule name. What patterns did it actually require, and could they appear in something legitimate? That takes thirty seconds and prevents a whole class of confident wrong escalation. It cuts the other way too, because reading the rule sometimes tells you a hit is stronger than it looks: a rule requiring three independent patterns, two of them structural, is much better evidence than one requiring a single common string, and both arrive in your console looking identical.

It does not mean the file ran

A file matching a credential-stealer rule, sitting in a downloads directory, has stolen nothing. It may never have been opened.

YARA reads bytes at rest. Execution is a completely different evidence source, and the distinction is the one between what a file is equipped to do and what it did. A match is always on the first side of that line.

Holding that line matters most when the file is genuinely alarming, which is when the pressure to overstate is highest. A confirmed ransomware binary in a user's temp directory is worth acting on urgently and it is still, on the evidence of a scan alone, a file that was written to disk. Whether it ran is a question for endpoint telemetry, and answering it from a YARA hit is the same error as the twelve-hosts sentence above with more at stake.

This is the inference most likely to escape into an incident report, because the language slips so easily. "We found the stealer on twelve hosts" and "twelve hosts have a file matching our stealer rule" describe identical evidence and imply very different things. The second costs four extra words and it is the one that survives review. It also keeps the next question answerable: if somebody asks whether those twelve hosts are compromised, the first phrasing has already answered yes on your behalf.

The rule name is not evidence

Rule names carry attribution and attribution is frequently wrong.

Family naming across the industry is inconsistent, tooling is shared and sold between groups, and a rule keyed on a common packer or a builder kit will fire across families that have nothing to do with each other. A hit from a rule called APT_Loader_Generic establishes that a rule with that name matched.

This matters more than it used to, because so much tooling is shared. A rule keyed on the tool identifies the tool rather than whoever was holding it, which can still be useful intelligence provided the write-up says which of the two it is. Where the family matters, the rule's own basis is what you check.

There is a practical reason to prefer rules you wrote over public ones where the attribution matters, and it is not about quality. A rule you wrote is one whose basis you already know, so when it fires at two in the morning the evaluation takes seconds. A public rule with a confident name requires you to read it first, and reading somebody else's rule under time pressure is exactly when the name gets trusted instead.

An absence establishes least of all

The direct descendant of Section 0.1. No match means no match. It does not mean the file is clean and it does not mean the estate is clean.

The rule may be keyed on something the actor changed. The scan may not have reached the file, because it was locked, encrypted, inside an archive the engine does not unpack, above a size limit you set, or on a host that was powered off. Any of those produces a result identical to genuine absence.

Before a negative becomes a finding, prove the check could have returned something. Run the rule against a file you know matches, and run the scan with -n so the files examined are listed rather than assumed. Both take seconds, and between them they turn an empty result from a silence into a measurement.

The two checks answer different questions and you need both. The -n run proves the scan reached the population; it says nothing about whether the rule was capable of firing, and a rule with a subtly wrong pattern will report every file as a non-match, correctly, forever. The positive control proves the rule can fire; it says nothing about coverage. Together they close the gap, and either alone leaves half of it open.

What YARA cannot see at all

Worth stating plainly so you do not go looking for it.

Behavior. What a process did, what it connected to, what it wrote. That is telemetry, and it is a different discipline with different tools.

The boundary is worth respecting rather than working around. Analysts sometimes try to infer behavior from a static match, reasoning that a file containing a network string must have made a network connection. It may never have run. Section 0.2's family was compiled and never executed, and every rule in this course matched it, which is a small demonstration of a large point.

Provenance. Who sent the file, to whom, and whether they opened it. A rule sees the file, not its history.

Provenance is frequently the thing that decides how much a hit matters, which is why its absence from the tool's output is worth planning around. The same binary matching the same rule is a different situation in a user's downloads folder, in a system directory, and in a scheduled task, and none of that context is in a scan result. Whatever pipeline consumes your hits should be carrying the path forward, and the path is often the most informative field in the output.

Intent. Software is not malicious in its bytes. A remote administration tool and a remote access trojan can be the same binary used differently, and no rule resolves that. Plenty of dual-use software is flagged by public rule sets for exactly this reason, and the hits are correct about the bytes and wrong about the situation. The practical handling is to keep the judgment out of the rule: a rule identifying a remote administration tool accurately is useful, and whether a hit on it matters is a question about your estate rather than about the file.

Reporting guide: write the sentence the evidence supports

Step 1, run the dual-use rule against your clean corpus and count the hits. Read three of the matched filenames.

Step 2, write the sentence you would put in a report if this rule had fired during an incident, then rewrite it to claim only what the scan established.

Step 3, take a rule you did not write, from any public rule set, and read its patterns rather than its name. Decide whether a hit from it would be strong or weak evidence, and why.

Step 4, run a rule that matches nothing and write the sentence for that too. Then run it with -n and write the sentence again.

Step 5, note the difference between the two negative sentences. That difference is what the flag bought you.

Keep both sentences somewhere you will see them again. The gap between what you would naturally write and what the evidence supports is a habit of language rather than a fact you learn once, and it closes with practice rather than with agreement. Most people read this section, agree with it entirely, and write the stronger sentence the next time they are under pressure.

Section 0.6 closes the module and sets out what the seven modules build, now that you know what the tool does and what a result from it is worth.