KQL

Sigma to Elastic

Paste a Sigma rule, get KQL for Elastic Security and Kibana. Free, no sign-up, with the ECS field mapping shown.

certutil

title: Base64 Encoding Via Built-In Windows Utility
id: 7c1e0a34-2b5f-4d18-9a63-0c8b1f4e5a71
status: experimental
description: |
    A sample rule for the huntrule.com converter. Detects a built-in utility being asked to
    base64-encode a file, which is a common way to stage data before moving it off a host.
    It exercises the `windash` modifier, where one flag has to be matched in both its dash
    and slash spellings.
author: HuntRule Team
date: 2026-08-01
tags:
    - attack.collection
    - attack.t1560.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\certutil.exe'
        - OriginalFileName: 'CertUtil.exe'
    selection_cli:
        CommandLine|contains|windash: '-encode'
    condition: all of selection_*
falsepositives:
    - Administrative scripts that legitimately encode files
level: medium
license: DRL-1.1

28 lines · 906 B

Elastic Security

1 caveat

event.category: process and event.type: start and ((process.executable: *\\certutil.exe or process.pe.original_file_name: CertUtil.exe) and (process.command_line: *-encode* or process.command_line: */encode* or process.command_line: *–encode* or process.command_line: *—encode* or process.command_line: *―encode*))

logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security*, winlogbeat-* — An Elastic query carries no index: the scope lives on the detection rule object, in 'index: []' or 'data_view_id'. Set index to the patterns your deployment ships this log source to — conventionally logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security*, winlogbeat-* — and set language to 'kuery' with type 'query'.

1 line · 320 B2/2 conditions

Verify this query against your own telemetry before deploying it — a converted rule is a starting point, not a tuned detection.

Conversion reportwindows / process_creation → Elastic Security3 fields mapped · 1 construct unsupportedDegraded

Converted to Elastic Security KQL with 1 note.

Profile

Matched on product + category

Field map

Sigma field	Target field	Source
CommandLine	process.command_line	github.com
Image	process.executable	github.com
OriginalFileName	process.pe.original_file_name	github.com

Unsupported constructs

DroppedCase sensitivity narrowed
CASE_SEMANTICS
Case sensitivity on Elastic is a property of the field mapping, not of the query language. ECS types these fields as 'keyword' or 'wildcard', which match byte-exactly including case, and neither KQL nor Lucene has an operator that changes it — so a Sigma rule's conventional case-insensitivity is not preserved and a value whose case differs from the logged one will not match. Sigma's '|cased' modifier, by contrast, is honoured exactly.
Narrowed to a case-SENSITIVE match: this target compares byte-exactly and the rule asked for insensitive, so a value whose case differs from the logged one will not match.

Coverage

selection_img — expressed
selection_cli — expressed

2 / 2 conditions expressed

Worked examples on Elastic Security

Real published rules run through the same engine as the tool above — including the ones it cannot take whole.

Base64 Encoding Via Built-In Windows Utilitywindows / process_creationDegraded

Sigma

title: Base64 Encoding Via Built-In Windows Utility
id: 7c1e0a34-2b5f-4d18-9a63-0c8b1f4e5a71
status: experimental
description: |
    A sample rule for the huntrule.com converter. Detects a built-in utility being asked to
    base64-encode a file, which is a common way to stage data before moving it off a host.
    It exercises the `windash` modifier, where one flag has to be matched in both its dash
    and slash spellings.
author: HuntRule Team
date: 2026-08-01
tags:
    - attack.collection
    - attack.t1560.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\certutil.exe'
        - OriginalFileName: 'CertUtil.exe'
    selection_cli:
        CommandLine|contains|windash: '-encode'
    condition: all of selection_*
falsepositives:
    - Administrative scripts that legitimately encode files
level: medium
license: DRL-1.1

Elastic Security · KQL

event.category: process and event.type: start and ((process.executable: *\\certutil.exe or process.pe.original_file_name: CertUtil.exe) and (process.command_line: *-encode* or process.command_line: */encode* or process.command_line: *–encode* or process.command_line: *—encode* or process.command_line: *―encode*))

Converted to Elastic Security KQL with 1 note. 2/2 conditions

PowerShell Download Cradle On The Command Linewindows / process_creationDegraded

Sigma

title: PowerShell Download Cradle On The Command Line
id: 1f9d4c02-6a77-4e5b-8c31-2d0af7b96e48
status: experimental
description: |
    A sample rule for the huntrule.com converter. Detects the download-and-run pattern where a
    remote payload is fetched and executed in one command. It exercises a value list under a
    single field, which every backend has to expand into its own OR form.
author: HuntRule Team
date: 2026-08-01
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_fetch:
        CommandLine|contains:
            - '.DownloadString('
            - '.DownloadFile('
            - 'Invoke-WebRequest '
            - 'Invoke-RestMethod '
    selection_run:
        CommandLine|contains:
            - '| IEX'
            - 'IEX ('
            - 'Invoke-Expression'
    condition: all of selection_*
falsepositives:
    - Installers and package managers that fetch and run their own payloads
level: high
license: DRL-1.1

Elastic Security · KQL

event.category: process and event.type: start and ((process.command_line: *.DownloadString\(* or process.command_line: *.DownloadFile\(* or process.command_line: *Invoke-WebRequest\ * or process.command_line: *Invoke-RestMethod\ *) and (process.command_line: *|\ IEX* or process.command_line: *IEX\ \(* or process.command_line: *Invoke-Expression*))

Converted to Elastic Security KQL with 1 note. 2/2 conditions

Registry Import With A Suspicious Pathwindows / process_creationFailed

Sigma

title: Registry Import With A Suspicious Path
id: 5b3a8e91-4c26-4f70-b1d8-6e97c30a2f5d
status: experimental
description: |
    A sample rule for the huntrule.com converter. Detects a registry import whose argument does
    not look like an ordinary file path. It exercises a regular expression alongside a `not`
    filter, so the report has both a regex to check against the target's engine and a negated
    branch to place.
author: HuntRule Team
date: 2026-08-01
tags:
    - attack.defense-evasion
    - attack.t1112
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\regedit.exe'
        - OriginalFileName: 'REGEDIT.EXE'
    selection_cli:
        CommandLine|contains: '.reg'
        CommandLine|re: ':[^ \\]'
    filter_flags:
        CommandLine|contains|windash:
            - ' -e '
            - ' -a '
    condition: all of selection_* and not filter_flags
falsepositives:
    - Scripted registry maintenance
level: high
license: DRL-1.1

Elastic Security · KQL

Could not convert to Elastic Security: elastic_kql cannot write 'regex' in expression position: KQL has no regular-expression operator at all — Elastic's own docs say 'KQL does not support regular expressions' and name Lucene as the language required for the /.../ syntax. Convert this rule to Elastic Lucene instead.

File Copy Through The Print Utilitywindows / process_creationDegraded

Sigma

title: File Copy Through The Print Utility
id: 3e6c17b8-9f40-4a2d-85e1-7b4d0c9a6f23
status: experimental
description: |
    A sample rule for the huntrule.com converter. Detects the print utility being used to copy an
    executable rather than to print. It exercises `startswith` together with `contains|all`, where
    several substrings must all appear in one field.
author: HuntRule Team
date: 2026-08-01
tags:
    - attack.defense-evasion
    - attack.t1218
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\print.exe'
        CommandLine|startswith: 'print'
        CommandLine|contains|all:
            - '/D'
            - '.exe'
    filter_self:
        CommandLine|contains: 'print.exe'
    condition: selection and not filter_self
falsepositives:
    - Printing a file whose name ends in .exe
level: medium
license: DRL-1.1

Elastic Security · KQL

event.category: process and event.type: start and (process.executable: *\\print.exe and process.command_line: print* and process.command_line: */D* and process.command_line: *.exe* and (not process.command_line: *print.exe*))

Converted to Elastic Security KQL with 1 note. 2/2 conditions

What to know about Elastic Security KQL

KQL — Kibana Query Language, which shares an acronym with Microsoft's Kusto and nothing else — is the language Kibana defaults to and the one almost every Elastic detection rule is written in. It maps onto Sigma comfortably: `field: value`, wildcards inside terms, `and` / `or` / `not`, and quoted phrases where a value contains spaces. Most Sigma rules come out as something an Elastic analyst would have typed by hand.

One thing it cannot do at all is regular expressions. There is no regex operator in KQL, in any version, and a Sigma rule using the `|re` modifier has no KQL translation — so this converter refuses it rather than approximating with a wildcard that would match a different set of events. When that happens, use the Lucene page instead: Lucene is Elastic's documented escape hatch for exactly this, and it is why both languages are offered rather than one.

The field mapping targets ECS, and the single most common error in hand-written Sigma-to-Elastic translation is appending `.keyword` to an ECS field name. ECS keyword fields are already keyword-typed; the multi-fields that exist go the other way, adding a `.text` analysed variant on top of a keyword parent. Appending `.keyword` to `process.name` does not make the match exact, it names a field that is not there, and the clause silently matches nothing. This converter never appends it, and the field map shows you every name it did use.

Elastic Security KQL reference →

How it works

Step 1
Paste the rule
Drop a Sigma rule into the left pane, or open a .yml file. The tool says what it thinks you pasted before anything is sent.
Step 2
Pick your SIEM
Choose the target dialect. Every shipped target is free and none of them are behind a sign-up.
Step 3
Read the report
The query comes back with the log-source profile that was used, every field it renamed, and anything the target could not express.
Step 4
Verify, then deploy
Run it against your own telemetry in audit mode before it alerts on anything.

Questions

Paste the Sigma rule into the tool on this page and press Convert. It returns KQL for Elastic Security, the log-source profile it matched, the field map it applied, and anything Elastic Security cannot express. Free, no sign-up.

No. KQL has no regex operator in any version, so a Sigma rule using the |re modifier cannot be expressed in it and this converter refuses instead of approximating. Use the Lucene page for those rules — that is what Lucene is there for.

No, and doing so is the most common way a hand-written Sigma-to-Elastic query silently matches nothing. ECS keyword fields are already keyword-typed; the multi-fields that exist add a .text variant, not a .keyword one. The converter never appends it.

It will run if your field names match the profile shown in the report. Whether it matches the right events depends on your own telemetry, so verify it before deploying. The coverage figure tells you how much of the rule made it into the query.

The other pair

The same tool, with a different target preselected.

Every rule in the detection catalog is written in Sigma, so any of them converts to Elastic Security here.