SIEM Query Builder

Free SIEM Query Builder for Splunk SPL, Elastic KQL and Microsoft Sentinel

This SIEM query builder writes the same detection three times — once in Splunk SPL, once in Elastic KQL, and once in Microsoft Sentinel KQL — from a single set of filter conditions. Pick a field, an operator and a value, choose how to group the results, and the tool emits a syntactically correct query for each platform side by side. Everything runs in your browser: no log data is uploaded, no credentials are needed, and nothing is stored.

It exists because detection engineers rarely get to stay on one platform. A rule written for a Splunk deployment has to be re-expressed when the SOC migrates to Sentinel, when a managed service provider onboards a client running Elastic, or when a threat-intel report publishes a detection in a syntax nobody on the team uses daily. The hard part is almost never the logic — it is remembering that a username is user in Splunk, user.name in Elastic Common Schema, and AccountName in the Sentinel SecurityEvent table. This tool holds that mapping so you do not have to.

What the Tool Does

There are two tabs:

• Builder — construct a detection from filter conditions joined with AND/OR, set a data source and time range, add group-by fields and a result limit, then read the generated SPL, KQL and Sentinel query. Roughly thirty pre-built detections are included, organised into six categories: Authentication, Network, Malware & Execution, Data Exfiltration, Cloud Security and Endpoint. Most presets carry a MITRE ATT&CK technique ID (T1110 for brute force, T1059.001 for encoded PowerShell, T1003.001 for LSASS credential dumping, T1071.004 for DNS tunnelling, and so on) so you can map coverage back to the framework.
• Reference — a per-platform syntax cheat sheet listing operators, common pipeline functions and a complete worked example for each of the three query languages.

Fifteen normalised fields are supported — user, source IP, destination IP, Windows event ID, process name, command line, host, action, status, port, domain, URL, file path, SHA-256 hash and parent process — each with its platform-specific field name already mapped.

How to Use the SIEM Query Builder

1. Open the Builder tab and either start from a preset detection or add your first filter condition manually.
2. Choose a field from the normalised list, pick an operator (equals, not equals, contains, starts with, ends with, greater than, less than, in list, regex) and type a value.
3. Add further conditions and set each one’s connector to AND or OR.
4. Set the data source. In Splunk this becomes the index= and sourcetype= prefix; in Sentinel it becomes the table name the query starts from.
5. Add group-by fields if you want an aggregation — grouping by source IP and user turns a raw event search into a brute-force detection.
6. Set a result limit and a time range, then copy the query for whichever platform you are working in.

The generated query is a starting point, not a finished production rule. Always run it against a bounded time window first, confirm the field names match your own ingestion pipeline, and tune the threshold before you attach an alert to it.

The Same Detection in Three Languages

Take the most common detection in any SOC: repeated failed Windows logons from a single source address, which maps to MITRE ATT&CK T1110 (Brute Force). Windows writes event ID 4625 on every failed logon. Here is that detection expressed three ways.

Splunk SPL. SPL starts with a bare search and pipes results through transforming commands:

index=security sourcetype=WinEventLog:Security EventCode=4625
| stats count by src_ip, user
| where count > 5
| sort - count
| head 20

Microsoft Sentinel (KQL). Sentinel KQL always starts from a table name, and every filter is an explicit where operator. Aggregation uses summarize rather than stats:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by IpAddress, AccountName
| where FailedAttempts > 5
| order by FailedAttempts desc
| take 20

Elastic KQL. Elastic’s Kibana Query Language is a filter language, not a pipeline language. It expresses the match but not the aggregation — in Kibana you add the group-by through a visualisation or an aggregation clause rather than in the query string:

event.code: "4625" AND event.outcome: "failure" AND source.ip: 10.0.0.*

That last point is the single most important difference between the three, and it catches people out constantly. Splunk SPL and Sentinel KQL are both pipeline languages: you can filter, aggregate, sort and limit in one expression. Elastic KQL only filters. If a detection needs a threshold (“more than five failures in ten minutes”), Elastic expresses that in the rule definition or in an Elasticsearch aggregation, not in the KQL string itself.

Field Name Translation

The second thing that breaks ported detections is field naming. Elastic standardises on the Elastic Common Schema (ECS), which uses dotted, lower-case, namespaced names. Sentinel uses table-specific PascalCase column names. Splunk uses whatever the Common Information Model or your own props/transforms produced, which in practice is short snake_case. A representative slice of the mapping this tool applies:

Operators differ too. Equality is = in SPL, : in Elastic KQL and == in Sentinel KQL. Substring matching is a wildcard on both sides in SPL and Elastic (field="*value*") but a dedicated contains operator in Sentinel. List membership is IN (…) in SPL, in (…) in Sentinel, and an OR-joined group in Elastic.

A Second Worked Example: Encoded PowerShell

Base64-encoded PowerShell (T1059.001) is a durable, high-signal detection. The logic is “process is powershell.exe and the command line contains -enc”. Note how differently each language expresses the substring match:

Splunk:   index=* process="powershell.exe" AND CommandLine="*-enc*"
Elastic:  process.name: "powershell.exe" AND process.command_line: *-enc*
Sentinel: SecurityEvent
          | where ProcessName == "powershell.exe"
          | where CommandLine contains "-enc"

Tune this one before deploying it. PowerShell accepts abbreviations of -EncodedCommand down to -e, so a determined attacker will use -ec or -EncodedComm; a production version of this rule usually matches a regex over the argument prefix instead of a fixed string. That is exactly the kind of refinement the builder is meant to hand off to you rather than pretend to solve.

Related Tools

Once a detection fires you usually need to enrich it. The DNS lookup tool resolves a suspicious domain and shows its records, the WHOIS lookup gives registration age and registrar, and the hash generator produces the SHA-256 values you will paste into an IOC filter. If you are parsing raw web-server logs before they reach the SIEM, the Nginx log pattern reference covers the field extraction side.

Frequently Asked Questions

Which query languages does this SIEM query builder support?

Three: Splunk SPL, Elastic KQL (Kibana Query Language) and Microsoft Sentinel KQL (Kusto Query Language). Every query you build is emitted in all three simultaneously so you can compare them directly.

Is Elastic KQL the same as Sentinel KQL?

No, despite the shared acronym. Elastic’s KQL is Kibana Query Language, a filter-only syntax for matching documents. Microsoft’s KQL is Kusto Query Language, a full pipeline analytics language with where, summarize, project, join and dozens of other operators. They share almost nothing except the letters.

Does the tool connect to my SIEM?

It does not. It generates query text that you copy into your own console. No API keys, no connectors, and no log data ever leaves your browser — which also means you can use it from a workstation that has no network path to the SIEM.

Are the generated queries production-ready?

Treat them as a well-formed first draft. The syntax is correct and the field mappings reflect the standard schemas, but every environment has its own index names, sourcetypes, custom parsers and normalisation. Run the query over a short time window, verify it returns what you expect, then set thresholds based on your own baseline before alerting on it.

What is MITRE ATT&CK and why are technique IDs shown?

ATT&CK is a public catalogue of adversary techniques observed in real intrusions, each with a stable ID such as T1110 (Brute Force) or T1047 (Windows Management Instrumentation). Tagging detections with technique IDs lets you measure coverage — which techniques you can currently see and which you cannot — rather than just counting rules.

Why does my query return nothing when the syntax is correct?

Almost always a field-name or index mismatch. Start by removing every filter and searching the raw index or table for a single event, then confirm the actual field names present on that event and add filters back one at a time. Wrong index, wrong sourcetype, a time range that predates ingestion, and a field that your parser never extracted are the four usual causes.

Can I use these queries for Elastic Security detection rules?

The KQL output works as the query portion of a custom Elastic detection rule. Threshold logic, however, belongs in the rule configuration rather than the query string, so for a “more than N events” detection you set the rule type to Threshold and configure the field and count there.

Does Sentinel charge for running these queries?

Microsoft Sentinel bills primarily on data ingestion and retention rather than per query, but long lookback windows over large tables consume resources and can be slow. Constrain the time range and project only the columns you need — that is good practice for cost and for query performance in every SIEM.

How do I handle a field my SIEM names differently?

Build the query with the closest normalised field, copy the output, and rename the field in your editor. The value of the tool is the structure and the operator syntax; a single find-and-replace on a field name is a much smaller job than reconstructing a pipeline from scratch.

Is any of this data logged?

No. The builder is entirely client-side JavaScript. Filter values you type — including internal hostnames, usernames or IP addresses — stay in the browser tab and are never transmitted.