Converting Sigma Rules to Microsoft Sentinel (KQL): A Practical Guide

Sigma has become the universal format for writing detection rules. The problem: Microsoft Sentinel and Defender XDR don't understand Sigma YAML. They speak KQL, Kusto Query Language. Between the two, you have to convert. And that conversion is far more subtle than a plain sigma convert.

This guide explains how to do it cleanly, what the two possible targets are, and why the choice of pipeline radically changes how many rules end up actually usable.

Sigma is generic, KQL is not

A Sigma rule describes detection logic abstractly: an Image field ending in powershell.exe, a CommandLine containing -enc. Sigma doesn't know which table those fields live in, that's the whole point, being portable across SIEMs.

KQL, on the other hand, queries concrete tables with concrete columns. Image doesn't exist in Sentinel: depending on context, the data is called FolderPath, ProcessCommandLine, InitiatingProcessCommandLine, and so on. Converting Sigma to KQL is therefore not about translating syntax, it's about remapping a data model.

pySigma and the Kusto backend

The reference tool is pySigma, the modern rewrite of the old sigmac. Conversion to KQL goes through the pysigma-backend-kusto backend (KustoBackend).

pip install pysigma pysigma-backend-kusto
sigma convert -t kusto -p microsoft_xdr rule.yml

The crucial and often-misunderstood part is the -p: the processing pipeline. It applies the field mapping and targets the right table. Without a pipeline, the generated KQL looks for columns that don't exist, and the rule never returns anything.

Two targets: microsoft_xdr vs sentinel_asim

The Kusto backend exposes two pipelines aimed at different schemas:

• microsoft_xdr, targets Defender XDR Advanced Hunting tables: DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, and so on.
• sentinel_asim, targets the ASIM schema (Advanced Security Information Model), Sentinel's normalized layer: imProcessCreate, imNetworkSession, etc.

The trade-off is concrete and worth knowing. The Defender XDR pipeline covers endpoint log fields far better: for process-creation rules, field coverage sits around ~98%, versus ~52% for ASIM. In other words, for endpoint detection (process creation, command line, hash, parent/child tree), you almost always target microsoft_xdr. ASIM shines more on normalized, multi-source network, authentication, and DNS schemas, but drops a good share of the fine-grained endpoint fields Sigma relies on.

Simple rule: endpoint detection → microsoft_xdr. Normalized multi-source correlation → sentinel_asim.

Field mapping, concretely

Take a classic Sigma rule. Its Image and CommandLine fields must become, in DeviceProcessEvents:

• Image → FolderPath
• CommandLine → ProcessCommandLine
• ParentImage → InitiatingProcessFolderPath
• User → AccountName

That's exactly what the microsoft_xdr pipeline does. Without it, sigma convert would produce a query against Image/CommandLine columns absent from the Defender schema, technically valid, functionally dead.

Before / after

A Sigma rule detecting PowerShell launched with an encoded command (-EncodedCommand / -enc), once run through sigma convert -t kusto -p microsoft_xdr, yields KQL of the form:

DeviceProcessEvents
| where FolderPath endswith "\\powershell.exe"
| where ProcessCommandLine has_any ("-enc","-EncodedCommand")

You get the Advanced Hunting table, the remapped columns, and KQL operators (endswith, has_any). That's what a rule ready to drop into a hunting query or an analytics rule looks like.

The pitfalls that cost you hours

Advanced Hunting is not Sentinel Analytics. The DeviceProcessEvents family lives in Defender XDR (Advanced Hunting). A "classic" Sentinel instance ingesting Sysmon via the AMA agent works instead on SecurityEvent, Event, Sysmon… Those are not the same columns. Picking the wrong pipeline for the wrong platform is the number-one mistake. If your Device* tables are exported to a Sentinel workspace connected to Defender, microsoft_xdr is still correct; otherwise, adapt.

KQL operators have a cost. has relies on term indexing and stays fast; contains does a much more expensive substring search; matches regex is the heaviest. pySigma picks the operator based on Sigma semantics, but a rule riddled with mid-string wildcards generates contains/matches regex that can sink a query across thousands of endpoints.

Non-standard Sigma tags break parsing. An exotic modifier, a convoluted condition, or an unsupported backend feature makes pySigma fail with a SigmaFeatureNotSupportedByBackendError. You then have to clean up or adapt the rule.

Correlation rules. Sigma correlation constructs (event counts, temporal chains) don't all translate cleanly to KQL; some require a manual rewrite into summarize / join.

At scale, manual conversion doesn't hold

Converting three rules by hand is an afternoon. Maintaining a base of 3,000+ Sigma rules is another story: every update of the upstream rule repository means reconverting, re-checking the pipeline, retesting columns, controlling operator cost, and catching rules broken by an unsupported modifier. Done by hand, every cycle, it's unsustainable, and that's where detection coverage silently degrades.

That's precisely the problem the ThreatClaw rule feed solves: Sigma rules are delivered already converted to KQL targeting the Defender XDR Advanced Hunting schema, reconverted and re-validated on every update of the corpus. You get ready-to-use KQL instead of a pySigma pipeline to maintain yourself. Details on the detection rules feed.

FAQ

microsoft_xdr or sentinel_asim, which one? For endpoint detection (processes, command line, files, registry), microsoft_xdr: its endpoint field coverage (~98% of process rules) crushes ASIM's (~52%). Keep sentinel_asim for normalized, multi-source network/authentication detections.

Does it work with "classic" Sentinel or only Defender XDR? The microsoft_xdr pipeline targets Advanced Hunting tables (Device*). They are native to Defender XDR and available in a Sentinel workspace connected to Defender. A Sentinel instance ingesting only Sysmon via AMA works on SecurityEvent/Event: that needs a pipeline suited to those tables, not microsoft_xdr.

Why does my converted rule return nothing? Almost always because no -p pipeline was passed: the KQL queries Sigma columns (Image, CommandLine) that don't exist in the target schema. Add the right pipeline and check the field mapping.