Sigma Rules Bring Community Detections to Any SIEM

In the previous article I wrote a handful of KQL queries to hunt for a backdoored IDE extension. They work in Microsoft Sentinel and Defender. They are useless in Splunk, Elastic or OpenSearch.

That is the core problem of detection engineering: every SIEM speaks its own language, and detection knowledge gets locked inside whichever product you happen to run. Sigma fixes that.

What Sigma is

Sigma is an open, generic signature format for log events. A Sigma rule is a YAML file that describes what to look for (which log source, which fields, which values) without saying how a specific SIEM should query it. A converter then translates the rule into the target query language.

The common analogy: Sigma is to logs what Snort is to network traffic and YARA is to files.

A rule has a few key sections:

logsource: the kind of event (for example process_creation on windows).
detection: named selections of field/value conditions, plus a condition that combines them.
metadata: title, ID, author, references, ATT&CK tags, false positives and severity level.

Why a community, SIEM-agnostic ruleset is a big deal

Thousands of rules for free. The SigmaHQ repository contains thousands of community-maintained rules mapped to MITRE ATT&CK. When a new technique or campaign appears, a rule often lands there within days.
No vendor lock-in. Your detection logic survives a SIEM migration. Changing from Splunk to Sentinel no longer means rewriting years of work.
Detection as code. Rules are plain text: they live in Git, go through pull requests, get reviewed, tested in CI and deployed automatically.
A shared language. Threat intel reports, vendors and researchers increasingly publish Sigma rules alongside IOCs, so you can consume them directly.
Better for small teams. If you are a team of four, you cannot write every detection from scratch. Reusing and tuning community rules is where the leverage is.

Which SIEMs are supported

Conversion is handled by pySigma and its backend plugins. Available backends include, among others, Microsoft Sentinel and Defender XDR (KQL), Splunk (SPL), Elasticsearch (Lucene, EQL, ES|QL), OpenSearch (Lucene and PPL), IBM QRadar (AQL) and Grafana Loki (LogQL). Run sigma plugin list to see the current list and its status.

Backends are paired with processing pipelines, which map Sigma’s generic field names to the schema your data actually uses (for example Sysmon fields to Defender’s DeviceProcessEvents or to Elastic Common Schema).

Converting rules with sigma-cli

Install the CLI and the backends you need:

pipx install sigma-cli          # or: python3 -m pip install sigma-cli
sigma plugin install kusto      # Microsoft Sentinel / Defender XDR
sigma plugin install opensearch # OpenSearch

Discover what is available:

sigma plugin list
sigma list pipelines kusto
sigma list formats opensearch_lucene

The basic syntax is:

sigma convert -t <backend> -p <pipeline> [-f <format>] [-o <output>] <rule or directory>

The example rule

You do not need to write a rule to get started: the point of Sigma is that someone already has. Take a classic from the SigmaHQ repository, Bypass UAC via Fodhelper.exe, by E.M. Anhaus, Tony Lambert and the oscd.community. fodhelper.exe is an auto-elevated Windows binary that reads a registry key the current user controls, so attackers point that key at their own payload and get it executed with high integrity, without a UAC prompt. Anything spawned by fodhelper.exe deserves a look.

title: Bypass UAC via Fodhelper.exe
id: 7f741dcf-fc22-4759-87b4-9ae8376676a2
status: test
description: Identifies use of Fodhelper.exe to bypass User Account Control. Adversaries use this technique to execute privileged processes.
references:
    - https://eqllib.readthedocs.io/en/latest/analytics/e491ce22-792f-11e9-8f5c-d46d6d62a49e.html
    - https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1548.002/T1548.002.md
author: E.M. Anhaus (originally from Atomic Blue Detections, Tony Lambert), oscd.community
date: 2019-10-24
modified: 2021-11-27
tags:
    - attack.privilege-escalation
    - attack.t1548.002
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\fodhelper.exe'
    condition: selection
falsepositives:
    - Legitimate use of fodhelper.exe utility by legitimate user
level: high

The detection is a single line, which makes it a good example: the interesting part is not the logic but how each backend translates ParentImage into its own schema.

Implementation in Microsoft Sentinel

The kusto backend offers several pipelines. microsoft_xdr targets Defender XDR tables (available in Sentinel through the Defender connector). sentinel_asim targets Sentinel’s normalised ASIM parsers, so the same rule works across data sources.

sigma convert -t kusto -p microsoft_xdr proc_creation_win_uac_bypass_fodhelper.yml

Output:

DeviceProcessEvents
| where InitiatingProcessFolderPath endswith "\\fodhelper.exe"

With the ASIM pipeline:

sigma convert -t kusto -p sentinel_asim proc_creation_win_uac_bypass_fodhelper.yml

imProcessCreate
| where ParentProcessName endswith "\\fodhelper.exe" or ActingProcessName endswith "\\fodhelper.exe"

To deploy it, create a Scheduled analytics rule in Sentinel (Analytics → Create → Scheduled query rule), paste the query, set the frequency and lookback, map entities (host, account, process) and the ATT&CK technique from the Sigma tags. For detection as code, keep the converted query in an ARM or Bicep template in the same repository as the Sigma source and deploy it from your pipeline.

A note on ASIM: many SigmaHQ rules also match on OriginalFileName (the name in the PE header, which survives a renamed binary). In the versions I tested, the sentinel_asim pipeline has no mapping for that field and the conversion fails, while microsoft_xdr handles it. Check before you assume a whole folder of rules converts.

Implementation in OpenSearch

The OpenSearch backend exposes two targets, opensearch_lucene and open_search_ppl, and several output formats, including plain queries, a Dashboards import file and Alerting monitors.

sigma convert -t opensearch_lucene -p ecs_windows --disable-pipeline-check proc_creation_win_uac_bypass_fodhelper.yml

process.parent.executable.caseless:*\\fodhelper.exe

The ecs_windows pipeline maps the rule to Elastic Common Schema field names. In the version I tested it is not flagged as intended for the OpenSearch backend, hence --disable-pipeline-check. If your logs use a different schema, write a small custom pipeline instead.

To get an alert instead of a query, use the monitor_rule format:

sigma convert -t opensearch_lucene -p ecs_windows --disable-pipeline-check -f monitor_rule -o monitor.json proc_creation_win_uac_bypass_fodhelper.yml

This produces a JSON monitor for OpenSearch Alerting (schedule, query, trigger and the Sigma metadata), which you can create through the Alerting API (POST _plugins/_alerting/monitors). Before deploying, adjust the index pattern (the generated monitor uses beats-*), check that fields such as process.parent.executable.caseless exist in your mapping, and add a notification action to the trigger.

Things to watch out for

Pipelines matter more than backends. A conversion that compiles is not a conversion that matches. Always check the output against real data.
Tune before you alert. Community rules are written for the general case. Review the falsepositives field and add exclusions for your environment.
Pin your tool versions. Backends and pipelines evolve; pin sigma-cli and plugin versions in CI so conversions are reproducible.
Test. Keep a few sample events per rule and check in CI that each converted query still fires.

Closing

Sigma turns detections into something you can share, review, version and migrate. For a small team, it means standing on the shoulders of a whole community instead of writing every rule from scratch.

Write it once. Convert it everywhere. Tune it for home.

Conversions in this article were generated with sigma-cli 3.1.0, pySigma-backend-kusto 1.0.1 and pySigma-backend-opensearch 2.0.3.

Sources