SIEM Detection Gaps?
Our SOC engineers build custom detection rules and tune your SIEM for maximum visibility.
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.
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).
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.
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.
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.
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".
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.
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.
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.
ℹ️ 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.