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.

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.

Home/Tools/Security/SIEM Query Builder

SIEM Query Builder

Build detection queries for Splunk SPL, Elastic KQL, and Microsoft Sentinel. Includes presets for authentication, network, malware, and threat hunting with MITRE ATT&CK mappings.

100% Private - Runs Entirely in Your Browser

No data is sent to any server. All processing happens locally on your device.

Loading SIEM Query Builder...

Loading interactive tool...

JavaScript Required

This interactive tool requires JavaScript to function. Please enable JavaScript in your browser to use the full features.

The tool description and documentation above provide information about this tool's capabilities. For the best experience, please enable JavaScript and refresh the page.

Need Professional Security Testing?

Our penetration testers find vulnerabilities before attackers do. Get a comprehensive security assessment.

Learn About Penetration Testing Explore Risk Assessment

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

Platform	Query Language	Syntax Style	Example: Failed SSH Logins
Splunk	SPL (Search Processing Language)	Pipe-based	`index=linux sourcetype=syslog "Failed password" \| stats count by src_ip`
Microsoft Sentinel	KQL (Kusto Query Language)	Tabular pipe	`Syslog \| where Facility == "auth" and SyslogMessage contains "Failed password" \| summarize count() by SrcIP`
Elastic	EQL / Lucene / ES\|QL	Multiple options	`event.action:"ssh_login" AND event.outcome:"failure"`
CrowdStrike	Event Search	Field-value	`event_simpleName=UserLogonFailed \| stats count by RemoteAddressIP4`
IBM QRadar	AQL (Ariel Query Language)	SQL-like	`SELECT 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

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.
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.
Include time boundaries — Always specify time ranges in your queries. Unbounded queries scanning all historical data consume excessive resources and may timeout.
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.
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.
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.

Frequently Asked Questions

Common questions about the SIEM Query Builder

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.

ℹ️ Disclaimer

This tool is provided for informational and educational purposes only. All processing happens entirely 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. Use at your own discretion.