~/KQL-example-generator KQL visualizer CVE CA simulator ☕ Support me apps ← about me
// microsoft sentinel · defender xdr · 52 hunting queries · mitre att&ck · query builder

KQL Example Generator — ready-to-use Microsoft Sentinel and Defender hunting queries

A library of 52 KQL queries for threat hunting and detection: password spray, MFA fatigue, impossible travel, encoded PowerShell, ransomware shadow-copy deletion, inbox forwarding rules, Azure deletions, ingestion cost and more. Each comes with a MITRE ATT&CK mapping, likely false positives and editable thresholds. Pick a time range, copy, paste into Sentinel or Defender advanced hunting. Or build your own query from a table in the Query builder.

Guide — a working hunting query in five steps

Nothing is sent anywhere: the queries are built in your browser, you paste them into your own workspace.
1Find a query

Pick a category such as Identity or Endpoint, filter on Sentinel or Defender XDR, or search for a technique like T1110 or a word like lsass.

2Set the time range

Choose the period at the top. Optionally type a user, IP, host or hash under Focus on to narrow every query to that entity.

3Tune the thresholds

Change the parameters, such as the minimum number of failures. They become let statements at the top of the query.

4Copy and run

Copy the query or download it as .kql and paste it into Sentinel Logs or Defender advanced hunting. Try on sample data shows what it returns on test tables.

5Build your own

In the Query builder, pick a table, add filters and choose rows, counts or a time chart. Explain step by step opens any query in the KQL Pipeline Visualizer.

What is in the library

DETECTAttacks

Mapped to MITRE ATT&CK.

Identity
spray, MFA fatigue, impossible travel, consent
Endpoint
encoded PowerShell, LSASS, shadow copies
Email
delivered phish, clicks, forwarding rules
AUDITChanges

Who changed what.

Entra ID
role and MFA changes, app secrets
Windows
admin groups, new users, services
Azure
deletions, RBAC, NSG rules
OPERATEHealth & cost

Keep Sentinel in shape.

Cost
ingestion per table and per day
Health
silent agents, open incidents
Servers
CPU and free disk space

KQL hunting queries, explained

KQL (Kusto Query Language) is the language of Microsoft Sentinel, Defender XDR advanced hunting and Azure Monitor. Security teams use it for two jobs: hunting, where an analyst runs a query to look for signs of an attacker, and detection, where the same query runs every few minutes as a scheduled analytics rule and raises an alert when it returns rows. Every query in this library works for both. The examples are written to be read: one step per line, a time filter first, clear column names and a comment header with the MITRE ATT&CK technique.

Sentinel or Defender XDR?

Microsoft Sentinel stores logs in a Log Analytics workspace: Entra ID sign-ins (SigninLogs), audit logs, Windows security events, Azure activity, Office 365 activity and firewall logs. Defender XDR advanced hunting holds the rich endpoint, email and identity tables from the Defender products (DeviceProcessEvents, EmailEvents and more) for 30 days. With the Defender XDR connector those tables also flow into Sentinel. The main difference in syntax is the time column: Timestamp in advanced hunting, TimeGenerated in Sentinel; in Sentinel both exist for the Defender tables.

Tables used in this library

TableContainsSource
SigninLogsInteractive Entra ID sign-insEntra ID diagnostic settings
AuditLogsDirectory changes: roles, apps, MFAEntra ID diagnostic settings
SecurityEventWindows security log (4624, 4625, 4720…)Azure Monitor Agent
DeviceProcessEventsEvery process start on endpointsDefender for Endpoint
DeviceNetworkEventsNetwork connections from endpointsDefender for Endpoint
EmailEvents, UrlClickEventsMail flow and Safe Links clicksDefender for Office 365
OfficeActivityExchange, SharePoint and Teams auditMicrosoft 365 connector
AzureActivityControl-plane operations in AzureAzure Activity connector

From hunting query to analytics rule

When a query proves useful, turn it into a scheduled analytics rule in Sentinel. Set the run frequency and the lookup period to the same value as the ago() in the query (for example every hour, looking back one hour), map the entities (account, IP, host) so incidents correlate, and start with a higher threshold to avoid alert fatigue. In Defender XDR the equivalent is a custom detection rule, which also needs the Timestamp, DeviceId and ReportId columns in the output.

Tuning and false positives

Every detection fires on some legitimate activity. Each query lists its typical false positives. Tune by raising thresholds, by excluding known service accounts and scanners with !in, or by keeping an allow-list in a Sentinel watchlist and filtering with _GetWatchlist('name'). Re-test after every change, and keep the original query so you can see what you are filtering away.

Writing efficient KQL

Filter on time first, then on the most selective column. Prefer has over contains and == over =~ when you can. Use project before a join and put the smaller table on the left. The Focus on field in this tool adds where * has "…", which searches every column: handy for an investigation, but name a column in queries that run as rules.