YARA Rules: The Complete Guide to Custom Malware Signatures

A YARA rule is essentially a boolean logic statement wrapped in a specific syntax. While the logic can become highly complex, the fundamental structure of every rule consists of three core sections: meta, strings, and condition.

rule Example_Malware_Rule
{
    meta:
        author = "Rokibul Islam"
        description = "Detects generic credential dumping behavior"
        date = "2026-05-25"
        threat_level = 5

    strings:
        $string1 = "lsass.exe" ascii wide nocase
        $string2 = "sekurlsa::logonpasswords" ascii wide
        $hex_pattern = { E8 ?? ?? ?? ?? 85 C0 74 ? 8B 4D 08 } 

    condition:
        ($string1 and $string2) or $hex_pattern
}

1. The meta Section

The meta section is technically optional, but in a professional environment, it is absolutely critical. It stores key-value pairs that provide metadata about the rule itself. This section has no impact on the rule's execution or logic; it is purely for documentation and organization.

When a YARA rule triggers an alert in a SIEM (Security Information and Event Management) system, the data in the meta section is often parsed to provide context to the analyst. Standard fields include author, description, reference (links to threat intel reports), date, and hash (hashes of known samples the rule was tested against).

2. The strings Section

The strings section is where you define the specific patterns (the "signatures") that YARA will search for within a file or memory space. Variables defining strings always begin with a dollar sign ($). YARA supports three primary types of strings:

• Text Strings: These are standard ASCII characters. You can use modifiers to broaden the search. For example, $a = "malicious_server.com" nocase will match regardless of capitalization. The wide modifier instructs YARA to search for the string encoded in 16-bit Unicode (commonly used by Windows), while ascii searches for standard 8-bit characters.
• Hexadecimal Strings: When hunting for specific machine code instructions, magic bytes, or obfuscated data, you must define hex strings enclosed in curly braces {}. YARA allows for incredible flexibility here. You can use wildcards (??) for unknown bytes, or jumps ([4-6]) for variable distances between bytes. Example: $hex = { 4D 5A 90 00 [10-20] E8 ?? ?? ?? ?? } searches for the MZ header, jumps 10 to 20 bytes, and looks for an Assembly CALL instruction.
• Regular Expressions: For highly complex textual patterns, YARA supports Perl-Compatible Regular Expressions (PCRE) enclosed in forward slashes /. While powerful, regex should be used sparingly as it heavily impacts scanning performance.

3. The condition Section

The condition section is the brain of the YARA rule. It uses boolean logic (and, or, not) to dictate exactly how the defined strings must relate to each other for the rule to trigger a positive match.

Conditions can range from simple to highly complex:

• condition: any of them (Matches if any string defined in the strings section is found).
• condition: all of them (Matches only if every string is found).
• condition: 2 of ($string1, $string2, $string3) (Matches if at least two of the specified strings are found).
• condition: $a at 0 (Matches if string $a is located at the absolute very beginning of the file—useful for identifying file headers).
• condition: $a and filesize < 500KB (Matches if string $a is found AND the file is smaller than 500 kilobytes).

The true power of modern YARA lies in its extensible modules, which allow the engine to parse complex file structures and extract metadata before applying the conditions. The most critical module for Windows malware analysis is the PE (Portable Executable) module.

By importing the pe module at the top of your rule, you can write conditions based on the structural characteristics of a Windows .exe or .dll file, rather than just searching for raw strings.

import "pe"

rule Suspicious_Packed_Executable
{
    meta:
        description = "Detects potentially packed Windows executables with no imports and a suspicious section name."
    
    condition:
        // Ensure it is a valid PE file
        uint16(0) == 0x5A4D and 
        // Check if the number of imported DLLs is zero (highly unusual for normal software)
        pe.number_of_imports == 0 and 
        // Iterate through sections and look for common packer names
        for any i in (0..pe.number_of_sections - 1): (
            pe.sections[i].name == ".upx0" or 
            pe.sections[i].name == ".aspack"
        )
}

Other powerful modules include the elf module for analyzing Linux binaries, the hash module for dynamically calculating MD5/SHA256 hashes of file segments, and the math module for calculating entropy (useful for detecting encrypted or heavily obfuscated payloads).

Scenario 1: Hunting a Novel Ransomware Variant A threat intelligence feed alerts your SOC to a new ransomware family that appends the extension .crypt0 to encrypted files and uses a specific Bitcoin wallet address for ransom demands. Standard antivirus signatures are not yet updated. An analyst quickly crafts a YARA rule:

rule Hunt_New_Ransomware
{
    strings:
        $ext = ".crypt0" ascii wide
        $btc_wallet = "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" ascii
        $note = "Your network has been compromised. Pay the ransom." nocase ascii wide
    condition:
        2 of them and filesize < 5MB
}

The analyst deploys this rule via their EDR solution across the entire enterprise, instantly identifying three compromised servers where the ransomware binary is lying dormant, waiting to execute.

Scenario 2: Identifying Cobalt Strike Beacons Cobalt Strike is a legitimate penetration testing framework heavily abused by APT groups. Attackers use it to generate "Beacons" (memory-resident payloads). Because Beacons are highly malleable, static file hashes are useless. A Malware Analyst extracts a Beacon from a memory dump and identifies a specific, unchangeable sequence of hexadecimal bytes associated with the Beacon's configuration parser. They create a YARA rule utilizing hex strings and deploy it to a memory scanner. This allows the SOC to scan the live RAM of all corporate workstations, uncovering hidden Beacons that have completely bypassed disk-based antivirus.

Writing a YARA rule is easy; writing an effective YARA rule requires discipline. Poorly written rules cause two major problems: false positives (alerting on legitimate software) and performance degradation (slowing down the systems being scanned).

1. Prioritize Hex and Unique Strings: Avoid writing rules based on generic strings like kernel32.dll or HTTP/1.1. These exist in millions of legitimate files. Focus on unique typos in the malware author's code, specific cryptographic keys, or unique sequences of assembly instructions (hex strings).
2. Optimize for Performance (The Fast-Path): YARA evaluates conditions sequentially. Place the fastest, most restrictive checks at the beginning of your condition. Checking the file size (filesize < 2MB) or the magic header (uint16(0) == 0x5A4D) takes milliseconds. If these fail, YARA stops evaluating. If you place a complex regular expression at the beginning of your condition, YARA will waste significant CPU cycles executing it on every file, even if the file is completely irrelevant.
3. Test Against Goodware: Before deploying a YARA rule to a production environment, it must be thoroughly tested against a massive corpus of legitimate software (goodware). If your rule designed to catch spyware also triggers on notepad.exe and chrome.exe, the resulting false positive storm will overwhelm the SOC and lead to the rule being disabled.
4. Utilize the private Keyword: If you define a string or a rule that is only meant to be used as a building block for other rules, label it as private. Private rules will not generate an alert output when matched, keeping your SIEM logs clean.