YARA Fundamentals

What Is YARA and Why Does It Matter?

Every SOC analyst eventually encounters a question no SIEM alert can answer on its own: "Is this file malicious?" A Wazuh alert tells you that a suspicious file appeared on an endpoint. Suricata tells you that a binary was downloaded over HTTP. MISP tells you that a hash matches a known malware family. But none of these tools can look inside an arbitrary file and tell you what patterns it contains, what strings are embedded in it, or whether its structure matches a known threat signature.

That is what YARA does.

YARA is a pattern-matching tool designed specifically for malware detection and classification. Created by Victor Alvarez at VirusTotal, it lets you write rules that describe textual, hexadecimal, and regex patterns found in files. When you run YARA against a file or directory, it checks every file against your rules and reports matches. Think of YARA rules as custom signatures — you define exactly what you are looking for, and YARA finds it.

Here is what makes YARA indispensable in SOC operations:

YARA is used by antivirus companies, CERT teams, threat intelligence platforms (including MISP and VirusTotal), and incident responders worldwide. The 523+ YARA rules pre-installed on CyberBlueSOC at /opt/yara-rules/ were written by the security community to detect everything from commodity ransomware to nation-state APT tools.

Anatomy of a YARA Rule

Every YARA rule follows the same structure. There are exactly three sections you need to understand: meta, strings, and condition. Once you master this structure, you can read and write any YARA rule.

Click to enlarge

Here is a complete YARA rule with all three sections:

rule Detect_Malicious_Script
{
    meta:
        author = "CyberBlue Academy"
        description = "Detects a PowerShell downloader script"
        date = "2026-02-17"
        reference = "https://cyberblue.academy/module-7"
        severity = "high"

    strings:
        $download = "DownloadString" nocase
        $iex = "Invoke-Expression" nocase
        $webclient = "Net.WebClient" nocase
        $hidden = "-WindowStyle Hidden" nocase
        $encoded = "-enc" nocase

    condition:
        filesize < 100KB and
        3 of them
}

Let us break down each section.

Section 1: meta

The meta section contains descriptive information about the rule. It has zero effect on matching — YARA ignores it during scanning. But it is critical for rule management:

Good metadata makes rules maintainable. When you have 500+ rules and one starts producing false positives, the author, date, and reference fields help you trace why the rule was created and whether it is still relevant.

Section 2: strings

The strings section defines the patterns YARA looks for inside files. Every string variable starts with a $ sign. You can define three types of strings:

Text strings — human-readable strings found in the file:

$download = "DownloadString"
$url = "http://malware.example.com/payload"
$cmd = "cmd.exe /c"

Hex strings — raw byte sequences in curly braces:

$mz_header = { 4D 5A 90 00 }
$shellcode = { 68 74 74 70 3A 2F 2F }
$call_ret = { E8 ?? ?? ?? ?? C3 }

The ?? in hex strings are wildcards — they match any byte value. This is essential for detecting shellcode where certain bytes (like offsets) change between samples.

Regular expressions — pattern matching with regex:

$ip_pattern = /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
$base64_blob = /[A-Za-z0-9+\/]{50,}={0,2}/
$c2_url = /https?:\/\/[a-z0-9\-\.]+\.(ru|cn|tk)\/[a-z]{5,}/

You can combine all three types in a single rule. The more diverse your string types, the more precise your detection.

Section 3: condition

The condition section defines the logic that determines whether a file matches the rule. This is where the real power lies:

condition:
    filesize < 100KB and 3 of them

This means: the file must be smaller than 100KB and at least 3 of the defined strings must be present. Common condition patterns:

The filesize check is one of the most important tools for reducing false positives. If you are looking for a malicious script, limiting to filesize < 100KB eliminates large binaries, databases, and log files from consideration.

The YARA Rule Lifecycle

Writing a YARA rule is not a one-shot activity. Professional rule development follows a lifecycle that ensures rules are accurate, tested, and maintained over time.

Click to enlarge

Stage 1 — Discover: You encounter a new threat. This could be a malware sample from an incident response engagement, a suspicious file flagged by an analyst, or indicators from a threat intelligence report. The trigger is always the same: you need a way to detect this threat across your environment.

Stage 2 — Analyze: Before writing a rule, you need to understand the target. Use tools like strings (extract readable text), hexdump (view raw bytes), CyberChef (decode and transform), and sandbox reports (understand behavior). Your goal is to find unique, stable patterns — strings or byte sequences that appear in the malicious sample but not in legitimate software.

Stage 3 — Write: Craft your YARA rule with multiple string types, a file format check, a size constraint, and a flexible condition. Use the meta section to document what you are detecting and why.

Stage 4 — Test: Run your rule against two corpora: a set of known-bad samples (to verify detection) and a set of known-good files (to verify zero false positives). The goal is 100% true positive rate and 0% false positive rate on your test sets. In reality, you may need to iterate between writing and testing multiple times.

Stage 5 — Deploy: Push your tested rule to production scanning infrastructure. This could be Velociraptor (endpoint hunting), your CI/CD pipeline (scanning code deployments), an email gateway (scanning attachments), or a file upload scanner (scanning user uploads).

Stage 6 — Maintain: Rules are not permanent. Monitor for false positives in production. When new variants of the malware appear, update your rule to catch them. When the threat is no longer active, consider retiring the rule to keep your rule set lean. Schedule periodic reviews (quarterly is common in mature SOCs).

Running YARA from the Command Line

YARA is a command-line tool. The basic syntax is:

yara [options] rule_file target

Scan a single file:

yara my_rule.yar suspect.exe

Scan a directory recursively:

yara -r my_rule.yar /uploads/

Show matching strings (critical for debugging):

yara -s my_rule.yar suspect.exe

The -s flag shows which strings matched and at what offset in the file. This is invaluable when debugging why a rule matched (or did not match).

Key flags you will use constantly:

Example output with -s flag:

$ yara -s detect_downloader.yar /samples/
Detect_Malicious_Script /samples/stage1.ps1
0x42:$download: DownloadString
0x8a:$webclient: Net.WebClient
0xc1:$hidden: -WindowStyle Hidden

This tells you the rule Detect_Malicious_Script matched the file /samples/stage1.ps1. Three strings matched: $download was found at byte offset 0x42, $webclient at 0x8a, and $hidden at 0xc1.

Compiling rules for performance:

When you have many rules, you can compile them into a binary format for faster loading:

yarac all_rules.yar compiled_rules.yarc
yara compiled_rules.yarc /target/directory/

Compiled rules load significantly faster, which matters when you are scanning large directories with hundreds of rules.

Your First YARA Rule: Step by Step

Let us write a complete YARA rule from scratch. Imagine you are investigating an incident where the attacker dropped a PHP web shell on a compromised web server. You found the web shell and now want to scan all web servers for similar files.

Step 1 — Analyze the sample. You examine the web shell and find these distinctive patterns:

<?php eval(base64_decode($_POST['cmd'])); ?>

The key indicators are: the eval function, base64_decode, and $_POST (reading user input from an HTTP POST request).

Step 2 — Write the rule:

rule Webshell_PHP_Eval
{
    meta:
        author = "CyberBlue Academy"
        description = "Detects PHP web shells using eval with base64_decode"
        date = "2026-02-17"
        severity = "critical"
        mitre_att_ck = "T1505.003"

    strings:
        $eval = "eval(" nocase
        $b64 = "base64_decode" nocase
        $post = "$_POST" nocase
        $get = "$_GET" nocase
        $request = "$_REQUEST" nocase
        $system = "system(" nocase
        $exec = "exec(" nocase
        $passthru = "passthru(" nocase
        $php_tag = "<?php"

    condition:
        filesize < 50KB and
        $php_tag and
        $eval and
        ($b64 or $system or $exec or $passthru) and
        ($post or $get or $request)
}

Step 3 — Test the rule:

# Test against the known web shell (should match)
yara -s webshell_rule.yar /evidence/webshell.php

# Test against a clean PHP application (should NOT match)
yara -r webshell_rule.yar /var/www/clean_app/

# Count matches across the entire web directory
yara -rc webshell_rule.yar /var/www/

Step 4 — Analyze results. If the rule matches the known web shell and does not match any clean PHP files, it is ready for deployment. If it produces false positives, tighten the condition (require more strings, add additional unique patterns from the web shell sample).

This rule demonstrates several best practices:

• Multiple string types covering different web shell techniques
• File size constraint (< 50KB) — web shells are small
• PHP tag check — only scan PHP files
• Flexible condition — requires eval plus at least one encoding/execution function plus at least one user input source
• ATT&CK mapping — T1505.003 is "Server Software Component: Web Shell"

What's Next

You now understand the anatomy of a YARA rule and how to run scans from the command line. In Lesson 7.2, you will dive deep into the strings section — learning modifiers like nocase, wide, fullword, xor, and base64 that make your patterns more flexible and powerful. You will also master hex string wildcards, jumps, and alternation for matching binary signatures that vary between samples.