Tools
T1059, T1110Sigma Rules
A practical introduction to Sigma, the open detection-rule format used to describe suspicious log activity in a SIEM-agnostic way. Includes real rule examples, field mappings, conversion tools, and integration patterns with Event IDs.
View on Graph
What Sigma Is
- Sigma is a generic detection rule format for log-based detections.
- A Sigma rule is written in YAML and describes the suspicious behavior, the relevant log source, matching fields, and the condition that must be true.
- The point is portability: defenders can describe the logic in a standard format and then convert or adapt it for tools such as Splunk, Elastic Security, KQL-based Sentinel, QRadar, or other SIEM and XDR platforms.
- Sigma is maintained by the SigmaHQ project on GitHub and includes a public repository of over 3,000 community-contributed rules.
Core Parts of a Rule
title: PowerShell Encoded Command Execution
id: 00000000-0000-0000-0000-000000000000
status: experimental
description: Detects PowerShell execution with EncodedCommand flag
author: SOC Analyst
date: 2026-05-23
tags:
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
CommandLine|contains: '-EncodedCommand'
condition: selection
falsepositives:
- Legitimate administration scripts
level: high
Required Sections
| Section | Purpose | Required? |
|---|---|---|
| title | Descriptive name of the rule | Yes |
| id | Unique UUID for the rule | Yes |
| description | What the rule detects and when to use it | Yes |
| logsource | Log type and product (Windows, Linux, network) | Yes |
| detection | The actual detection logic (selections + condition) | Yes |
| condition | Boolean logic combining selections | Yes |
| level | Alert severity (low, medium, high, critical) | Yes |
| status | Rule maturity (stable, test, experimental, deprecated) | Recommended |
| tags | MITRE ATT&CK mapping | Recommended |
| author | Rule author | Recommended |
| falsepositives | Known scenarios that trigger the rule | Recommended |
| references | URLs for further context | Recommended |
Logsource — Mapping to Real Event IDs
The logsource section maps a Sigma rule to a specific log type. Here are the most common mappings for Windows:
| Sigma Logsource Category | Windows Event ID / Log | What It Covers |
|---|---|---|
process_creation | Sysmon Event ID 1 or Security Event ID 4688 | Process creation with command line |
file_event | Sysmon Event ID 11 | File creation, modification, rename |
image_load | Sysmon Event ID 7 | DLL loading by a process |
network_connection | Sysmon Event ID 3 | Outbound network connections |
registry_event | Sysmon Event ID 12, 13, 14 | Registry modifications |
process_access | Sysmon Event ID 10 | Cross-process access (credential dumping) |
dns_query | Sysmon Event ID 22 | DNS queries by process |
windows_security | Security Event Log (Event IDs 4624, 4625, etc.) | Authentication events |
windows_system | System Event Log | System events (services, drivers) |
powershell | PowerShell Operational (Event ID 4103, 4104) | PowerShell script block logging |
Example: Logsource for Process Creation
logsource:
category: process_creation
product: windows
This maps to Sysmon Event ID 1. When you write selection under this logsource, you are describing fields from Sysmon Event 1: Image, CommandLine, ParentImage, User, Hashes, etc.
Real Detection Rules — Practical Examples
Rule 1: Suspect Service Installation from User-Writable Path
Detects attackers installing services from directories where standard users can write files (common privilege escalation / lateral movement technique).
title: Service Installation from User-Writable Path
id: 00000000-0000-0000-0000-000000000001
status: stable
description: Detects service installation where the binary path is in a user-writable directory
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1543.003
logsource:
service: security
product: windows
detection:
selection:
EventID: 4697
ServiceFileName|contains:
- '\Users\'
- '\Temp\'
- '\AppData\'
- '\Desktop\'
condition: selection
falsepositives:
- Some legitimate applications install per-user services
level: high
Rule 2: LSASS Credential Dumping via Process Access
Detects non-standard processes accessing LSASS memory (Sysmon Event ID 10).
title: LSASS Credential Dumping
id: 00000000-0000-0000-0000-000000000002
status: stable
description: Detects non-standard processes accessing LSASS process memory
tags:
- attack.credential_access
- attack.t1003.001
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess: '0x1FFFFF'
filter:
SourceImage:
- 'C:\Windows\System32\wmiprvse.exe'
- 'C:\Windows\System32\svchost.exe'
- 'C:\Windows\System32\Lsaiso.exe'
condition: selection and not filter
falsepositives:
- Legitimate LSASS protection software
- Antivirus scanning of LSASS memory
level: critical
Rule 3: DNS Query for Known Malicious Domain
title: DNS Query to Malicious Domain
id: 00000000-0000-0000-0000-000000000003
status: experimental
description: Detects DNS queries to known malicious domains from threat intel
tags:
- attack.command_and_control
- attack.t1071
logsource:
category: dns_query
product: windows
detection:
selection:
QueryName|contains:
- '.xyz'
- '.top'
- '.gq'
- '.ml'
filter:
Image|endswith:
- '\svchost.exe'
- '\System'
condition: selection and not filter
falsepositives:
- Some legitimate sites use these TLDs
level: medium
Rule 4: PowerShell Download Cradle
title: PowerShell Download Cradle
id: 00000000-0000-0000-0000-000000000004
status: stable
description: Detects PowerShell downloading and executing remote content
tags:
- attack.execution
- attack.t1059.001
- attack.command_and_control
- attack.t1105
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
CommandLine|contains:
- 'Net.WebClient'
- 'DownloadString'
- 'DownloadFile'
- 'Invoke-RestMethod'
- 'Invoke-WebRequest'
- 'IEX'
- 'wget'
- 'curl'
condition: selection
falsepositives:
- System administrators using PowerShell remoting features
level: high
Using the Sigma CLI — Converting Rules
The sigma-cli tool converts Sigma rules to target SIEM formats:
# Install sigma-cli
pip install sigma-cli
# Convert a Sigma rule to Splunk SPL
sigma convert -t splunk -p splunk-windows my_rule.yml
# Convert to Elasticsearch EQL
sigma convert -t es-rule my_rule.yml
# Convert to Microsoft Sentinel (KQL)
sigma convert -t sentinel-rule my_rule.yml
# Convert to QRadar
sigma convert -t qradar -p qradar-windows my_rule.yml
# Convert to Kibana/Elasticsearch query
sigma convert -t es-dsl my_rule.yml
Conversion Example
Input rule (Sigma YAML):
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains: '-EncodedCommand'
condition: selection
Output (Splunk SPL):
Image=*\\powershell.exe CommandLine=*-EncodedCommand*
Output (Elasticsearch EQL):
process where process.executable == "*\\powershell.exe" and process.command_line == "*-EncodedCommand*"
How To Use Sigma Safely — The Pipeline Workflow
Step 1: Research
Find a rule from the SigmaHQ public repository or write your own. Check the rule metadata — what TTP does it cover? What logsource does it need?
Step 2: Validate
| Check | Why It Matters |
|---|---|
| Does your environment have the required log source? | A rule that needs Sysmon Event 22 (DNS Query) won’t fire if you don’t collect DNS events. |
| Are the field names the same? | Sigma uses normalized field names. Your SIEM may use different names (e.g., CommandLine vs command_line vs process.command_line). Use a pipeline file to map fields. |
| Are the false positives documented? | Test the rule in your environment before enabling alerting. |
| Is the level appropriate? | A critical rule firing 100 times a day is no longer actionable. Tune the level or add filters. |
Step 3: Test
Run the rule against historical data to understand its true-positive and false-positive rates before enabling it in production.
Step 4: Tune
Add filter sections to exclude known-good behavior in your environment:
detection:
selection:
... (the actual pattern)
filter_1:
Image: 'C:\Windows\System32\cleanmgr.exe' # Your approved disk cleanup tool
filter_2:
CommandLine|contains: 'approved-admin-script.ps1' # Your approved admin script
condition: selection and not 1 of filter_*
Step 5: Deploy
Enable the rule in your SIEM. Monitor for the first week to ensure it is detecting the intended behavior without overwhelming noise.
Step 6: Maintain
Sigma rules are not write-once. As your environment changes (new applications, new users, new infrastructure), rules need periodic review and tuning.
Creating a Sigma Rule — Cheat Sheet
RULE STRUCTURE:
─────────────────────────────────────────────────────
title: [Short description of what this detects]
id: [UUID - generate at uuidgenerator.net]
status: [stable|test|experimental|deprecated]
description: [1-2 sentence explanation]
author: [Your name]
date: [YYYY-MM-DD]
modified: [YYYY-MM-DD - if updated]
tags:
- attack.[tactic]
- attack.[technique_id]
logsource:
category: [process_creation|file_event|network_connection|registry_event|etc]
product: [windows|linux|macos|network]
detection:
selection:
FieldName: 'value' # Exact match
FieldName|contains: 'value' # Substring match
FieldName|startswith: 'val' # Starts with
FieldName|endswith: 'ue' # Ends with
FieldName: # OR of values
- 'value1'
- 'value2'
filter:
FieldName: 'excluded_value'
condition: selection and not filter
falsepositives:
- 'Known false positive scenario'
level: [low|medium|high|critical]
─────────────────────────────────────────────────────
Related
- Azure Sentinel — detection and response for T1654 techniques
- Metasploit — detection and response for T1203 techniques
- EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques
- MFA Fatigue — detection and response for T1110.004, T1621 techniques
- MITRE ATT&CK for Triage — covers the mitre att&ck for triage concepts
