Sigma Rules: Portable Detection Engineering

Sigma Rules: Portable Detection Engineering - article cover image Tools & Defense
2026.07.12
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Sigma is a generic, YAML-based signature format for describing detections against log data in a SIEM-agnostic way. A single Sigma rule expresses *what to look for* — a log source and a set of field-match conditions — and the sigma-cli/pySigma toolchain then compiles that rule into a concrete query for a specific backend: Splunk SPL, Elastic/Kibana Query Language (ES|QL or Lucene via pySigma-backend-elasticsearch), Microsoft Sentinel KQL, and others. This is the same relationship Snort/Suricata rules have to network detection, applied to log/SIEM detection instead.

The practical payoff is portability and shareability: detection engineering teams, threat intel providers (SigmaHQ’s public rule repository is the largest example), and individual researchers can publish a rule once and have every consuming organization compile it for whatever backend they actually run, instead of maintaining N different vendor-specific rule sets by hand. It also decouples detection logic from any one vendor’s query syntax quirks, which matters enormously when an organization migrates SIEM platforms and does not want to lose years of accumulated detection content.

Attack Prerequisites

Framed as what has to be true for a Sigma rule to actually detect anything in production, rather than an attack precondition:

  • The underlying log source must exist and be ingested — a rule targeting category: process_creation with product: windows is worthless if Sysmon Event ID 1 (or Security 4688) is not being collected and forwarded to the SIEM in the first place.
  • Field names in the rule must match the field names the backend’s pipeline produces — this is what pySigma’s field-mapping pipelines (e.g. sigma-pipeline-sysmon conventions) handle, translating Sigma’s generic field names (Image, CommandLine, ParentImage) to whatever the SIEM actually calls that field after ingestion.
  • The rule’s logsource block must resolve unambiguously to a real index/table/data-stream in the target backend; ambiguous or missing logsource mapping is the most common cause of a rule compiling but matching nothing.
  • Detection thresholds/timeframes must fit the actual event volume — a timeframe: 5m correlation rule assumes events for the correlated fields arrive close enough together to fall in the same window at the ingestion latency the pipeline actually has.

How It Works

A Sigma rule’s logsource block declares which data it applies to via a combination of category (a normalized event type such as process_creation, network_connection, registry_event), product (windows, linux, aws, etc.), and optionally service (sysmon, security, powershell) — this is what lets the same rule be written once and matched against either Sysmon Event ID 1 or Security Event ID 4688 depending on which the target environment actually logs, via backend-specific field mappings.

The detection block is a set of named search identifiers (arbitrary labels like selection, filter, condition_1) each containing field: value pairs, and a condition string that combines them with boolean logic (selection and not filter, 1 of selection*, all of them). Field modifiers appended with a pipe — |contains, |startswith, |endswith, |re, |all, |windash (matches both - and / argument prefixes), and |cased — control the match semantics without needing regex for common cases. Values support wildcards (*) and lists (implicit OR across a YAML list under one field).

Compilation happens via sigma-cli (the pySigma-based successor to the legacy sigmac tool): sigma convert loads the rule, applies a backend plugin plus an optional pipeline (field-mapping and log-source-mapping layer specific to how a given environment ingests its logs, e.g. a Sysmon-via-Winlogbeat-into-Elastic pipeline), and emits a native query string ready to paste into or programmatically push to the target SIEM. This separation — rule logic versus backend/pipeline — is exactly what makes one rule usable across many differently configured environments.

Practical Example / Configuration

A real, valid Sigma rule detecting LSASS process-memory access consistent with credential dumping (the technique tools like Mimikatz and comsvcs.dll MiniDump abuse), matched against Sysmon Event ID 10 (ProcessAccess):

title: Potential Credential Dumping via LSASS Access
id: 8a3f2b1c-9d4e-4a6f-b2c8-1e5f7a9c3d02
status: experimental
description: >
    Detects processes other than known-legitimate ones opening a handle to
    lsass.exe with access rights consistent with memory dumping, a common
    precursor to credential theft (e.g. Mimikatz sekurlsa::logonpasswords).
references:
    - https://attack.mitre.org/techniques/T1003/001/
author: yunolay research
date: 2026-07-12
tags:
    - attack.credential-access
    - attack.t1003.001
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess:
            - '0x1010'
            - '0x1410'
            - '0x1438'
            - '0x143a'
            - '0x1fffff'
    filter_known_tools:
        SourceImage|endswith:
            - ':\Windows\System32\svchost.exe'
            - ':\Program Files\Windows Defender\MsMpEng.exe'
            - ':\Windows\System32\wbem\WmiPrvSE.exe'
    condition: selection and not filter_known_tools
falsepositives:
    - Legitimate EDR/AV agents reading LSASS memory for scanning
    - Backup or crash-dump utilities explicitly permitted in the environment
level: high
YAML

A second rule, targeting suspicious encoded PowerShell execution via Sysmon/Security process creation (Event ID 1 / 4688), demonstrating field modifiers and the windash operator for argument-prefix normalization:

title: Suspicious Encoded PowerShell Command Line
id: 3c7e1a9d-5f22-4b8e-9a11-6d2f0c4b7e91
status: stable
description: Detects PowerShell invoked with base64-encoded command
    arguments, commonly used to obfuscate download-and-execute payloads.
references:
    - https://attack.mitre.org/techniques/T1059/001/
author: yunolay research
date: 2026-07-12
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_flag:
        CommandLine|contains|windash:
            - '-enc'
            - '-encodedcommand'
    condition: selection_img and selection_flag
falsepositives:
    - Legitimate automation/config-management scripts that pass encoded
      commands (should be allowlisted by script hash or signer, not by
      disabling this rule outright)
level: medium
YAML

Compiling the first rule against two different backends shows the same logic producing genuinely different, backend-native query syntax:

# Splunk backend
sigma convert -t splunk -p sysmon lsass_access.yml

# Elasticsearch/Lucene backend
sigma convert -t elasticsearch -p ecs_windows lsass_access.yml

# Microsoft Sentinel (KQL) backend
sigma convert -t sentinel_alert_rules -p sysmon lsass_access.yml
Bash

Walkthrough / Exploitation

A realistic path from writing a Sigma rule to a deployed SIEM detection:

# 1) Validate rule syntax against the Sigma schema before anything else
sigma check lsass_access.yml
Bash
# 2) List available backends/pipelines to confirm the target environment
#    is supported (e.g. does the org ingest via Sysmon or via Security log?)
sigma list backends
sigma list pipelines
Bash
# 3) Compile to the actual backend/pipeline combination the SIEM uses
sigma convert -t splunk -p sysmon --without-pipeline -f default \
  lsass_access.yml -o lsass_access.spl
Bash
# 4) Bulk-convert an entire local clone of the public SigmaHQ ruleset,
#    filtered to a tag of interest, for a first-pass detection baseline
sigma convert -t splunk -p sysmon \
  --filter 'tags: attack.credential-access' \
  rules/windows/process_access/
Bash

Step 1 catches malformed YAML before it reaches a SIEM; step 2 confirms the pipeline is supported; step 3 produces the deployable query; step 4 is how most teams bootstrap coverage — pulling curated subsets of the public SigmaHQ repository rather than authoring every rule from scratch.

Note: level (informational/low/medium/high/critical) and status (experimental/test/stable/deprecated) are metadata fields, not detection logic — they exist so SOC tooling can triage/prioritize compiled alerts and so rule maintainers can track maturity, but a status: experimental rule still fires exactly like a stable one once compiled.

Opsec: The filter_known_tools pattern in the LSASS example is an allowlist of legitimate LSASS-touching processes, not a security boundary — an attacker who can rename or path-spoof a process to match an excluded SourceImage value defeats the filter. Prefer signer/hash-based exclusions over path-based ones where the backend’s field mapping supports them.

Detection and Defense

Because Sigma rules are themselves the detection artifact, the relevant guidance is about operating a Sigma-based detection program correctly:

  • Version-control rules alongside the pipelines/mappings that compile them so a field-mapping change (e.g. a SIEM migration) is tracked against the exact rule set it affects.
  • Track false-positive feedback per rule ID (the id: UUID field exists precisely so a rule can be referenced stably even as its title/logic evolves) and tune filter_* blocks rather than disabling rules wholesale.
  • Pull and diff against SigmaHQ regularly — the public repository is actively maintained with new technique coverage; stale local rule sets miss new LOLBin and technique variants.
  • Map rules to MITRE ATT&CK via the tags field to maintain a visible coverage matrix and identify gaps by tactic/technique rather than by rule count alone.
  • Test compiled queries against known-benign and known-malicious sample logs before enabling alerting, since a mis-mapped field name compiles cleanly but silently matches nothing.

Sigma itself detects nothing without correct log ingestion and field mapping upstream — the format’s portability only pays off when the underlying telemetry (Sysmon, Security auditing, cloud audit logs) is actually collected at the fidelity the rule assumes.

Real-World Impact

The SigmaHQ public repository is the largest open, cross-vendor detection rule set in the industry and is used directly or as a starting baseline by SOC teams, MDR providers, and SIEM vendors; several commercial SIEM/XDR products now ship native Sigma import or Sigma-derived detection content. Because Sigma rules commonly carry MITRE ATT&CK tags, they are also widely used to build and report on ATT&CK technique coverage matrices during detection-engineering maturity assessments.

Conclusion

Sigma’s contribution is not new detection logic — it is a shared, versionable, backend-agnostic way to express detection logic so it survives SIEM migrations and can be pooled across the community. The format’s power is entirely dependent on accurate logsource targeting, correct field mapping in the compiling pipeline, and the underlying log source actually being collected; a syntactically perfect rule against an uncollected event type detects nothing, which is why rule authoring and log-source engineering have to be treated as one discipline, not two.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL