Sigma Converter
One Sigma rule to Splunk SPL, Sentinel KQL, Elastic Lucene and SQL.
What each backend can express
| Sigma feature | Splunk SPL | Sentinel KQL | Elastic Lucene | Athena SQL |
|---|---|---|---|---|
| contains, startswith, endswith, wildcards | Yes | Yes | Yes | Yes (LIKE) |
| ? single-character wildcard | Becomes * | Yes (regex) | Yes | Yes (_) |
| |re regular expression | Yes (regex, or rex inside OR and NOT) | Yes (RE2) | Translated; \b and lookarounds refused | Yes |
| |cased | No | Yes (_cs) | Mapping-dependent | Yes |
| |cidr | Yes | Yes | Yes (ip fields) | Yes |
| |fieldref | Top level only | Yes | No | Yes |
| |exists, |neq, null | Yes | Yes (empty and missing are one) | Yes | Yes |
| Keyword (full-text) lists | Yes | Term match (has), narrower | Yes | No |
| Correlation rules (event_count, value_count, temporal) | Yes (bin, stats) | Yes (summarize) | No | Yes (GROUP BY) |
| N of selection (N above 1) | Broadened to OR | Broadened to OR | Broadened to OR | Broadened to OR |
How it compares
Each target is checked two ways: against the expected queries in pySigma's own backend tests, and by converting every SigmaHQ rule and running the query on events generated from the rule, compared with this page's Sigma matcher.
| pySigma test cases | Exact text | Same events or Sigma semantics | Before this pass |
|---|---|---|---|
| Splunk SPL (26) | 18 | 24 (2 need a Splunk field pipeline) | 4 exact, 19 agree, 7 refused |
| Sentinel and Defender KQL (55) | 37 | 55 | 7 exact, 45 agree |
| Elastic Lucene (28) | 25 | 28 | 3 exact, 23 agree, 4 wrong |
| SQL (25, SQLite tests vs Trino) | 0, other dialect | 25 | 21 agree, 2 wrong, 2 refused |
| Splunk correlations (8) | 7 | Exact check only | 0, refused |
| Lucene regex vectors (25 + 17) | 25 translated, 17 refused | Same | 0 |
| Round trip on SigmaHQ | Splunk | KQL | Lucene | SQL |
|---|---|---|---|---|
| Rules checked | 3,700 | 3,659 | 3,749 | 3,659 |
| Query selects the same events | 100% | 100% | 100% | 100% |
| Before this pass | 99.9%, 53 refused | 99.8% | 97.6% | 87.7% |
| Not checked (lossy warning shown) | 66 | 107 keyword | 17 | 107 keyword |
| Feature | pwnsy converter | sigma-cli 4.0 and pySigma 2 | Uncoder IO |
|---|---|---|---|
| Runs in the browser | Yes, no upload | No (Python CLI) | SaaS, server side |
| Targets | 4 (SPL, KQL, Lucene, Trino SQL) | 34 backends | 24 formats |
| Field pipelines | Sentinel CloudTrail, Defender XDR | Many | Per-platform maps |
| Correlation rules | SPL, KQL, SQL | Per backend | Not documented for Sigma |
| Says when a query is broader or narrower | Yes | Raises on unsupported | No |
Known limits
- Equivalence uses small evaluators of each query language written for this test, so it covers the syntax both tools emit.
- pySigma's SQLite tests compare case-sensitively. This page's SQL lowercases both sides, as Sigma requires, and those 12 cases count as Sigma semantics.
- KQL keyword lists use has, which matches whole terms, so they are narrower than Sigma.
- Lucene regex refuses word boundaries, lookarounds and backreferences. SPL ? wildcards become *.
Sigma converter FAQ
How does this compare with pySigma and sigma-cli?
pySigma is the reference converter, with many backends and processing pipelines. This page covers four targets in the browser and is measured against pySigma's own backend tests: on 134 cases, 132 queries select the same events as pySigma's expected query, or follow Sigma's semantics where that query does not. The other 2 depend on a Splunk pipeline that renames fields. For CI, use sigma-cli with the pipeline for your field names.
Are field names mapped?
For Microsoft Sentinel, CloudTrail fields map to the AWSCloudTrail table. Windows process creation, image load, file, registry and network rules map to the Defender XDR tables with the column names of pySigma's microsoft_xdr pipeline, including its value fixes: Hashes split into MD5, SHA1 and SHA256, registry hive names written out, DOMAIN\user split into two columns. Other sources keep the rule's field names, and the output says so. SPL, Lucene and SQL keep the rule's field names.
Why is a backend marked as unable to convert?
Some Sigma features have no equivalent. Lucene cannot compare two fields or count events, Lucene regex has no word boundaries or lookarounds, and SQL has no full-text keyword search. The page refuses rather than writing a query that means something different, and it warns when a query is broader or narrower than the rule.
Is case sensitivity preserved?
Sigma matches case-insensitively by default. KQL uses =~, contains and in~, SQL lowercases both sides, and SPL search is case-insensitive already. Elastic keyword fields are case-sensitive unless the index normalises them, so the Lucene output carries a note.
Can I test the rule before I convert it?
Yes. The Test tab runs the rule against sample or pasted JSON logs and scores caught attacks and false positives, and the Lint tab lists rule errors and applies safe fixes. All three tabs share one editor, so the rule you test is the rule you convert.
Conversions follow the default query shape of the pySigma backends for each target. The only processing pipelines are the Sentinel AWSCloudTrail map and the Defender XDR maps. Check the output against your own schema before you schedule it. SigmaHQ rules are fetched live under the Detection Rule License 1.1.