Sigma Rule Converter

Convert a validated Sigma rule into a query for the backends supported here, with the conditions that cannot be translated exactly called out rather than silently dropped.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Conversion runs the official pySigma library in your browser. The first conversion downloads the Python runtime and the pinned pySigma packages (about 12 MB, cached by your browser afterwards). Your rule is never sent anywhere.

Sigma rule

Target

Field-mapping pipeline Maps Sigma's field names to your platform's schema. "None" keeps Sigma's names.

The converted query appears here, next to the rule.

The official converter, in your browser

Sigma rules are converted to SIEM queries by pySigma, the Sigma project's own conversion library, and its backend plugins. This page does not re-implement that logic. It runs the real library, compiled to WebAssembly through Pyodide, entirely inside your browser. The packages are pinned, and after loading the page checks that every installed version matches its pin. If one does not, conversion is refused rather than done with an unknown version.

Targets and pipelines

The targets offered are the backends in the pinned packages: Splunk SPL and SPL2; Elasticsearch and OpenSearch Lucene, ES|QL and EQL; and Kusto (KQL) for Microsoft Defender XDR, Microsoft Sentinel and Azure Monitor. Each offers the field-mapping pipelines its package ships. A Windows process-creation rule converted for Elastic without the ecs_windows pipeline keeps Sysmon's field names, which your ECS-based index will not have. The pipeline is what makes the query match your data.

Validated first, and honest about what was lost

Every rule goes through the Sigma Rule Validator before conversion, and a rule with errors is not converted. Anything the backend cannot express is reported as an error from pySigma itself, verbatim, never silently dropped. Examples are a modifier a backend does not support, or a field a pipeline cannot map.

Not production-ready until tested

A converted query is a starting point. Field names, index or table names, data retention, and how your logs are parsed all vary by environment. Run the query against known-good and known-bad data in your own platform, and tune it, before you deploy it as a detection.

Frequently asked questions

What is downloaded, and from where?

The Pyodide runtime from cdn.jsdelivr.net and the pinned pySigma wheels from PyPI. They are code, not your data. Your browser caches them after the first use.

Which versions are used?

pySigma 1.3.3 with backend-splunk 2.1.0, backend-elasticsearch 2.1.0 and backend-kusto 1.0.1, on Pyodide 0.26.4. The installed versions are shown once the converter loads.

My platform is not listed.

Only backends in the pinned packages are offered, so every conversion comes from real, maintained code. Other platforms have their own pySigma backends, which you can run with sigma-cli.

References and licences

pySigma (LGPL-2.1) and backends: Splunk (LGPL-2.1), Elasticsearch (LGPL-3.0), Kusto (LGPL-3.0), loaded unmodified at run time
Pyodide (MPL-2.0)

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.