Sigma Rules: Universal Detection Logic and SIEM Conversion
One of the most persistent problems in defensive cybersecurity has been the fragmentation of detection languages: every SIEM has its own proprietary syntax, every platform requires different queries, and rules written for Splunk don't work on Elastic, which in turn isn't compatible with Microsoft Sentinel. The result is that SOC teams spend enormous amounts of time rewriting the same detection logic for each tool, instead of focusing on what really matters: finding threats before they cause damage.
Sigma rules were created exactly to solve this problem. Introduced by Florian Roth and Thomas Patzke, Sigma is today the de facto standard format for writing portable, platform-independent detection rules. A Sigma rule written once can be automatically converted to Splunk SPL, Elasticsearch KQL, Microsoft Sentinel KQL, IBM QRadar, Chronicle YARA-L, and over 40 other targets. In this article we explore Sigma syntax in depth, logsource mapping patterns, modification and conversion techniques, and how to integrate Sigma into a modern Detection-as-Code pipeline.
What You Will Learn
- Complete structure of a Sigma rule: title, logsource, detection, condition
- Logsource mapping: category, product, service and how they translate in SIEMs
- Advanced modifiers: contains, startswith, endswith, re, base64offset
- Aggregation conditions: count, sum, min, max for statistical detection
- Automatic conversion with sigma-cli to Splunk, Elastic and Sentinel
- Detection patterns for lateral movement, persistence, exfiltration
- Testing and validation of Sigma rules with synthetic data
- Managing an enterprise Sigma repository with best practices
What is Sigma and Why It Became the Standard
Sigma is an open, YAML-based format for describing detection patterns on security logs in a platform-independent way. Think of it as YARA for logs: just as YARA allows writing rules for malicious files that work on any scanner, Sigma allows writing detection rules that work on any SIEM.
The SigmaHQ project hosts today over 3,000 community rules under continuous maintenance, mapped to the MITRE ATT&CK framework, and ready for conversion. Growth has been explosive: from a niche tool for threat hunters, Sigma has become the common language of professional detection engineers. The main advantages are three:
- Portability: write one rule, deploy it on N different SIEMs
- Collaboration: rules are readable by anyone, regardless of the SIEM in use
- Automation: conversion is fully automatable in CI/CD
Anatomy of a Sigma Rule
A Sigma rule is a YAML file with well-defined fields. Let us examine the complete structure with a real example that detects mimikatz usage through Windows Event Logs:
title: Mimikatz Detection via Windows Security Events
id: 0d82df6e-0e4e-4fbb-a12b-6e7a00a9c7c3
status: stable
description: Detects mimikatz usage patterns via LSASS access events
and command-line indicators
references:
- https://github.com/gentilkiwi/mimikatz
- https://attack.mitre.org/techniques/T1003/001/
author: Federico Calo
date: 2026/03/01
modified: 2026/03/09
tags:
- attack.credential_access
- attack.t1003.001
- attack.defense_evasion
logsource:
category: process_access
product: windows
detection:
selection_lsass:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1038'
- '0x1400'
- '0x143a'
selection_mimikatz_cli:
CommandLine|contains|all:
- 'sekurlsa'
- 'logonpasswords'
filter_legitimate:
SourceImage|startswith:
- 'C:\Windows\System32\'
- 'C:\Program Files\Windows Defender\'
condition: (selection_lsass and not filter_legitimate) or selection_mimikatz_cli
falsepositives:
- Legitimate security tools performing LSASS inspection
- Antivirus and EDR solutions
level: high
Mandatory Fields and Metadata
The metadata block at the beginning of the rule serves both documentation and management automation purposes:
- title: human-readable rule name. Must be unique and descriptive. Convention: "Verb + Subject + Context"
- id: unique UUID v4. Never changes over time, allows tracking versions and false positive reports
-
status: rule lifecycle. Valid values are:
stable,test,experimental,deprecated,unsupported -
level: severity. Values:
informational,low,medium,high,critical -
tags: list of MITRE ATT&CK tags in format
attack.t<ID>for techniques orattack.<tactic>for tactics
Logsource: The Heart of Portability
The logsource block is the magic that makes Sigma portable.
Instead of specifying a SIEM-specific index or data stream, it defines the log
type abstractly through three fields: category, product,
and service.
The sigma-cli pipeline system translates these abstract logsources into the concrete
paths of each SIEM. For example, category: process_creation on
product: windows becomes:
| SIEM Target | Logsource Translation |
|---|---|
| Splunk | source="WinEventLog:Security" EventCode=4688 |
| Elasticsearch (ECS) | event.category:process AND event.type:start |
| Microsoft Sentinel (KQL) | SecurityEvent | where EventID == 4688 |
| Chronicle (YARA-L) | $event.metadata.event_type = "PROCESS_LAUNCH" |
Advanced Modifiers
Modifiers are suffixes added to field names with the pipe character
| to modify the match type. Knowing them all is fundamental for
writing effective rules:
| Modifier | Description | Example |
|---|---|---|
contains |
Substring match (wildcard on both sides) | CommandLine|contains: 'mimikatz' |
startswith |
Match at the beginning of the value | Image|startswith: 'C:\Users\' |
endswith |
Match at the end of the value | Image|endswith: '\cmd.exe' |
re |
PCRE regex | CommandLine|re: '(?i)sekurlsa' |
base64offset |
Decode base64 with offset 0,1,2 | CommandLine|base64offset|contains: 'IEX' |
all |
All list values must match (AND) | CommandLine|contains|all: ['-enc', 'bypass'] |
cidr |
CIDR range match for IPs | DestinationIp|cidr: '10.0.0.0/8' |
Aggregation Conditions: Statistical Detection
Some detections require counting events within a time window, not matching a single event. Sigma supports aggregation conditions for these use cases:
# Brute force detection: more than 10 failed logins in 60 seconds
title: Windows Brute Force Login Attempt
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
LogonType: 3
condition: selection | count() > 10
timeframe: 60s
level: medium
---
# Port scan detection: many different ports from same source
title: Network Port Scan Detection
logsource:
category: network_connection
detection:
selection:
EventID: 5156
condition: selection | count(DestinationPort) by SourceAddress > 30
timeframe: 10m
level: medium
Conversion with sigma-cli: Practical Guide
sigma-cli is the official tool for converting Sigma rules into SIEM query languages. Installation and basic usage:
# Installation
pip install sigma-cli
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
# List available backends
sigma list backends
# Basic conversion: Sigma -> Splunk SPL
sigma convert -t splunk -p splunk_windows rules/mimikatz.yml
# Conversion with custom pipeline
sigma convert \
-t splunk \
-p splunk_windows \
-p my_custom_field_mapping.yml \
rules/
# Conversion for Elasticsearch with ECS
sigma convert \
-t elasticsearch \
-p ecs_windows \
-f lucene \
rules/credential_access/
# Conversion for Microsoft Sentinel (KQL)
sigma convert \
-t microsoft365defender \
-p microsoft365defender \
rules/lateral_movement/
# JSON output for automation
sigma convert \
-t splunk \
-p splunk_windows \
--format-output json \
rules/ > converted_rules.json
Warning: Pipelines and Field Mapping
Every organization has its own log normalization. If your logs do not follow the standard schema (e.g., Sysmon for Windows), you must create a custom pipeline that maps Sigma fields to the actual fields in your SIEM. Without this mapping, the converted rules will not work.
Detection Patterns for Common Use Cases
A collection of ready-to-use Sigma rules for high-priority use cases, mapped to the most exploited MITRE ATT&CK techniques:
Lateral Movement: Pass-the-Hash
title: Pass-the-Hash Attack Pattern
id: 6571d552-4c16-4f50-b5f6-11ae9d1b0a38
status: stable
description: Detects Pass-the-Hash attacks via anomalous NTLM authentication
tags:
- attack.lateral_movement
- attack.t1550.002
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 3
AuthenticationPackageName: NTLM
KeyLength: 0
filter_local:
IpAddress:
- '127.0.0.1'
- '::1'
filter_machine:
SubjectUserName|endswith: '