SIGMA and YARA Detection Rules

SIGMA and YARA are both rule-based detection languages, but they serve different purposes and operate at different layers of the detection stack. YARA (pattern-matching tool) is designed for file-based detection: it scans binary or text files for patterns such as byte sequences, strings, or regular expressions. SIGMA, on the other hand, is a generic signature format for log events. It describes suspicious behavior in a SIEM-agnostic way, allowing analysts to write detection rules once and convert them to multiple SIEM query languages (Splunk, Elasticsearch, QRadar, etc.).

YARA rules are written in a C-like syntax and consist of three main sections: meta, strings, and condition. The meta section contains metadata like author, description, and date. The strings section defines patterns to search for—for example, $a = "malware" or $b = { 6A 40 68 00 30 00 00 } (hex). The condition section specifies the logic for matching, such as $a at 0 or 2 of ($a,$b,$c). When YARA scans a file, it reads the file content into memory, then applies the rules sequentially. For each rule, it searches for the defined strings using the Aho-Corasick algorithm (for multiple patterns) and evaluates the condition. If the condition is true, the rule matches. YARA uses fast pattern matching and can handle large files efficiently.

SIGMA rules are written in YAML format and describe log events using a generic field-value structure. Each rule has a title, description, logsource (e.g., product: windows, category: process_creation), and detection section. The detection section defines selection criteria using field names like EventID, Image, CommandLine and values. For example:

detection:
  selection:
    EventID: 4688
    Image|endswith: '\\cmd.exe'
  condition: selection

SIGMA rules are converted to SIEM queries using tools like sigmac (SIGMA converter). The converter maps the generic field names to the specific field names used by the target SIEM (e.g., EventID -> event_id in Elasticsearch). The resulting query can be executed against log data.

YARA: To create a rule, save it as a .yar file. To scan a file:

yara myrule.yar suspicious.exe

To scan a directory recursively:

yara -r myrule.yar /path/to/dir

To see which rule matched: yara -m myrule.yar file. For performance, compile rules: yara -c myrule.yar.

SIGMA: Rules are saved as .yml files. To convert a SIGMA rule to a Splunk query:

sigmac -t splunk -c config.yml myrule.yml

To convert to Elasticsearch:

sigmac -t es-rule -c config.yml myrule.yml

Verification is done by running the converted query against the SIEM and checking for matches.

YARA integrates with security tools like VirusTotal (for crowdsourced scanning), ClamAV (via libclamav), and many EDR solutions (e.g., CrowdStrike, SentinelOne) that support YARA scanning on endpoints. SIGMA rules are commonly used with SIEM platforms (Splunk, Elastic Security, Azure Sentinel) and can be shared via repositories like the SIGMA GitHub repository. Both are often used in conjunction: YARA for file-based detection (e.g., scanning malware samples), SIGMA for behavioral detection (e.g., detecting process injection via log events).

Scenario 1: Detecting Ransomware in a SOC A SOC analyst needs to detect ransomware that encrypts files and drops a ransom note. They write a YARA rule that looks for the ransom note filename (e.g., DECRYPT.txt) and common encryption patterns (e.g., $a = { 6A 40 68 00 30 00 00 } for AES key scheduling). The rule is deployed to all endpoints via the EDR. When a user downloads a malicious executable, the endpoint scanner flags it within seconds. The SOC receives an alert and can quarantine the file before execution. Common issue: false positives from legitimate encryption software (e.g., VeraCrypt). Mitigation: add exclusion for known good software hashes.

Scenario 2: Detecting Lateral Movement with SIGMA A blue team wants to detect pass-the-hash attacks. They write a SIGMA rule that monitors Windows Security Event ID 4624 (logon) with LogonType 3 (network) and a specific authentication package (NTLM). The rule is converted to a Splunk query and deployed. When an attacker uses Mimikatz to perform a pass-the-hash, the SIEM alerts. However, the rule may generate false positives from legitimate network logins. To reduce noise, they add a condition to exclude known admin workstations. Performance: the query must be efficient to avoid high CPU on the SIEM; use indexed fields.

Scenario 3: Threat Hunting with YARA and SIGMA Combined During an incident response, analysts receive a suspicious PowerShell script. They run a YARA rule on the script to identify known obfuscation patterns (e.g., base64 strings, encoding functions). The rule matches, confirming malware. Next, they write a SIGMA rule to detect similar PowerShell execution across the environment: EventID: 4688 and Image: *\\powershell.exe and CommandLine: *-EncodedCommand*. This rule is converted and deployed to the SIEM, revealing three other compromised hosts. The combination of file-level (YARA) and behavioral (SIGMA) detection provides comprehensive coverage.