What Are Sigma Rules?

Definition

Sigma is an open, generic signature format for describing log events relevant to security operations. Created by Florian Roth and Thomas Patzke in 2017, Sigma does for log analysis what YARA does for file scanning and Snort does for network traffic: it provides a standardized, platform-independent way to express detection logic that can be shared across organizations and converted to the native query language of any SIEM.

A Sigma rule is a YAML document that specifies three things: where to look (the log source), what to look for (field conditions and their logical relationships), and why it matters (metadata including severity, MITRE ATT&CK mappings, and references). The rule does not contain any vendor-specific syntax. Conversion to a target platform — Splunk, Microsoft Sentinel, Elastic, Chronicle, QRadar, or any supported backend — is handled by separate tooling.

This separation of detection logic from query language is what makes Sigma powerful. A detection engineer can write a rule describing suspicious PowerShell execution and share it publicly. A Splunk shop converts it to SPL. A Sentinel shop converts it to KQL. An Elastic shop converts it to Lucene or EQL. The detection logic is identical across all three; only the syntax differs.

Why Sigma Exists

Before Sigma, sharing detection rules between organizations required translating vendor-specific queries by hand. A detection published in SPL was usable only by Splunk customers. If a threat researcher wrote a detection for a new attack technique, they had to publish multiple versions — one for each SIEM — or accept that most of their audience could not use it. In practice, most detections were published in a single format, and the majority of the community received no actionable output.

Sigma solved this problem by introducing an abstraction layer. The detection logic is expressed once, in a format that is both human-readable and machine-parseable. The key problems Sigma addresses:

• Vendor lock-in. Organizations change SIEMs. Detection libraries written entirely in SPL become technical debt when migrating to Sentinel. Sigma rules survive platform migrations because conversion is automated.
• Community sharing. A universal format enables a global community to contribute detection rules. The SigmaHQ repository contains thousands of peer-reviewed rules that any team can deploy regardless of their SIEM.
• Consistency. Sigma enforces a structured format with required metadata — severity levels, MITRE ATT&CK mappings, descriptions, and references. This produces detection rules that are documented, traceable, and maintainable by default.
• Audit and compliance. Because Sigma rules are declarative YAML, they can be version-controlled, diffed, reviewed in pull requests, and tested in CI/CD pipelines. This brings software engineering practices to detection engineering.

YAML Syntax Breakdown

A Sigma rule is a valid YAML document with a defined set of top-level fields. Some are required, some are recommended, and some are optional. Understanding the structure is essential for both writing and reading rules.

Logsource, Detection & Condition

The logsource and detection blocks are the operational core of every Sigma rule. They define where to look and what to look for.

Logsource

The logsource block describes the type of log data the rule applies to. It uses three optional fields that work together to identify the correct data:

YAMLlogsource:
  category: process_creation    # Generic log type
  product: windows              # Operating system or product
  service: sysmon               # Specific log service/channel

category is the most important field — it maps to an abstract log type like process_creation, network_connection, file_event, dns_query, or image_load. During conversion, pySigma's pipeline maps these categories to the correct index, sourcetype, or table for the target SIEM. For example, category: process_creation with product: windows maps to Sysmon EventID 1 in Splunk or the DeviceProcessEvents table in Microsoft Defender.

Detection

The detection block contains one or more named search identifiers (conditions) and a condition statement that combines them with boolean logic. Each search identifier is a dictionary of field-value pairs that are AND-joined by default.

YAMLdetection:
  selection_process:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_args:
    CommandLine|contains|all:
      - '-enc'
      - 'bypass'
  filter_legitimate:
    ParentImage|endswith: '\svchost.exe'
    User|contains: 'SYSTEM'
  condition: (selection_process and selection_args) and not filter_legitimate

Key syntax patterns in the detection block:

• Field modifiers use the pipe (|) character: endswith, startswith, contains, re (regex), base64, cidr, all, windash
• Lists within a single field are OR-joined: Image|endswith: ['\powershell.exe', '\pwsh.exe'] means "image ends with powershell.exe OR pwsh.exe"
• Multiple fields within a single search identifier are AND-joined
• |all modifier changes list behavior from OR to AND: contains|all means the field must contain every listed value
• The condition combines search identifiers using and, or, not, and parentheses

Example Sigma Rule (Annotated)

The following rule detects a common MITRE ATT&CK technique — encoded PowerShell command execution (T1059.001) — which is frequently used by malware, ransomware operators, and penetration testers for defense evasion.

SIGMAtitle: Suspicious Encoded PowerShell Command Line
id: f6c7d850-c3d4-4a1e-8b5a-2d9e7f3a4c6b
status: stable
description: |
  Detects execution of PowerShell with encoded command line arguments,
  a common technique used by malware and post-exploitation frameworks
  to obfuscate malicious commands.
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://attack.mitre.org/techniques/T1027/
author: Threadlinqs Intelligence
date: 2026/01/15
modified: 2026/03/20
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_encoded:
    CommandLine|contains:
      - '-encodedcommand'
      - '-enc '
      - '-ec '
      - '-enco'
  selection_hidden:
    CommandLine|contains:
      - '-w hidden'
      - '-window hidden'
      - '-windowstyle hidden'
  filter_legitimate:
    ParentImage|endswith:
      - '\msiexec.exe'
      - '\ConfigMgr\\'
    CommandLine|contains: 'WindowsUpdate'
  condition: selection_binary and (selection_encoded or selection_hidden) and not filter_legitimate
falsepositives:
  - Legitimate administrative scripts using encoded commands
  - Software deployment tools (SCCM, Intune)
  - Monitoring agents with encoded parameters
level: high

Conversion to SPL and KQL

The Sigma rule above is platform-agnostic. To deploy it, you convert it to your SIEM's native query language using pySigma and its backend plugins. Here is what the same detection logic looks like after conversion.

Converted to Splunk SPL

SPLindex=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\powershell.exe" OR Image="*\\pwsh.exe")
AND (
  (CommandLine="*-encodedcommand*" OR CommandLine="*-enc *"
   OR CommandLine="*-ec *" OR CommandLine="*-enco*")
  OR
  (CommandLine="*-w hidden*" OR CommandLine="*-window hidden*"
   OR CommandLine="*-windowstyle hidden*")
)
NOT (
  (ParentImage="*\\msiexec.exe" OR ParentImage="*\\ConfigMgr\\*")
  AND CommandLine="*WindowsUpdate*"
)
| table _time, ComputerName, User, ParentImage, Image, CommandLine

Converted to Microsoft KQL

KQLDeviceProcessEvents
| where (FolderPath endswith "\\powershell.exe"
    or FolderPath endswith "\\pwsh.exe")
    and (
      (ProcessCommandLine contains "-encodedcommand"
       or ProcessCommandLine contains "-enc "
       or ProcessCommandLine contains "-ec "
       or ProcessCommandLine contains "-enco")
      or
      (ProcessCommandLine contains "-w hidden"
       or ProcessCommandLine contains "-window hidden"
       or ProcessCommandLine contains "-windowstyle hidden")
    )
    and not (
      (InitiatingProcessFolderPath endswith "\\msiexec.exe"
       or InitiatingProcessFolderPath endswith "\\ConfigMgr\\")
      and ProcessCommandLine contains "WindowsUpdate"
    )
| project Timestamp, DeviceName, AccountName,
  InitiatingProcessFolderPath, FolderPath, ProcessCommandLine

Notice the structural differences: SPL uses wildcard matching (*\\powershell.exe), pipe-separated commands, and index/sourcetype filters. KQL uses endswith/contains operators, where clauses, and references Microsoft Defender table and field names. The detection logic is identical — only the syntax changed. This is the core value proposition of Sigma.

pySigma Conversion

To convert a Sigma rule yourself, install pySigma and the appropriate backend:

BASH# Install pySigma and Splunk backend
pip install pySigma pySigma-backend-splunk pySigma-pipeline-sysmon

# Convert a single rule
sigma convert -t splunk -p sysmon rule.yml

# Convert to KQL for Microsoft Sentinel
pip install pySigma-backend-microsoft365defender
sigma convert -t microsoft365defender rule.yml

# Convert an entire directory of rules
sigma convert -t splunk -p sysmon ./rules/windows/

The -p flag specifies a processing pipeline that maps generic Sigma field names (like Image) to the correct field names for your specific log source configuration. Pipelines are critical — without them, the converted query references field names that may not exist in your environment.

The SigmaHQ Community

The SigmaHQ GitHub repository is the central, community-maintained collection of Sigma detection rules. As of early 2026, it contains over 3,000 rules organized by log source category and MITRE ATT&CK technique. It is the largest open-source detection rule repository in the world.

SigmaHQ rules are organized into directories that mirror log source categories:

TREErules/
  windows/
    process_creation/     # Sysmon EID 1, Security EID 4688
    file_event/           # Sysmon EID 11
    registry_event/       # Sysmon EID 12/13/14
    network_connection/   # Sysmon EID 3
    image_load/           # Sysmon EID 7
    dns_query/            # Sysmon EID 22
    pipe_created/         # Sysmon EID 17/18
  linux/
    process_creation/
    file_event/
  cloud/
    aws/
    azure/
    gcp/
  network/
    firewall/
    proxy/

Every rule in SigmaHQ follows a strict schema and undergoes community review before being merged. Rules are tagged with MITRE ATT&CK technique IDs, severity levels, and false positive guidance — making them deployable out of the box for teams that maintain proper log source mappings.

SigmaHQ is to detection rules what the CVE database is to vulnerabilities — a shared, structured, publicly accessible knowledge base that the entire security community builds upon. See: github.com/SigmaHQ/sigma

Rule Writing Best Practices

Writing effective Sigma rules requires the same discipline as writing production code. A detection rule that produces too many false positives is worse than no rule at all — it trains analysts to ignore alerts. Here are the practices that separate production-grade rules from prototypes.

Be specific with field modifiers

Use endswith instead of contains when matching binary paths. Image|contains: 'powershell' will match C:\Tools\powershell_helper.exe — a false positive. Image|endswith: '\powershell.exe' matches only the actual PowerShell binary. Every modifier choice is a precision-versus-recall tradeoff.

Layer selections with filters

Start with a broad selection that captures all potentially malicious behavior, then add filters that exclude known legitimate patterns. This approach is easier to maintain because new false positives are addressed by adding filters, not by making the selection more complex. Keep selections and filters as separate search identifiers for readability.

Use |all for AND-joined lists

When a command line must contain multiple suspicious tokens (not just one), use the |all modifier: CommandLine|contains|all: ['-enc', 'bypass']. This is more precise than two separate field conditions and reads more clearly in the YAML.

Document false positives honestly

The falsepositives field is not optional in practice. If you do not document known false positive sources, every SOC that deploys your rule will independently discover them, tune them out, and possibly tune the rule into uselessness. Be specific: "SCCM client encoded PowerShell during software deployment" is useful. "Legitimate admin activity" is not.

Tag with MITRE ATT&CK

Every rule should include ATT&CK tags in the format attack.tactic_name and attack.tNNNN (or attack.tNNNN.NNN for sub-techniques). These tags enable automated coverage mapping — tools like the ATT&CK Navigator can visualize which techniques your detection library covers and where gaps exist.

Test with real data

Convert the rule to your target SIEM format and run it against historical data before deploying to production. Check both true positive rate (does it catch the attack?) and false positive rate (does it fire on normal activity?). A rule that has never been tested against real logs is a hypothesis, not a detection.

How Threadlinqs Uses Sigma

Threadlinqs Intelligence ships every detection rule in three formats: Splunk SPL, Microsoft KQL, and Sigma. Each threat in the platform includes production-ready detection rules mapped to the specific techniques used in that campaign, with Sigma rules that can be deployed directly or converted to any additional SIEM format.

The platform's detection library contains over 1,800 rules across all three formats. Each Sigma rule includes full metadata — MITRE ATT&CK technique mappings, severity levels, false positive guidance, and references to the threat report that motivated the detection. The MCP server integration enables automated retrieval of Sigma rules by threat ID, technique, or severity, allowing security teams to programmatically build and maintain their detection libraries.

For teams building detection-as-code pipelines, Threadlinqs Sigma rules are designed to slot directly into CI/CD workflows: pull rules via the API, convert to your target format with pySigma, validate against your field mappings, and deploy to your SIEM — all automated, all version-controlled.

Frequently Asked Questions