Sigma and YARA
Write a detection once, run it on any SIEM or any file on disk.
What you will learn
- -Write a Sigma rule and convert it to your SIEM's query language
- -Write a YARA rule that matches malware by strings and structure
- -Choose Sigma for logs and YARA for files and memory
You wrote a detection for Cobalt Strike activity in Splunk SPL, and next quarter the company migrates to Sentinel. Rewrite everything by hand, or write it once in a portable format and let a converter emit the dialect you need. and are the two portable formats that matter, and they cover the two things you hunt: events and files.
Sigma is for logs. YARA is for files and memory. Learn which question you are asking and the tool is obvious.
Sigma: one rule, every SIEM
A Sigma rule is a YAML file that describes a log source and a detection condition in vendor-neutral terms. A converter turns it into SPL, KQL, Elastic DSL, or whatever backend you run. The SigmaHQ repo on GitHub ships thousands of community rules you can adapt instead of starting cold.
Here is a rule for the Office-spawns-a- behavior from the earlier lessons:
title: Office Application Spawns Command Shell
id: 8f2b0e11-3a4c-4d5e-9f01-2a3b4c5d6e7f
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith:
- '\winword.exe'
- '\excel.exe'
- '\powerpnt.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
condition: selection
falsepositives:
- Legitimate document macros in finance workflows
level: high
The condition field is the logic. Everything under detection is a named block of matches, and the condition combines them. Convert it with the sigma CLI:
$pip install sigma-cli$sigma convert -t splunk office_spawns_shell.yml$sigma convert -t kusto office_spawns_shell.ymlSame YAML, two SIEMs, zero rewriting. That is the entire reason Sigma exists.
YARA: match the file, not the log
YARA answers a different question: is this specific badness present in a file, a process, or a ? You describe it with and a condition, and the YARA engine scans. responders and analysts live in it.
rule Suspicious_PowerShell_Downloader {
meta:
author = "lab"
description = "Flags PowerShell scripts that download and execute"
strings:
$a = "DownloadString" nocase
$b = "IEX" nocase
$c = "FromBase64String" nocase
condition:
2 of ($a, $b, $c)
}
The condition says match when at least two of those three strings appear, which is loose enough to catch variants and tight enough to skip a script that merely mentions one keyword. Run it across a :
$yara -r downloader.yar /mnt/evidence/YARA scans live memory too, which is where fileless malware hides. yara -r rules.yar <pid> matches against a running process, catching that never touched disk.
Which one, when
If your data is an event in a log, that is Sigma. If your data is bytes in a file or a process, that is YARA. Plenty of real detections use both: a Sigma rule flags the suspicious process creation in your , and a YARA rule confirms what the dropped file actually is once you pull it.
YARA rules pointed at file systems and memory that hold other people's data, and Sigma rules run against production logs. Scan , images, and log stores only when you own them or have written for the engagement. Grabbing a malware sample to test a rule is fine in an isolated lab, never on a shared or production machine.
You need to detect a known ransomware binary sitting on disk across 500 endpoints by its byte patterns. Sigma or YARA?
The signal is bytes in a file, not an event in a log. Which tool scans files and memory?