malware-triage-yara

| | YARA Rule | Pattern matching rule defining strings, byte sequences, and conditions that identify a specific file or malware family | | Condition | Boolean expression combining string matches, file properties, and module functions to determine if a rule matches | | Hex String | Byte pattern with optional wildcards (??) and jumps ([N-M]) for matching machine code or binary data | | PE Module | YARA module providing access to PE file properties (imports, sections, timestamps, resources) for structural matching | | Imphash | MD5 hash of a PE file's import table; samples from the same family often share import hashes | | Rich Header | Undocumented PE structure containing compiler/linker metadata; consistent within malware build environments | | YARA-C | Compiled YARA rule format enabling faster scanning by pre-compiling rules for repeated use |

Tools & Systems

• YARA: Pattern matching engine for identifying and classifying malware based on text, hex, and structural patterns
• yara-python: Python bindings for YARA enabling scripted scanning, rule compilation, and integration with analysis pipelines
• yarGen: Automatic YARA rule generator that creates rules from malware samples by identifying unique strings and opcodes
• YARA-Rules (GitHub): Community-maintained repository of YARA rules covering malware families, exploits, and suspicious indicators
• Malpedia YARA: Curated YARA rules from the Malpedia malware encyclopedia with high-quality family-specific rules

Common Scenarios

Scenario: Creating Detection Rules for a New Malware Family

Context: Reverse engineering of a new malware sample has identified unique strings, byte patterns, and PE characteristics. YARA rules are needed for enterprise-wide hunting and ongoing detection.

Approach:

1. Extract unique strings from the unpacked binary (C2 URLs, mutex names, registry paths)
2. Identify unique byte sequences from the encryption routine or C2 protocol (from Ghidra analysis)
3. Record PE characteristics (imphash, Rich header hash, section names, compilation timestamp range)
4. Write a YARA rule combining string, byte pattern, and PE module conditions
5. Test against the known malware samples to confirm true positive detection
6. Test against a clean file corpus (Windows system files, common applications) to verify zero false positives
7. Deploy to enterprise scanning infrastructure and threat intelligence platform

Pitfalls:

• Writing rules too specific to a single sample (will not detect variants with minor changes)
• Writing rules too generic (matching legitimate software, causing false positives)
• Using strings that appear in common libraries or frameworks (e.g., OpenSSL strings)
• Not testing on a sufficiently large clean corpus before deployment

Output Format

YARA TRIAGE RESULTS
=====================
Scan Date:        2025-09-15
Rule Sets:        apt_rules (847 rules), ransomware_rules (312 rules),
                  trojan_rules (1,204 rules), custom_rules (45 rules)
Samples Scanned:  2,500
Processing Time:  47 seconds

CLASSIFICATION SUMMARY
APT:              12 samples (0.5%)
Ransomware:       187 samples (7.5%)
Trojan:           423 samples (16.9%)
Unknown:          1,878 samples (75.1%)

TOP MATCHING RULES
Rule                         Matches  Family
MalwareX_C2_Beacon           45       MalwareX
LockBit3_Ransom_Note         38       LockBit 3.0
Emotet_Epoch5_Loader         32       Emotet
CobaltStrike_Beacon_Config   28       Cobalt Strike
QakBot_DLL_Loader            25       QakBot

SAMPLE DETAIL
File:    suspect.exe
SHA-256: e3b0c44298fc1c149afbf4c8996fb924...
Matches:
  [1] MalwareX_Strings (custom)
      - $url1 at 0x4A20: "/gate.php?id="
      - $mutex at 0x5100: "Global\\CryptLocker_2025"
  [2] MalwareX_Decryptor (custom)
      - $xor_loop at 0x401200: { 8A 04 0E 32 04 0F ... }
  [3] MalwareX_PE_Characteristics (custom)
      - PE import combination matched
Classification: MALWAREX (HIGH CONFIDENCE)