Sigma Rules

Sigma Rules

Write Sigma detection, correlation, and filter rules plus processing pipelines per the Sigma v2.1.0 specification. This version is backward-compatible with v2.0.0.

Detection Rules

A detection rule matches log events against field conditions.

Template

title: <concise description of what is detected>
id: <UUIDv4>
status: <stable|test|experimental|deprecated|unsupported>
description: <what this rule detects and why it matters>
author: <name>
date: YYYY-MM-DD
modified: YYYY-MM-DD
references:
    - <URL>
tags:
    - attack.<tactic>
    - attack.<technique_id>
logsource:
    category: <category>
    product: <product>
    service: <service>
detection:
    <selection_name>:
        <FieldName|modifier1|modifier2>: <value or list>
    <filter_name>:
        <FieldName>: <value>
    condition: <selection_name> and not <filter_name>
falsepositives:
    - <known false positive scenario>
level: <informational|low|medium|high|critical>

Detection Block

The detection section maps named identifiers to field conditions, then combines them with a condition expression.

YAML mapping (AND-linked fields):

selection:
    EventID: 1
    Image|endswith: '\whoami.exe'

YAML list of mappings (OR-linked):

selection:
    - EventID: 1
      Image|endswith: '\whoami.exe'
    - EventID: 4688
      NewProcessName|endswith: '\whoami.exe'

Keyword list (field-agnostic search):

keywords:
    - 'mimikatz'
    - 'sekurlsa'

Field Modifiers

Modifiers chain with | on the field name. Common modifiers:

For the full list of 30 modifiers, incompatible combinations, and encoding chains, see references/modifiers.md.

Condition Expressions

Conditions combine named detections with boolean logic:

condition: selection and not filter
condition: 1 of selection* or keywords
condition: all of them

Precedence: not > and > or. Quantifiers: 1 of, all of, any of, N of. Wildcard patterns match detection names (selection*). them matches all identifiers except _-prefixed ones.

For the full grammar, see references/condition-syntax.md.

Wildcards in Values

* matches any number of characters, ? matches exactly one. Escape with backslash: \*, \?, \\. Non-special backslash sequences like \W are preserved literally (important for Windows paths).

Worked Example

Request: "Detect use of the Windows command line to delete shadow copies"

title: Shadow Copy Deletion via Vssadmin or WMIC
id: c947b146-0abc-4f7a-a55e-bf2fcb8dbb60
status: test
description: >
    Detects the use of vssadmin or wmic to delete volume shadow copies,
    a common ransomware and anti-forensics technique.
author: Security Team
date: 2025-01-15
references:
    - https://attack.mitre.org/techniques/T1490/
tags:
    - attack.impact
    - attack.t1490
logsource:
    category: process_creation
    product: windows
detection:
    selection_vssadmin:
        Image|endswith: '\vssadmin.exe'
        CommandLine|contains|all:
            - 'delete'
            - 'shadows'
    selection_wmic:
        Image|endswith: '\wmic.exe'
        CommandLine|contains|all:
            - 'shadowcopy'
            - 'delete'
    condition: 1 of selection_*
falsepositives:
    - Legitimate backup rotation scripts
level: high

For the full detection rule reference (metadata fields, logsource, multi-document YAML, tags), see references/detection-rules.md.

---

Correlation Rules

Correlation rules aggregate or sequence events matched by detection rules over a time window, grouped by key fields.

Template

title: <what the correlation detects>
id: <UUIDv4>
correlation:
    type: <correlation_type>
    rules:
        - <rule-id or wildcard>
    group-by:
        - <field>
    timespan: <duration>
    condition:
        gte: <threshold>
level: <level>

Correlation Types

Condition Block

Threshold (mapping): for count/metric types:

condition:
    gte: 100

With field (required for value_count, value_sum, value_avg, value_percentile, value_median):

condition:
    field: SourceIP
    gte: 5

Operators: gt, gte, lt, lte, eq, neq. Values must be numeric.

Extended (string): for temporal types:

condition: "recon_scan and lateral_movement"

Timespan

Format: integer + unit suffix. Units: s (seconds), m (minutes), h (hours), d (days), w (weeks), M (months, uppercase), y (years). Both timespan and timeframe keys are accepted.

Worked Example

Request: "Alert on brute force: more than 5 failed logins from the same user within 5 minutes"

title: Failed Login
id: d4c9a825-fdb3-472e-9b0e-fa4709aba44c
status: test
logsource:
    category: authentication
    product: windows
detection:
    selection:
        EventType: failed_login
    condition: selection
level: low
---
title: Brute Force Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
correlation:
    type: event_count
    rules:
        - d4c9a825-fdb3-472e-9b0e-fa4709aba44c
    group-by:
        - User
    timespan: 5m
    condition:
        gte: 5
level: critical

For all 8 correlation types with full examples, see references/correlation-rules.md.

---

Filter Rules

Filter rules inject AND NOT exclusion conditions into referenced detection rules, enabling centralized tuning without modifying original rules.

Template

title: <what is being filtered>
logsource:
    category: <must match target rule>
    product: <must match target rule>
filter:
    rules:
        - <target-rule-id>
    selection:
        <FieldName|modifier>: <value>
    condition: selection

Key Points

• selection, condition, and rules all live inside the filter section
• rules: [] (empty) applies the filter globally to all matching rules
• Filter rules should not have level or status fields
• Multiple filters on the same rule use independent detection namespaces (no collision)

Worked Example

Request: "Exclude service accounts from the brute force rule"

title: Exclude Service Accounts from Brute Force
logsource:
    category: authentication
    product: windows
filter:
    rules:
        - d4c9a825-fdb3-472e-9b0e-fa4709aba44c
    selection:
        User|startswith: 'svc_'
    condition: selection

For global vs targeted filters and multi-filter patterns, see references/filter-rules.md.

---

Processing Pipelines

Pipelines transform Sigma rule ASTs before evaluation -- typically for field name mapping between generic Sigma field names and backend-specific schemas (ECS, Splunk CIM, etc.).

Template

name: <pipeline name>
priority: <integer, lower runs first>
transformations:
  - type: field_name_mapping
    mapping:
      <SigmaField>: <backend_field>
    rule_conditions:
      - type: logsource
        product: <product>

Common Transformations

Rule Conditions

Transformations only apply when all rule_conditions match:

Worked Example

Request: "Map generic Sigma fields to Elastic Common Schema for Windows process creation rules"

name: ECS Windows Process Creation
priority: 10
transformations:
  - type: field_name_mapping
    mapping:
      CommandLine: process.command_line
      Image: process.executable
      ParentImage: process.parent.executable
      User: user.name
      OriginalFileName: process.pe.original_file_name
      Hashes: process.hash
      ParentCommandLine: process.parent.command_line
      IntegrityLevel: winlog.event_data.IntegrityLevel
      LogonId: winlog.logon.id
    rule_conditions:
      - type: logsource
        product: windows
        category: process_creation
  - type: change_logsource
    product: windows
    category: process_creation
    rule_conditions:
      - type: logsource
        product: windows
        category: process_creation

For the full list of 26 transformations, all condition types, variables, and expression syntax, see references/pipelines.md.

---

Authoring Checklist

When writing or reviewing Sigma rules, verify:

• [ ] title is present and under 256 characters
• [ ] id is a valid UUIDv4 (8-4-4-4-12 hex format)
• [ ] status is one of: stable, test, experimental, deprecated, unsupported
• [ ] level is one of: informational, low, medium, high, critical
• [ ] date and modified use YYYY-MM-DD format; modified >= date
• [ ] logsource is present with at least one of category, product, service
• [ ] Logsource values are lowercase
• [ ] Detection has at least one named identifier and a condition
• [ ] Condition only references identifiers that exist in the detection block
• [ ] Tags match ^[a-z0-9_-]+\.[a-z0-9._-]+$ (e.g. attack.t1059)
• [ ] No incompatible modifier combinations (e.g. contains|startswith, re|contains)
• [ ] deprecated rules have a related entry
• [ ] Correlation rules have type, rules, group-by, and timespan
• [ ] Filter rules have rules, selection, and condition inside the filter section
• [ ] Filter rules do not have level or status

Multi-Document YAML

Multiple rules in one file are separated by ---. Collection actions control template inheritance:

• action: global -- store as template merged into all subsequent rules
• action: reset -- clear the template
• action: repeat -- clone the previous rule and merge current fields on top

This is commonly used to share logsource across detection + correlation rule pairs.

Additional References

• Detection rules deep dive -- metadata, logsource, multi-document, tags
• Correlation rules -- all 8 types with examples
• Filter rules -- global vs targeted, multi-filter patterns
• Pipelines -- all 26 transformations and conditions
• Field modifiers -- all 30 modifiers, chaining, compatibility
• Condition syntax -- grammar, precedence, quantifiers

Sigma Rules Skill

An Agent Skill for authoring Sigma detection rules, correlation rules, filter rules, and processing pipelines.

What This Skill Does

This skill teaches AI agents the full Sigma v2.1.0 specification so they can:

• Write correct detection rules from natural language descriptions
• Create correlation rules (event_count, value_count, temporal, and 5 more types)
• Author filter rules for centralized tuning
• Build processing pipelines for field mapping (ECS, Splunk CIM, etc.)
• Use proper field modifiers, condition expressions, and multi-document YAML
• Validate rules against the specification checklist

Install

npx skills add timescale/sigma-rules -g -y

Or install for a specific agent:

npx skills add timescale/sigma-rules -g -a cursor -y
npx skills add timescale/sigma-rules -g -a claude-code -y

Structure

sigma-rules/
├── SKILL.md                          # Main skill — templates, examples, checklist
└── references/
    ├── detection-rules.md            # Detection rule format deep dive
    ├── correlation-rules.md          # All 8 correlation types with examples
    ├── filter-rules.md               # Filter rule format and usage
    ├── pipelines.md                  # Pipeline transforms and conditions
    ├── modifiers.md                  # All 30 field modifiers
    └── condition-syntax.md           # Condition expression grammar

The main SKILL.md covers the essential authoring workflow with templates and worked examples. Reference files provide deeper detail and are loaded on demand.

Coverage

• Sigma Specification v2.1.0 (backward-compatible with v2.0.0)
• 30 field modifiers with compatibility rules
• 8 correlation types (event_count, value_count, temporal, temporal_ordered, value_sum, value_avg, value_percentile, value_median)
• 26 pipeline transformation types
• Multi-document YAML (global, reset, repeat actions)
• Condition expression grammar (not > and > or, quantifiers, wildcards)

References

• Sigma Specification
• SigmaHQ Rule Repository
• pySigma

License

MIT

Condition Expression Syntax

Full reference for Sigma condition expressions per the v2.1.0 specification.

Overview

The condition field in a detection block combines named detection identifiers with boolean logic and quantifiers.

detection:
    selection:
        EventID: 1
    filter:
        User: 'SYSTEM'
    condition: selection and not filter

Operator Precedence

a or not b and c parses as a or ((not b) and c).

Use parentheses to override: (a or b) and not c.

Boolean Operators

# AND: all must match
condition: selection1 and selection2

# OR: any must match
condition: selection1 or selection2

# NOT: negate
condition: selection and not filter

# Parentheses: grouping
condition: (selection1 or selection2) and not filter

# Complex
condition: selection_parent and (selection_download or selection_encoded) and not filter

Nested same-type binary operators are flattened: a and b and c becomes And([a, b, c]), not And(a, And(b, c)).

Quantifiers

Quantifiers aggregate multiple detection identifiers.

Where X is one of:

• A wildcard pattern: selection*, filter_*
• them -- all identifiers except _-prefixed ones

Examples

# At least one selection fires
condition: 1 of selection*

# All selections must fire
condition: all of selection*

# At least 2 of the matched identifiers
condition: 2 of selection*

# Any named identifier (except _-prefixed)
condition: 1 of them

# All identifiers must fire
condition: all of them

Wildcard Patterns

selection* matches identifiers named selection, selection1, selection_cmd, etc. The * matches any suffix.

them Keyword

them matches all detection identifiers in the block except those starting with _:

detection:
    _helper:
        ParentImage|endswith: '\services.exe'
    selection1:
        Image|endswith: '\svchost.exe'
    selection2:
        Image|endswith: '\lsass.exe'
    condition: 1 of them

Here 1 of them matches selection1 or selection2 but ignores _helper. Use _-prefixed identifiers for reusable sub-detections that should not be included in quantifier aggregation.

Combining Quantifiers with Boolean Logic

condition: 1 of selection* and not 1 of filter*
condition: all of selection* or keywords
condition: (1 of selection_network* or 1 of selection_process*) and not filter

Multiple Conditions

The condition field can be a YAML list, producing independent rule evaluations:

detection:
    selection1:
        EventID: 1
    selection2:
        EventID: 4688
    condition:
        - selection1
        - selection2

Each condition is evaluated separately, potentially producing multiple matches from a single rule.

Parsing Notes

• Identifiers cannot be Sigma keywords (and, or, not, of, them, all, any). An identifier like and_filter is valid because the parser uses lookahead to distinguish keywords from identifier prefixes.
• Whitespace between operators and operands is required: aand b is an identifier, not a and b.
• Condition expressions are case-sensitive: AND is not recognized as a boolean operator (use lowercase and).

Correlation Condition Expressions

In temporal correlation rules, the condition is a string referencing rule IDs (not detection identifiers):

correlation:
    type: temporal
    rules:
        - rule-a
        - rule-b
    condition: "rule-a and rule-b"

This uses the same boolean syntax (and, or, not, parentheses) but over rule references instead of detection names.

Correlation Rules Reference

Full reference for all 8 Sigma correlation rule types per the v2.1.0 specification.

Structure

A correlation rule always requires the correlation section:

title: <description>
id: <UUIDv4>
correlation:
    type: <correlation_type>
    rules:
        - <rule-id or wildcard pattern>
    group-by:
        - <field_name>
    timespan: <duration>
    condition: <threshold or expression>
    generate: <boolean>          # optional, default false
level: <level>

Required Fields

Timespan Units

Both timespan and timeframe are accepted as key names.

Generate Flag

When generate: true, the correlation rule produces an alert even when detecting rules do not individually fire. Used for metric-based correlations where the aggregate threshold is the alert trigger.

---

Count Types

event_count

Count matching events per group key within the time window.

title: Brute Force Login Attempts
correlation:
    type: event_count
    rules:
        - <failed-login-rule-id>
    group-by:
        - User
        - SourceIP
    timespan: 5m
    condition:
        gte: 10
level: high

value_count

Count distinct values of a specific field per group key.

title: Login From Many Sources
correlation:
    type: value_count
    rules:
        - <login-rule-id>
    group-by:
        - User
    timespan: 10m
    condition:
        field: SourceIP
        gte: 5
level: high

The field key in the condition specifies which field's distinct values to count.

---

Metric Types

value_sum

Sum a numeric field across matching events per group.

title: Large Data Exfiltration
correlation:
    type: value_sum
    rules:
        - <outbound-transfer-rule-id>
    group-by:
        - SourceIP
    timespan: 1h
    condition:
        field: BytesSent
        gte: 1073741824
level: critical

value_avg

Average of a numeric field per group.

title: Abnormal Average Request Size
correlation:
    type: value_avg
    rules:
        - <http-request-rule-id>
    group-by:
        - ClientIP
    timespan: 30m
    condition:
        field: RequestSize
        gte: 10000
level: medium

value_percentile

Compute a percentile of a numeric field per group.

title: 95th Percentile Response Time
correlation:
    type: value_percentile
    rules:
        - <response-time-rule-id>
    group-by:
        - ServiceName
    timespan: 15m
    condition:
        field: ResponseTime
        gte: 5000
level: medium

value_median

Compute the median of a numeric field per group.

title: Median Payload Size Spike
correlation:
    type: value_median
    rules:
        - <payload-rule-id>
    group-by:
        - DestinationIP
    timespan: 1h
    condition:
        field: PayloadSize
        gte: 4096
level: medium

---

Temporal Types

temporal

Require multiple detection rules to fire within the same time window for the same group. No ordering requirement.

title: Recon Then Lateral Movement
correlation:
    type: temporal
    rules:
        - <recon-rule-id>
        - <lateral-movement-rule-id>
    group-by:
        - SourceIP
    timespan: 15m
    condition: "<recon-rule-id> and <lateral-movement-rule-id>"
level: critical

When no condition is specified, temporal defaults to {gte: 1} -- at least one match of each referenced rule.

temporal_ordered

Same as temporal, but the rules must fire in the order they appear in the condition expression.

title: Credential Dump Then Exfiltration
correlation:
    type: temporal_ordered
    rules:
        - <credential-dump-rule-id>
        - <exfiltration-rule-id>
    group-by:
        - User
    timespan: 30m
    condition: "<credential-dump-rule-id> and <exfiltration-rule-id>"
level: critical

---

Condition Operators

For threshold-style conditions (count and metric types):

Multiple operators can be combined in a single condition:

condition:
    gt: 10
    lte: 100

All operator values must be numeric.

---

Multi-Document Pattern

Detection and correlation rules are commonly paired in the same file using --- separators:

title: Failed SSH Login
id: ssh-failed-login
logsource:
    category: authentication
    product: linux
detection:
    selection:
        EventType: ssh_failed
    condition: selection
level: low
---
title: SSH Brute Force
id: ssh-brute-force
correlation:
    type: event_count
    rules:
        - ssh-failed-login
    group-by:
        - User
        - SourceIP
    timespan: 5m
    condition:
        gte: 10
level: critical

Use action: global to share logsource when the detection and correlation share the same platform:

action: global
logsource:
    product: windows
    category: process_creation
level: medium
---
title: Detect Cmd Execution
id: detect-cmd
detection:
    selection:
        CommandLine|contains: 'cmd'
    condition: selection
---
action: repeat
title: Detect PowerShell Execution
id: detect-ps
detection:
    selection:
        CommandLine|contains: 'powershell'
    condition: selection
---
title: Recon Burst
correlation:
    type: event_count
    rules:
        - detect-cmd
        - detect-ps
    group-by:
        - User
    timespan: 60s
    condition:
        gte: 3
level: high

Rule References with Wildcards

The rules field supports wildcard patterns to match multiple rule IDs:

correlation:
    rules:
        - "recon-*"       # matches recon-cmd, recon-ps, etc.

Detection Rules Reference

Full reference for Sigma detection rules per the v2.1.0 specification.

Metadata Fields

Related Field

related:
    - id: <UUIDv4>
      type: derived    # derived | obsolete | merged | renamed | similar

Rules with status: deprecated should have at least one related entry.

Logsource

At least one of category, product, or service is required. All values must be lowercase.

logsource:
    category: process_creation   # what kind of event
    product: windows             # which platform/product
    service: sysmon              # specific log source
    definition: >                # optional free-text for readers
        Requires Sysmon with process creation logging enabled

category describes the event type (e.g. process_creation, file_event, network_connection, authentication). product is the platform (e.g. windows, linux, macos, aws, azure). service narrows to a specific log source within the product.

Custom fields are allowed per the spec but may not be portable.

Detection Block

Parsing Rules

Multiple Values for a Field

A list of values is OR-linked by default:

selection:
    EventID:
        - 1
        - 4688

Add |all to AND-link values:

selection:
    CommandLine|contains|all:
        - 'delete'
        - 'shadows'

Multiple Conditions

The condition field can be a list, producing independent rule evaluations:

condition:
    - selection1
    - selection2

Underscore-Prefixed Identifiers

Identifiers starting with _ are excluded from them and bare all of / 1 of quantifiers. Use them for helper or reusable sub-detections.

Value Types

Wildcard Escaping

Backslash only escapes *, ?, and \. This preserves Windows paths like C:\Windows\System32.

Tags

Format: namespace.value matching ^[a-z0-9_-]+\.[a-z0-9._-]+$.

No duplicate tags allowed.

Multi-Document YAML

Separate documents with ---. Collection actions control template merging:

action: global

Stores the document as a template that merges into all subsequent rules. The action key itself is removed. No rule is produced.

action: global
logsource:
    product: windows
    category: process_creation
level: medium
---
title: Detect Cmd
detection:
    selection:
        CommandLine|contains: 'cmd'
    condition: selection
---
title: Detect Powershell
detection:
    selection:
        CommandLine|contains: 'powershell'
    condition: selection

Both rules inherit logsource and level from the global template.

action: reset

Clears the current global template. No rule is produced.

action: repeat

Clones the previous document, deep-merges the current document on top, then applies the global template. Useful for rules that differ only slightly.

action: global
logsource:
    product: windows
---
title: Detect Cmd
id: detect-cmd
detection:
    selection:
        CommandLine|contains: 'cmd'
    condition: selection
---
action: repeat
title: Detect Powershell
id: detect-ps
detection:
    selection:
        CommandLine|contains: 'powershell'
    condition: selection

Merge Order

• Normal documents: merged = deep_merge(global, document)
• Repeat documents: merged = deep_merge(global, deep_merge(previous, repeat_doc))

deep_merge is recursive: source mappings override destination keys; non-mapping source replaces destination entirely.

Complete Real-World Example

title: Suspicious PowerShell Download Cradle
id: 3b6ab547-0998-4d6b-8e34-f1e7016c37a2
status: test
description: >
    Detects PowerShell download cradles using common cmdlets
    and .NET classes to fetch remote payloads.
author: Security Operations
date: 2025-03-01
modified: 2025-06-15
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://attack.mitre.org/techniques/T1105/
tags:
    - attack.execution
    - attack.t1059.001
    - attack.command_and_control
    - attack.t1105
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_download:
        CommandLine|contains:
            - 'Invoke-WebRequest'
            - 'IWR '
            - 'wget '
            - 'curl '
            - 'Net.WebClient'
            - 'DownloadString'
            - 'DownloadFile'
            - 'Invoke-RestMethod'
            - 'Start-BitsTransfer'
    selection_encoded:
        CommandLine|contains:
            - '-enc '
            - '-EncodedCommand'
        CommandLine|re: '(http|ftp)s?://'
    condition: selection_parent and (selection_download or selection_encoded)
falsepositives:
    - Legitimate admin scripts that download tools
    - Software deployment systems
level: high

Filter Rules Reference

Full reference for Sigma filter rules per the v2.1.0 specification. Filters inject AND NOT exclusion conditions into referenced detection rules, enabling centralized tuning without modifying original rule files.

Structure

title: <what is being filtered out>
description: <optional explanation>
author: <name>
logsource:
    category: <should match target rule>
    product: <should match target rule>
filter:
    rules:
        - <target-rule-id>
    selection:
        <FieldName|modifier>: <value>
    condition: selection

Required Fields

All three of rules, selection (at least one named detection), and condition must be inside the filter section.

Fields That Should NOT Be Present

Global vs Targeted Filters

Targeted Filter

References specific rule IDs. The filter only applies to those rules:

title: Exclude Admin Users from Brute Force Detection
logsource:
    category: authentication
    product: windows
filter:
    rules:
        - d4c9a825-fdb3-472e-9b0e-fa4709aba44c
    selection:
        User|startswith: 'adm_'
    condition: selection

Global Filter

An empty rules list applies the filter to all rules with a matching logsource:

title: Exclude Test Environment Events
logsource:
    product: windows
filter:
    rules: []
    selection:
        Environment: test
    condition: selection

Multiple Filters on the Same Rule

Multiple filters can reference the same detection rule. Each filter operates independently -- detection identifier names (like selection) in different filters do not collide.

title: Rule A
id: rule-a
logsource:
    product: windows
detection:
    sel:
        EventID: 1
    condition: sel
---
title: Filter Out Test Environment
filter:
    rules:
        - rule-a
    selection:
        Environment: test
    condition: selection
---
title: Filter Out Service Accounts
filter:
    rules:
        - rule-a
    selection:
        User|startswith: 'svc_'
    condition: selection

Both filters use selection as their detection name without conflict. The resulting logic for rule-a becomes:

sel AND NOT (test-env-filter.selection) AND NOT (svc-filter.selection)

Complex Filter Conditions

Filter detections support the same syntax as regular detection blocks -- multiple identifiers and boolean conditions:

title: Exclude Known Good Processes on DC
logsource:
    category: process_creation
    product: windows
filter:
    rules:
        - <target-rule-id>
    svchost:
        Image|endswith: '\svchost.exe'
        ParentImage|endswith: '\services.exe'
    lsass:
        Image|endswith: '\lsass.exe'
        ParentImage|endswith: '\wininit.exe'
    dc_env:
        ComputerName|startswith: 'DC-'
    condition: (svchost or lsass) and dc_env

Combined: Global + Targeted

When both global and targeted filters exist, all applicable filters are applied. The order of filter application does not affect the result (they are all AND NOT):

title: Base Rule
id: base-rule
logsource:
    product: windows
detection:
    sel:
        EventID: 1
    condition: sel
---
title: Global Filter -- Test Env
filter:
    rules: []
    env_match:
        Environment: test
    condition: env_match
---
title: Targeted Filter -- Svc Account
filter:
    rules:
        - base-rule
    svc_match:
        User: svc_account
    condition: svc_match

Result for base-rule: sel AND NOT env_match AND NOT svc_match

Field Modifiers Reference

Full reference for all 30 Sigma field modifiers per the v2.1.0 specification. Modifiers are chained on the field name with | separators.

Syntax

FieldName|modifier1|modifier2: value

Modifiers are applied left-to-right. Some modifiers transform the value, others change matching behavior.

Modifier Categories

String Matching

These are mutually exclusive -- do not combine them with each other.

Value Linking

Without all, a list of values means "match any one." With all, all values must match.

Do not use all with a single value (redundant). Do not combine all with re.

Encoding

Encoding modifiers can be chained: FieldName|wide|base64offset: 'payload'

Pattern Matching

When re is present, the value is treated as a raw regex string. Backslash sequences are not interpreted as Sigma wildcards.

Case Sensitivity

Field Existence

A lone * wildcard value is equivalent to exists: true. Prefer the explicit form.

Placeholder

Field Reference

Numeric Comparison

Do not combine numeric modifiers with string matching modifiers (contains, startswith, endswith).

Regex Flags

Regex flags require the re modifier to be present.

Timestamp Parts

These were introduced in v2.1.0 and allow time-based filtering on timestamp fields.

---

Incompatible Modifier Combinations

The following combinations are invalid:

Modifier Chaining Examples

# Substring match, all values must be present (AND)
CommandLine|contains|all:
    - 'net'
    - 'user'
    - '/add'

# Case-insensitive regex
CommandLine|re|i: 'invoke-(expression|command)'

# Base64-encoded wide string at any offset
CommandLine|wide|base64offset: 'http://evil.com'

# Windash: matches both -exec and /exec
CommandLine|windash|contains: '-exec'

# Field existence check
TargetFilename|exists: true

# Numeric comparison
EventID|gte: 4688

# Field reference: match events where SourceIP equals DestinationIP
SourceIP|fieldref: DestinationIP

# Timestamp-based detection
Timestamp|hour|gte: 22

Common Patterns

OR Values (default)

selection:
    Image|endswith:
        - '\cmd.exe'
        - '\powershell.exe'
        - '\pwsh.exe'

Matches if Image ends with any of the three values.

AND Values (with all)

selection:
    CommandLine|contains|all:
        - 'net'
        - 'localgroup'
        - 'administrators'

Matches only if CommandLine contains all three strings.

Negation via Condition (not a modifier)

Negation is handled in the condition expression, not via modifiers:

detection:
    selection:
        EventID: 1
    filter:
        User: 'SYSTEM'
    condition: selection and not filter

Processing Pipelines Reference

Full reference for Sigma processing pipelines. Pipelines transform Sigma rule ASTs before evaluation or backend conversion -- typically for field name mapping between generic Sigma fields and backend-specific schemas.

Pipeline Structure

name: <pipeline name>
priority: <integer>              # lower runs first, default 0
vars:                            # variables for %name% placeholder expansion
  var_name: <string or list>
transformations:                 # ordered list of transformation items
  - id: <optional string>       # for processing_item_applied conditions
    type: <transformation_type>
    # ... type-specific parameters
    rule_conditions: []          # optional: all must match for transform to apply
    rule_cond_expression: ""     # optional: logical expression over conditions
    detection_item_conditions: []
    field_name_conditions: []
    field_name_cond_not: false   # negate field name conditions
finalizers:                      # for query backends (not used in eval mode)
  - type: <concat|json|template>

Multiple pipelines are sorted by priority (ascending) and applied in order.

---

Transformation Types (26)

Field Transformations

Value Transformations

Detection Structure Transformations

Placeholder Transformations

State and Control Transformations

---

Condition Types

Transformations are gated by conditions. All conditions in a list are AND-linked by default. Use rule_cond_expression for custom logic.

Rule Conditions (rule_conditions)

Applied at the rule level -- the transformation only runs if the rule matches.

Detection Item Conditions (detection_item_conditions)

Applied per detection item within a rule.

Field Name Conditions (field_name_conditions)

Applied per field name. Use field_name_cond_not: true to negate.

Rule Condition Expression

Override the default AND behavior with rule_cond_expression:

rule_conditions:
  - type: logsource
    product: windows
  - type: tag
    tag: attack.execution
rule_cond_expression: "cond_0 and not cond_1"

Conditions are referenced as cond_0, cond_1, ... by index. Supports and, or, not, and parentheses.

---

Common Pipeline Patterns

ECS Field Mapping

name: Elastic Common Schema
priority: 10
transformations:
  - type: field_name_mapping
    mapping:
      CommandLine: process.command_line
      Image: process.executable
      ParentImage: process.parent.executable
      User: user.name
      SourceIP: source.ip
      DestinationIP: destination.ip
      DestinationPort: destination.port
    rule_conditions:
      - type: logsource
        product: windows

Conditional Transform with State

name: Stateful Pipeline
transformations:
  - id: windows-mapped
    type: field_name_mapping
    mapping:
      CommandLine: process.command_line
    rule_conditions:
      - type: logsource
        product: windows
  - type: field_name_prefix
    prefix: "winlog."
    rule_conditions:
      - type: processing_item_applied
        processing_item_id: windows-mapped

Drop Unsupported Detection Items

name: Drop Unsupported
transformations:
  - type: drop_detection_item
    field_name_conditions:
      - type: include_fields
        fields:
          - Imphash
          - md5
        match_type: plain

Placeholder Expansion

name: Placeholder Resolution
vars:
  admin_users:
    - Administrator
    - Domain Admins
    - Enterprise Admins
transformations:
  - type: value_placeholders
  - type: wildcard_placeholders

Logsource Rewrite

name: Splunk Logsource
transformations:
  - type: change_logsource
    category: endpoint
    product: splunk
    rule_conditions:
      - type: logsource
        product: windows
        category: process_creation

Custom Attributes

name: Engine Config
transformations:
  - type: set_custom_attribute
    attribute: rsigma.timestamp_field
    value: event.ingested
  - type: set_custom_attribute
    attribute: rsigma.suppress
    value: 5m

---

Finalizers

Finalizers produce final query output. They are parsed from the pipeline YAML but not used in evaluation mode (only relevant for query backends).