Yara Rule Development

YARA Rule Development for Malware Hunting

When to Use

• During an active Incident Response (IR) engagement when a new, undocumented piece of malware is discovered. You must rapidly create a YARA rule to sweep the entire organization to find any other compromised machines.
• To monitor external databases (e.g., VirusTotal LiveHunt) for newly uploaded files matching an advanced threat actor's specific toolset to gain proactive threat intelligence.
• When categorizing malware families within a sandbox analysis pipeline by establishing behavioral signatures (e.g., classifying a file as "Cobalt Strike" vs "Meterpreter").

Prerequisites

• Authorized scope and rules of engagement for the target environment
• Appropriate tools installed on the attack/analysis platform
• Understanding of the target technology stack and architecture
• Documentation template ready for findings and evidence capture

Workflow

Phase 1: The Structure of a YARA Rule

# Concept: A YARA rule is essentially a massive `If/Then` statement defining conditions 
# under which a file belongs to a specific malware family.

rule APT29_CozyBear_Implant
{
    meta:
        description = "Detects the custom DLL implant utilized in recent SolarWinds campaigns"
        author = "IR Team Analyst"
        date = "2024-03-24"
        tlp = "RED"                   // Traffic Light Protocol for intelligence sharing

    strings:
        // Define the evidence we are looking for (Hexadecimal bytes, Strings, or Regex)
        $string1 = "payload_exfiltrator_v2" ascii wide nocase
        $string2 = "C:\\Users\\Public\\Downloads\\update.dat" 
        $hex_pattern = { E8 ?? ?? ?? ?? 85 C0 74 0A 48 8B 05 ?? ?? ?? ?? } // Matches specific X64 assembly instructions

    condition:
        // Define the logic mapping the evidence
        uint16(0) == 0x5A4D and // Magic Bytes: The file MUST be a Windows Executable (MZ)
        filesize < 2MB and      // Highly optimized implant, usually very small
        (all of ($string*) or $hex_pattern) // Must contain all strings OR the exact assembly sequence
}

Phase 2: Analyzing the Malware (Extracting Signatures)

# Concept: To write an effective rule, you must find patterns truly unique to the malware, 
# ensuring you do not accidentally flag legitimate software (False Positives).

# 1. Static Extration of Strings
strings -e l malicious_implant.exe > strings_wide.txt
strings -e S malicious_implant.exe > strings_ascii.txt

# Good candidate strings for YARA:
# - Custom Mutex names (e.g., `Global\Ransom_Lock_XYZ`)
# - C2 Domain addresses (e.g., `http://evil-infra-c2.com/telemetry.php`)
# - Typos in debugging language (e.g., `Connectin failed.` or `Memmory allocation error`)
# - Specific PDB (Program Database) compilation paths indicating the attacker's folder structure
#   `C:\Users\Ivan\Desktop\Trojan_Source\Release\implant_v2.pdb`

# Bad candidate strings (Will cause massive False Positives):
# - `kernel32.dll`
# - `GetProcAddress`
# - `Mozilla/5.0 (Windows NT 10.0; Win64; x64)`

Phase 3: Utilizing the PE Module (Advanced Hunting)

# Concept: Advanced malware obliterates its strings using obfuscation or packing (e.g., UPX).
# If there are no strings, we must hunt based on the STRUCTURE of the Portable Executable (PE) file using Yara Modules.

import "pe"

rule Obfuscated_Ransomware
{
    condition:
        // Find files exporting specific, dangerous API combinations indicating process injection despite having no strings
        pe.imports("kernel32.dll", "VirtualAllocEx") and
        pe.imports("kernel32.dll", "WriteProcessMemory") and
        pe.imports("kernel32.dll", "CreateRemoteThread") and
        
        // Find files claiming to be legitimate but clearly possessing anomalous characteristics
        pe.number_of_sections == 8 and
        pe.sections[0].name == ".text" and
        pe.sections[0].entropy > 7.5 // A wildly high mathematical entropy indicating the code is deeply encrypted or packed
}

Phase 4: Deployment and Global Hunting

# Concept: Once the rule is written, it is deployed natively against endpoints, servers, or cloud intelligence platforms.

# 1. Local Network Sweeping via YARA CLI:
# Iterate through the entire C: drive silently reporting any file that matches the logic
yara32.exe -r -s my_custom_rules.yar C:\

# 2. VirusTotal Retrohunt / LiveHunt Deployment:
# Upload the `.yar` file to VirusTotal Enterprise. 
# Retrohunt will scan petabytes of historical malware submissions in minutes to see if this actor has operated previously.
# LiveHunt will monitor every file uploaded globally to VirusTotal in real-time, emailing you if the attacker tests a new variant.

Decision Point 🔀

flowchart TD
    A[Discover New Malware Artifact] --> B[Extract basic properties via 'strings']
    B --> C{Are unique text strings visible?}
    C -->|Yes| D[Identify Mutexes, PDB Paths, or Custom Error Messages]
    C -->|No / Packed| E[Utilize 'pe' module analyzing API Imports and Entropy]
    D --> F[Draft YARA Rule combining strings and constraints (Filesize, MZ Header)]
    E --> F
    F --> G[Test Rule locally against known Good/Clean software repository]
    G --> H{False Positives triggered?}
    H -->|Yes| I[Refine constraints to be more specific (Increase required matches, modify regex)]
    H -->|No| J[Deploy Rule out to EDR sensors enterprise-wide to isolate compromised hosts]

🔵 Blue Team Detection & Defense

• Automated IOC Extraction Models: YARA rules form the absolute bedrock of defensive automation architecture. Security Operations Centers (SOCs) should integrate YARA signature scanning natively into their Email Gateways, automated internal Sandboxes, and Network Intrusion Detection Systems (Suricata).
• Rule Performance Optimization: Ensure all developed rules are highly optimized utilizing constraints. A rule lacking the uint16(0) == 0x5A4D (MZ Header) constraint will force the EDR agent to calculate regex operations across massive ISO images and MP4 videos on the hard drive, massively spiking CPU utilization enterprise-wide and angering employees. Ensure YARA fails on non-executable files.
• Sigma Rule Parity: While YARA excels identically identifying malicious files, it is essentially blind to anomalous behavior. Blue Teams must couple YARA intelligence with Sigma rules (the YARA equivalent for parsing SIEM Log Events like Splunk or Elastic) to detect fileless malware executing exclusively within the RAM of powershell.exe.

Key Concepts

Output Format

Threat Intelligence Brief: YARA Signature Development for X-Wiper
=================================================================
Target Tooling: X-Wiper Data Destruction Implant (Version 3)
Objective: Enterprise-wide Identification and Containment

Description:
During post-incident forensic analysis, a novel data wiping executable (`sys_updater.exe`) was recovered from the compromised domain controller. The malware is heavily obfuscated, however, static analysis revealed a highly unique compile-time PDB path and a proprietary XOR encryption key utilized during its initial boot sequence. 

An optimized YARA rule was authored to hunt for this specific variant across the corporate infrastructure. 

```yara
rule X_Wiper_V3_Destructor
{
    meta:
        description = "Identifies the core destructive module of X-Wiper utilized post-lateral movement."
        tlp = "AMBER"
    
    strings:
        // Recovered Compile Path
        $pdb_path = "D:\\Development\\Destruction_Framework\\Release\\x_wiper_core.pdb" ascii nocase
        // Hardcoded XOR decryption key mapped in memory
        $xor_key = { DE AD BE EF 00 00 00 00 BB 11 22 33 }
        // Base64 encoded primary C2 beacon
        $c2_domain = "aHR0cHM6Ly93d3cuZXZpbC1pbmZyYS5jb20=" 

    condition:
        uint16(0) == 0x5A4D and filesize < 5MB and
        ($pdb_path or $xor_key or $c2_domain) 
}

Result: Upon deploying the rule via the corporate EDR's sweeping module, 14 previously unidentified and dormant instances of the wiper were located on secondary backup servers. The artifacts were successfully quarantined proactively, mitigating a massive secondary catastrophic data loss event.

## 🛡️ Remediation & Mitigation Strategy
- **Input Validation:** Sanitize and strictly type-check all inputs.
- **Least Privilege:** Constrain component execution bounds.


## 📚 Shared Resources
> For cross-cutting methodology applicable to all vulnerability classes, see:
> - [`_shared/references/elite-chaining-strategy.md`](../_shared/references/elite-chaining-strategy.md) — Exploit chaining methodology and high-payout chain patterns
> - [`_shared/references/elite-report-writing.md`](../_shared/references/elite-report-writing.md) — HackerOne-optimized report writing, CWE quick reference
> - [`_shared/references/real-world-bounties.md`](../_shared/references/real-world-bounties.md) — Verified disclosed bounties by vulnerability class

## References
- YARA Documentation: [Writing YARA rules](https://yara.readthedocs.io/en/stable/writingrules.html)
- Kaspersky Lab: [YARA - Beginner's Guide](https://securelist.com/yara-rules/86364/)
- GitHub (YARA Rules): [YARA-Rules standard repository](https://github.com/Yara-Rules/rules)