# KQL threat hunting queries: a library of ready made detection content for Sentinel and Defender XDR

> This repository collects Kusto Query Language queries for threat hunting and detection in Microsoft Sentinel and Microsoft Defender XDR, organised by data source and by defender product, with a training section that teaches the language through a few operators and a hunt template. The author announced a heavy rebuild of the repository to fit the current community landscape.

**cyb3rmik3/KQL-threat-hunting-queries** — A repository of KQL queries focused on threat hunting and threat detecting for Microsoft Sentinel & Microsoft XDR (Former Microsoft 365 Defender).

- Repository: https://github.com/cyb3rmik3/KQL-threat-hunting-queries
- Stars: 800 · Forks: 97
- Language: Unknown
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/cyb3rmik3-kql-threat-hunting-queries

## What the repository actually holds

The repository is an effort to provide ready made detection and hunting queries, and more, so that analysts and threat hunters can use the power of KQL in Microsoft Sentinel and Microsoft Defender XDR. The README describes it as an effort rather than a product, and it is a collection of content rather than a tool.

The directory layout is organised by workflow and by data source. There is 01.ThreatHunting, 02.ThreatDetection and 03.SecOps, which are the phases of an analyst's work, and then product directories for the data sources: Azure, Defender For Endpoint, Defender for Office365, Sentinel, Syslog-CEF and TIFCE. There are also EASM, MDVM and XSPM directories, and the Syslog-CEF and TIFCE directories holding the log formats that a Microsoft SIEM ingests from other tools.

A Learning directory and a threat-hunting-template.md file sit alongside. The template is the most useful single file for a new contributor, since a template that says what a hunt should contain makes the difference between a query collection and a body of reusable hunting knowledge.

The project is MIT licensed, the default branch is main, and the last push was on 2026-10-22. There are no GitHub releases, and the topics list covers the Microsoft security product names alongside the Kusto and KQL vocabulary.

## The rebuild notice and what it implies for the content

The README opens its body with a dated note. On Jan. 27th, after almost a year of contributions, the repository is undergoing a heavy rebuild to meet what the community now needs and to give far more contextualisation, in order to keep contributing.

That sentence does a lot of work and is worth reading closely. It says the previous state of the repository was accumulated over almost a year of contributions, which is what you would expect from a collection that grows one query at a time. And it says the rebuild is about contextualisation, not only about tidying.

The reason this matters for someone deciding whether to use the content is that a query without context is a liability. A detection query that fires on a suspicious pattern is only useful if the analyst knows what normal looks like in that environment, what the table contains, and which of its fields are reliable. A rebuild aimed at adding contextualisation is a response to exactly that gap.

It also means the content is in motion. A collection that is being restructured while you are reading it will have changed paths, and any automation that references a specific file will break. For an evaluation, that argues for reading the current structure rather than assuming a query you saw referenced elsewhere still sits at the same path.

## The KQL primer, four operators at a time

The KQL Basics section is a short tutorial built on the DeviceNetworkEvents table from the advanced hunting schema, which contains information about network connections and related events. Four operators are enough to show the shape of the language.

The first is where, which filters on a specific predicate:

```
DeviceNetworkEvents
| where LocalIP == "192.168.0.1"
```

The second pair is contains and has. Contains looks for any substring match, and has looks for a specific word with better performance. The distinction is the one that matters when a query runs across a large table, since has can use the index and contains cannot:

```
DeviceNetworkEvents
| where DeviceName has "ComputerName"
```

The third is ago, which returns the time offset relative to the time the query executes:

```
DeviceNetworkEvents
| where Timestamp > ago(1d)
```

And the fourth is project, which selects the columns to include in the order specified. The tutorial builds them up in sequence, and the combined form is where the shape of a hunting query becomes clear:

```
DeviceNetworkEvents
| where Timestamp > ago(1d)
| where DeviceName has "ComputerName"
| project Timestamp, ActionType, RemoteIP, RemotePort, RemoteUrl
```

Two details are worth carrying forward. The data is organised into a hierarchy of databases, tables and columns, similar to SQL, and the time filter comes first in practice, which is a habit rather than a requirement but one that pays off on a busy table.

## The training resources the repository points at

The KQL Training section is a list of external resources, and it is the most useful part of the README for anyone who is not already fluent in KQL.

The first entry is Microsoft's own Certified Security Operations Analyst course, exam code SC-200, and the description says that if Sentinel and Microsoft 365 Defender are your daily tools you should consider it. Two specific learning paths are linked from it, one on using KQL for Azure Sentinel and one on configuring the Azure Sentinel environment.

The second is the Defender XDR advanced hunting expert training, which the README describes as a comprehensive guide for security analysts and threat hunters, delivered through a series of webcasts titled Tracking the Adversary and L33TSP3AK.

The third is hands-on KQL training from Mehmet Ergene, known as cyb3rmonk, who runs the blu raven academy and offers an introduction to KQL for security analysis that is free, alongside paid courses on threat hunting and detection engineering in a hyper-realistic lab environment.

The fourth is Rod Trent's MustLearnKQL series, a set of blog posts and videos about the power and simplicity of the language, and the fifth is a pair of hands-on platforms: KC7 Cyber and the Kusto Detective Agency, both of which are described as ways to learn the language through challenges.

The sixth is Invictus's incident response in the Microsoft Cloud training, which covers incident response in Azure and Microsoft 365, including KQL basics, query packs and more advanced use cases and queries for cloud attacks.

## How the hunting method is framed

The Threat Hunting Basics section starts from Microsoft's own framing, and it is the part of the README that explains the discipline rather than the syntax.

Threat hunting should be a continual process, and the cycle starts at the top with the hypothesis. The hypothesis helps plan what you are going to hunt for, which requires understanding where you are going to hunt and how you will do it, which in turn means understanding the data you have, the tools you have, the expertise you have, and how to work with them.

The point the section emphasises is that the cycle does not stop when you execute the hunt. There are still several phases to conduct throughout the lifecycle, including responding to anomalies, and even if you do not find an active threat there will be activities to perform.

That is the argument for the MITRE ATT&CK approach that follows, which is described as having two components. In practice, for someone reading this repository, the practical effect is that a query is the end of a phase rather than the whole of a hunt. A detection query in 02.ThreatDetection and a hunting query in 01.ThreatHunting serve different purposes, and the directory split reflects that distinction.

The repository also links the training path on performing threat hunting in Azure Sentinel, which is where the same cycle is described in more detail.

## Where this collection is the wrong choice

The first limitation is the platform, which is not a limitation so much as a filter. The queries are written against Microsoft table names in the Sentinel and Defender XDR schemas, and a query against DeviceNetworkEvents or a Defender for Office365 table is meaningless in a Splunk, Elastic or OpenSearch environment. A team not on the Microsoft security stack gets nothing from it except ideas.

The second is the data prerequisite. Even on Microsoft products, a query is only as good as the telemetry behind it. If the Defender for Endpoint connector is not deployed, the endpoint tables are empty and the queries return nothing. If syslog is not being shipped in CEF format, the Syslog-CEF directory has no data to read. This is the most common reason a community detection query appears broken, and it is worth checking before concluding a query is wrong.

The third is the nature of a community collection. The README asks readers to read the disclaimer, and it asks contributors to star the repository if they found a useful query. That is the shape of an open collection built from individual contributions, and it has the properties of one: uneven depth, occasional overlap between queries covering the same behaviour, and no guarantee that every query has been validated against production data. The rebuild note is an honest acknowledgement of that, and the same reason it exists, contextualisation, is what a query needs to become a detection rule you can trust.

The comparison with the alternative is not really about this repository versus another collection, since there are many KQL collections and they overlap. The useful comparison is with buying detection content, or with the built-in detection rules that ship with Sentinel and Defender. Those are maintained by the vendor, tested against real telemetry and supported. What a community collection offers is speed and coverage of behaviours the vendor has not shipped a rule for, and the price is that you own the tuning.

## Conclusion

This repository fits a security analyst who wants working KQL to adapt rather than queries to write from scratch, and who is working inside Sentinel or Defender XDR where the advanced hunting schema is already populated. It does not fit a team on a different SIEM, since the queries are written against Microsoft table names, and it does not fit an environment where third party telemetry is absent, since the data the queries read will not be there. Before relying on any query, read the disclaimer the README points at, check which schema the query targets, and treat the collection as a starting point for your own logic rather than a detection set you can deploy unchanged.

## FAQ

### What does the KQL threat hunting queries repository provide?

It is an effort to provide ready made detection and hunting queries, and more, so that analysts and threat hunters can use KQL in Microsoft Sentinel and Microsoft Defender XDR. The content is organised by workflow phase in 01.ThreatHunting, 02.ThreatDetection and 03.SecOps, and by data source in directories for Azure, Defender for Endpoint, Defender for Office365, Sentinel, Syslog-CEF and TIFCE.

### What KQL operators does the repository teach?

The KQL Basics section walks through where, contains and has, ago, and project, all on the DeviceNetworkEvents table from the advanced hunting schema. It notes that has looks for a specific word with better performance than contains, and that the data is organised into databases, tables and columns much like SQL.

### Why are the KQL query collections being reorganised?

A dated note in the README says that on Jan. 27th, after almost a year of contributions, the repository is undergoing a heavy rebuild to meet the current community landscape and to give far more contextualisation, in order to keep contributing. That means paths and organisation may change as you read it.

### How does the repository frame the threat hunting process?

It follows Microsoft's framing that hunting should be continual, starting with a hypothesis that plans what to hunt for and requires understanding the data, the tools and the expertise available. The cycle does not stop at executing the hunt, since there are further phases including responding to anomalies, and there is work to do even when no active threat is found.

### What external KQL training does the repository recommend?

It links Microsoft's SC-200 certified security operations analyst course and its KQL and Sentinel environment learning paths, the Defender XDR advanced hunting expert training webcasts, the blu raven academy courses from Mehmet Ergene including a free introduction to KQL, Rod Trent's MustLearnKQL series, the KC7 Cyber and Kusto Detective Agency hands-on platforms, and the Invictus incident response in the Microsoft Cloud training.

## Sources

- [cyb3rmik3/KQL-threat-hunting-queries on GitHub](https://github.com/cyb3rmik3/KQL-threat-hunting-queries)
- [Issues](https://github.com/cyb3rmik3/KQL-threat-hunting-queries/issues)
- [License: MIT](https://github.com/cyb3rmik3/KQL-threat-hunting-queries/blob/main/LICENSE)
- [README](https://github.com/cyb3rmik3/KQL-threat-hunting-queries/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cyb3rmik3-kql-threat-hunting-queries