What Are YARA Rules? How Malware Detection Works — and Where It Fails
A real incident from running 19,000+ YARA rules in production: how an overly broad rule triggered false positives — and what we learned from it.
What Is a YARA Rule?
YARA (Yet Another Recursive Acronym) is an industry-standard malware detection tool that lets you write conditional expressions describing specific byte sequences, strings, or patterns found in files, and flag anything that matches. Many antivirus products, including ShieldGuard, use YARA rules to catch variants and modified malware that hash matching alone can't detect.
A typical YARA rule looks like this:
rule ExampleMalware {
strings:
$s1 = "malicious_string_example"
$s2 = { 4D 5A 90 00 03 00 00 00 } // part of an MZ header
condition:
$s1 or $s2
}
The strings section defines the strings or byte sequences you want to detect, and
the condition section describes what combination of matches counts as a detection.
Beyond simple string matching, YARA also supports regular expressions, file size checks, and
combinations of multiple conditions, making it a highly flexible rule language.
How ShieldGuard Uses YARA
ShieldGuard periodically syncs YARA rule collections published by several security vendors and researchers — including Elastic, ESET, Google Cloud Threat Intelligence, and ReversingLabs — and combines them with our own signature database. This gives us coverage of far more malware patterns than an individual developer could realistically write from scratch.
The Catch: Non-Detection Rules Sneak In
Here's the real point of this article. Publicly available YARA rule collections sometimes contain rules that aren't meant for malware detection at all — utility rules meant for analysis or data extraction, such as "extract domain-name-like strings from a file" or "extract IP-address-like strings."
While building ShieldGuard, we actually found a rule like this mixed in:
rule domain {
strings:
$domain_regex = /([\w\.-]+)/ wide ascii
condition:
$domain_regex
}
At a glance it looks like a malware detection rule, but the regular expression
/([\w\.-]+)/ matches "one or more alphanumeric characters, underscores, dots, or
hyphens in a row" — a condition that effectively matches
almost any file containing readable text.
We found similarly-shaped rules named ip (matching anything that looks like an
IPv4/IPv6 address), url (matching anything starting with http(s)://),
and contains_base64 (matching 12+ consecutive Base64-looking characters). We
determined none of these were appropriate for real-world malware verdicts.
How We Fixed It
Our fix identifies these "IOC-extraction utility rules" by filename and explicitly excludes them from what gets loaded into the detection engine. After the fix, harmless text files are correctly scored "Clean," while the industry-standard EICAR malware test string is still correctly scored "Malicious."
The lesson here is that "a YARA rule matched" and "this file is actually malicious" are not the same thing. Understanding where a rule came from and what it was intended for — and designing appropriate confidence weighting and exclusion lists — is essential to reducing false positives.
Summary
- YARA rules are an industry-standard way to detect malware via string and byte-pattern matching
- Public rule collections can contain "utility rules" not meant for detection
- Overly broad conditions cause harmless files to be falsely flagged
- Understanding a rule's origin and excluding ones that don't fit your purpose matters
Try the detection engine that learned this lesson
ShieldGuard is a Windows antivirus built with this fix already applied.
See ShieldGuard