SIEM Query Builder

Free SIEM query generator for Splunk SPL, Elastic KQL, and Microsoft Sentinel. Build detection rules with presets for authentication, network, malware hunting. Includes MITRE ATT&CK mappings.

Advertisement

What Is a SIEM Query Builder

A SIEM (Security Information and Event Management) query builder helps security analysts construct search queries for SIEM platforms without memorizing each platform's proprietary query language. SIEM systems ingest, normalize, and correlate security events from across an organization's infrastructure — firewalls, endpoints, servers, cloud services, and applications — enabling threat detection, investigation, and compliance reporting.

Each SIEM platform uses a different query syntax: Splunk uses SPL, Microsoft Sentinel uses KQL, Elastic Security uses EQL/Lucene, and CrowdStrike uses specialized query syntax. This tool translates detection logic into the correct syntax for your platform, accelerating threat hunting and reducing query errors.

SIEM Query Languages Comparison

PlatformQuery LanguageSyntax StyleExample: Failed SSH Logins
SplunkSPL (Search Processing Language)Pipe-basedindex=linux sourcetype=syslog "Failed password" | stats count by src_ip
Microsoft SentinelKQL (Kusto Query Language)Tabular pipeSyslog | where Facility == "auth" and SyslogMessage contains "Failed password" | summarize count() by SrcIP
ElasticEQL / Lucene / ES|QLMultiple optionsevent.action:"ssh_login" AND event.outcome:"failure"
CrowdStrikeEvent SearchField-valueevent_simpleName=UserLogonFailed | stats count by RemoteAddressIP4
IBM QRadarAQL (Ariel Query Language)SQL-likeSELECT sourceip, COUNT(*) FROM events WHERE category='Authentication' AND outcome='Failure' GROUP BY sourceip

Common Use Cases

  • Threat hunting: Build queries to search for indicators of compromise (IOCs), suspicious behaviors, and anomalous patterns across log sources
  • Detection rule development: Create detection rules that trigger alerts when specific attack patterns are observed
  • Incident investigation: Construct queries to pivot on IP addresses, usernames, file hashes, and process names during active investigations
  • Cross-platform standardization: Maintain detection logic in a platform-agnostic format and translate it to whichever SIEM your organization or client uses
  • Compliance reporting: Build queries for audit-required reports: failed login attempts, privilege escalations, data access logs, and configuration changes

Best Practices

  1. Start with the MITRE ATT&CK framework — Map your detection queries to ATT&CK techniques. This ensures coverage across the kill chain and provides a common language for describing what your queries detect.
  2. Normalize field names — Use consistent field naming across queries (source_ip, dest_ip, username) even when underlying platforms use different names. This makes cross-platform translation easier.
  3. Include time boundaries — Always specify time ranges in your queries. Unbounded queries scanning all historical data consume excessive resources and may timeout.
  4. Tune for false positives — Every detection query needs tuning. Start with broad detection, then add exclusions for known-good activity (service accounts, scanners, maintenance windows) based on your environment.
  5. Test queries with known-bad data — Validate that your queries actually detect the intended behavior by testing with recorded attack traffic or red team exercises before deploying to production.
  6. Document detection rationale — For every query, document what it detects, what ATT&CK technique it maps to, expected false positive sources, and recommended response actions.
Advertisement

Frequently Asked Questions

What SIEM platforms does this tool support?+

The builder supports three major platforms: Splunk SPL (Search Processing Language), Elastic KQL (Kibana Query Language), and Microsoft Sentinel KQL (Kusto Query Language). Each platform has different syntax, and the builder handles field mapping and query generation for all three.

What are the detection presets?+

Presets are pre-built filter combinations for common security use cases. Categories include Authentication (failed logins, impossible travel), Network (port scanning, DNS tunneling), Malware (encoded PowerShell, LOLBAS), Data Exfiltration (large transfers, cloud uploads), Cloud (AWS root login, S3 public buckets), and Endpoint (AV disabled, LSASS access).

What is MITRE ATT&CK mapping?+

Each detection preset includes a MITRE ATT&CK technique ID (like T1110 for Brute Force). This maps the detection to the MITRE ATT&CK framework, helping you understand what adversary technique the query is designed to detect. This is useful for coverage mapping and threat modeling.

How does field mapping work between platforms?+

Different SIEM platforms use different field names for the same data. For example, username is "user" in Splunk, "user.name" in Elastic, and "AccountName" in Sentinel. The builder automatically translates fields when you switch platforms, so you can focus on the logic rather than syntax.

Can I translate queries between platforms?+

Yes, but with limitations. The builder translates field names and basic operators between platforms. Complex features like subsearches, lookups, or platform-specific functions may need manual adjustment. Use the generated query as a starting point and review for your specific environment.

What is SPL vs KQL?+

SPL (Search Processing Language) is Splunk's query language, using pipes and commands like "| stats" and "| where". KQL (Kusto Query Language) is used by Microsoft Sentinel and Elastic, with syntax like "| summarize" and "| where". Elastic also supports Lucene syntax, but we focus on KQL for consistency.

How do I use the Group By feature?+

Group By adds aggregation to your query. For example, grouping failed logins by source_ip and user shows you which IPs are targeting which accounts. In Splunk this becomes "| stats count by src_ip, user", in Sentinel it's "| summarize count() by IpAddress, AccountName".

What time ranges are available?+

The tool supports 1 hour, 24 hours, 7 days, and 30 days as preset time ranges. The syntax differs by platform: Splunk uses "earliest=-24h", Sentinel uses "| where TimeGenerated > ago(24h)". You can also leave it blank to search all available data.

Are these queries ready for production use?+

These queries are starting points for detection development. Before deploying to production, you should: 1) Test in your environment, 2) Tune thresholds to reduce false positives, 3) Add additional filters specific to your data, 4) Consider performance impact of broad queries, 5) Document and review with your team.

How do I handle false positives?+

Add exclusion filters for known-good activity. For example, exclude your monitoring systems from failed login alerts, or exclude backup servers from large data transfer alerts. Use the NOT operator or add exclusion conditions to your query. Document exceptions for audit purposes.

This tool is provided for informational and educational purposes only. All processing happens in your browser — no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results.