Real-World YARA Rules

Standing on the Shoulders of the Community

You have spent five lessons learning to write YARA rules from scratch. That skill is essential — you will write custom rules for every incident you investigate. But you should not start from zero for every threat. The security community has been writing and sharing YARA rules for over a decade, and the collective knowledge in public rule repositories is enormous.

CyberBlueSOC ships with 523+ YARA rules at /opt/yara-rules/. These rules detect known malware families, common webshell patterns, exploit payloads, packer signatures, and APT indicators. The rules were written by security researchers, incident responders, and threat intelligence teams worldwide.

In this lesson, you will learn to read, evaluate, and customize these rules. A community rule that you understand and have tested is far more valuable than a rule you copied blindly.

Click to enlarge

Reading a Professional YARA Rule

Let us dissect a real-world YARA rule step by step. This rule detects Cobalt Strike Beacon, one of the most common post-exploitation tools encountered in enterprise intrusions:

rule CobaltStrike_Beacon_Config
{
    meta:
        author = "Florian Roth"
        description = "Detects Cobalt Strike Beacon in memory or on disk"
        reference = "https://www.fireeye.com/blog/threat-research/2020/12/..."
        date = "2023-08-15"
        modified = "2025-01-10"
        hash1 = "a1b2c3d4e5f6..."
        tlp = "TLP:WHITE"
        mitre_att_ck = "T1071.001, T1059.001"
        score = 85

    strings:
        $beacon_str1 = "beacon.dll" wide ascii nocase
        $beacon_str2 = "beacon.x64.dll" wide ascii nocase
        $beacon_str3 = "%s.4444" wide ascii
        $sleep_mask = "SleepMask" wide ascii
        $pipe1 = "\\.\pipe\msagent_" ascii
        $pipe2 = "\\.\pipe\MSSE-" ascii

        $config_block = { 00 01 00 01 00 02 ?? ?? 00 02 }
        $xor_key_69 = { 69 68 69 68 69 68 69 68 }

        $cs_uri = /\/[a-z]{3,8}\.(js|html|php)\?[a-z]=[0-9]{4,}/

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x464C457F) and
        filesize < 5MB and
        (
            3 of ($beacon_str*, $sleep_mask, $pipe*) or
            ($config_block and 1 of ($beacon_str*)) or
            ($xor_key_69 and $cs_uri and filesize < 500KB)
        )
}

Reading the Meta Section

What makes this meta section good: Multiple reference points (sample hash, threat report), ATT&CK mapping, TLP marking, active maintenance dates, and a confidence score. You can make an informed deployment decision based on metadata alone.

Reading the Strings Section

This rule uses all three string types with appropriate modifiers:

Text strings with modifiers:

• $beacon_str1 = "beacon.dll" wide ascii nocase — catches the DLL name in ASCII, UTF-16, and any case combination
• $pipe1 = "\\.\pipe\msagent_" ascii — named pipe pattern used by Cobalt Strike for inter-process communication

Hex strings:

• $config_block = { 00 01 00 01 00 02 ?? ?? 00 02 } — the Beacon configuration header with wildcards for variable bytes
• $xor_key_69 = { 69 68 69 68 69 68 69 68 } — a known XOR key pattern used in Beacon encoding

Regex:

• $cs_uri = /\/[a-z]{3,8}\.(js|html|php)\?[a-z]=[0-9]{4,}/ — matches the URL pattern that Cobalt Strike uses for C2 communication (e.g., /alpha.js?q=1234)

Reading the Condition

(uint16(0) == 0x5A4D or uint32(0) == 0x464C457F) and
filesize < 5MB and
(
    3 of ($beacon_str*, $sleep_mask, $pipe*) or
    ($config_block and 1 of ($beacon_str*)) or
    ($xor_key_69 and $cs_uri and filesize < 500KB)
)

Line 1: File must be a PE executable (0x5A4D = MZ) or ELF binary (0x464C457F = \x7FELF). This immediately excludes text files, images, documents, and archives.

Line 2: File must be under 5MB. Cobalt Strike Beacons are compact — this excludes large legitimate applications.

Lines 3-6: Three independent detection paths (connected by or):

1. Path A: 3 of the named Beacon strings or pipe patterns — catches samples with multiple visible Cobalt Strike indicators
2. Path B: The configuration header hex pattern plus at least one Beacon string — catches samples where the config block is present but most strings are obfuscated
3. Path C: The XOR key pattern plus the C2 URI regex plus a tighter size limit — catches encoded Beacons with the characteristic XOR key

Why multiple detection paths? Cobalt Strike is highly configurable. Some operators change the pipe name, some obfuscate strings, some modify the C2 URI pattern. No single path catches all variants. By providing three independent paths, the rule catches different configurations.

Evaluating Rule Quality

Not all community rules are equal. Before deploying a rule to production, evaluate it against these criteria:

Quality Checklist

Red Flags

Watch out for these patterns in community rules:

1. Single generic string with any of them:

   Copy

   strings:
       $a = "eval("
   condition:
       $a
   

   This matches every PHP framework, JavaScript build tool, and Python script with eval.

2. No file format or size check:

   Copy

   condition:
       3 of them
   

   Without uint16 or filesize, the rule scans every file of every type.

3. Extremely complex regex without anchoring:

   Copy

   $r = /.*malware.*/
   

   The .* on both sides makes this match any file containing "malware" anywhere — including security documentation, news articles, and this very lesson.

4. No author or reference: If you cannot trace who wrote a rule or what analysis it is based on, you cannot assess its quality or report false positives upstream.

Major YARA Rule Repositories

Click to enlarge

YARA-Rules (GitHub)

Repository: github.com/Yara-Rules/rules

The largest open-source YARA rule collection. 523+ rules organized by category:

• malware/ — commodity malware families (RATs, stealers, ransomware)
• webshell/ — PHP, ASP, JSP web shells
• cve_rules/ — exploit and vulnerability indicators
• packers/ — packer and protector detection (UPX, Themida, VMProtect)
• email/ — malicious email attachment patterns
• crypto/ — cryptocurrency miner indicators
• apt/ — advanced persistent threat rules

Strengths: Broad coverage, well-organized categories, actively maintained. Limitations: Variable quality — some rules are excellent, others are outdated or overly generic. Always review before deploying.

This is the repository pre-installed on CyberBlueSOC at /opt/yara-rules/.

Florian Roth / Neo23x0 Signature Base

Repository: github.com/Neo23x0/signature-base

High-quality rules from one of the most respected YARA authors. Specializes in:

• APT detection rules (APT28, APT29, Lazarus Group, etc.)
• Exploit indicators (CVE-specific detections)
• Hack tool detection (Mimikatz, Cobalt Strike, Metasploit)
• Webshell detection (comprehensive PHP/ASP/JSP coverage)

Strengths: Consistently high quality, rich metadata (ATT&CK mapping, TLP, references), actively maintained with regular updates. Best for: Enterprise SOC environments, APT hunting, professional IR work.

Awesome YARA

Repository: github.com/InQuest/awesome-yara

Not a rule repository but a curated collection of YARA resources:

• Links to rule repositories (aggregates all known public sources)
• YARA tools (editors, testing frameworks, rule generators)
• Learning resources (tutorials, blog posts, conference talks)
• Integration guides (YARA with other security tools)

Best for: Discovering new rule sources and tools.

VirusTotal (Livehunt / Retrohunt)

URL: virustotal.com

VirusTotal lets you run YARA rules against its massive sample database:

• Livehunt — your rules run against every file uploaded to VirusTotal in real time. When a new sample matches your rule, you get notified.
• Retrohunt — scan VirusTotal's historical database (billions of samples) with your rules. Find all past samples that match.

Best for: Testing rules against massive, diverse sample sets. Validating detection accuracy before deploying to production.

Note: Livehunt and Retrohunt require a VirusTotal Intelligence subscription (paid).

Customizing Community Rules

Community rules are starting points, not final products. You should customize them for your environment:

Adding Exclusions

strings:
    // Original strings from community rule
    $eval = "eval(" nocase
    $system = "system(" nocase
    // Add exclusion strings for your environment
    $safe_wp = "WordPress" nocase
    $safe_joomla = "Joomla" nocase
    $safe_internal = "YourCompanyFramework" nocase

condition:
    // Original condition
    filesize < 50KB and 2 of ($eval, $system) and
    // Add exclusions
    not 1 of ($safe_*)

Adjusting Thresholds

A community rule might use 2 of them but you find it too noisy in your environment. Increase to 3 of them or add a filesize constraint.

Updating Metadata

Always add your organization's context when you deploy a community rule:

meta:
    // Original author preserved
    original_author = "Florian Roth"
    // Your team's additions
    deployed_by = "CyberBlue SOC Team"
    deployed_date = "2026-02-17"
    tested_against = "100 clean samples, 5 known malicious"
    false_positive_notes = "Matches WordPress plugin X — excluded"
    environment = "Production web servers"

Maintaining Your Rule Library

A YARA rule library is a living asset. It requires ongoing maintenance:

Version Control

Store your rules in Git. Every change — new rule, modified condition, added exclusion — should be a commit with a clear message:

git log --oneline rules/
a1b2c3d  Add exclusion for WordPress 6.x plugin
d4e5f6a  Tighten Cobalt Strike rule - reduce FP on MS Office
7890abc  New rule: LockBit 3.0 indicators from INC-2026-0147
bcd1234  Import YARA-Rules community update (Q1 2026)

Scheduled Reviews

Set a quarterly cadence to review your rule library:

• Retire rules for threats that are no longer active (e.g., a malware family that was taken down)
• Update rules for threats that have evolved (new variants, changed indicators)
• Import new community rules for emerging threats
• Audit false positive logs — rules that generate FPs regularly need tightening

Rule Naming Convention

Use a consistent naming scheme for organizational rules:

rule ORG_Category_ThreatName_Variant
{
    // Examples:
    // CB_Malware_LockBit3_Ransom
    // CB_Webshell_PHP_EvalDecode
    // CB_APT_APT29_CozyBear_Stage2
    // CB_Tool_CobaltStrike_Beacon_x64
}

Prefix with your organization code (CB_ for CyberBlue), followed by category, threat name, and variant. This makes rules sortable and searchable.

What's Next

You have completed Module 7: YARA — Malware Detection & Hunting. You can now write YARA rules from scratch, use all three string types with advanced modifiers, build precise conditions, scan at scale on individual systems and across your fleet, and leverage the security community's collective knowledge.

In Module 8, you will learn Sigma — the universal detection rule format for SIEM systems. While YARA finds malware in files and memory, Sigma finds attacker behavior in log events. You will write Sigma rules that translate into Wazuh queries, Splunk searches, and Elastic rules, making your detections portable across any SIEM platform.