KQLWizard: a public library of KQL hunting queries and detections

Content, not a tool you install

KQLWizard is a repository of KQL queries and threat hunting detections for Microsoft Defender and Microsoft Sentinel. The README states the purpose plainly: to share KQL queries and threat hunting detections that anyone can use to strengthen their defenses, designed to expand detection coverage across Microsoft Security product logs and uncover activities that may not trigger alerts by default.

That last clause is the one to hold on to. These are hunting queries, not alerts. A hunting query is something an analyst runs deliberately against a table, while a detection rule is something the platform evaluates continuously. The repository contains both, which the README lists as Detection Rules, Hunting Queries and Visualizations, all freely available for defenders to adopt or adapt.

The user is therefore an analyst with a populated workspace. There is no install step, no package to add and no configuration file. The unit of value is a query text file that you paste into the Defender XDR hunting pane or a Sentinel workspace, test against your own data, and keep only if it earns its place.

The JavaScript entry in the repository topics and a Javascript/ directory at the top level indicate that some of the content is tooling rather than KQL, most likely the visualisations, which are typically shipped as HTML and JavaScript files to load into a Defender or Sentinel dashboard. The repository does not describe them in the README, so the folder itself is the evidence.

A LinkedIn profile is given as the homepage, and the README invites direct questions to the author, Steven Lim. For content that people will paste into their own tenant, having a named author to ask is worth more than an anonymous dump would be.

The directory layout maps to data sources

The top level entries are ADX/, Azure/, DefenderXDR/, IOC/, Javascript/, Sentinel/, plus BingSiteAuth.xml, CNAME, LICENSE, README.md and googlecde3b712e80c0223.html.

The folder names are the organising idea, and they map directly onto where the data lives. DefenderXDR/ holds queries against the Defender XDR advanced hunting tables, Sentinel/ holds queries for Sentinel workspaces, Azure/ holds queries against Azure resource and activity logs, and ADX/ points at Azure Data Explorer. The README links three of these directories directly as Azure KQLs, DefenderXDR KQLs and Sentinel KQLs.

The folders you will browse are exactly these:

ADX/
Azure/
DefenderXDR/
IOC/
Javascript/
Sentinel/

That structure is more useful than it first appears. A query written for a Defender XDR table will fail in a Sentinel workspace unless the equivalent table is present there, and the table names differ between products, so a query written for one often needs field and table renaming for another. Separating the content by product tells you where a query is expected to run, and by extension tells you which of your tenants it can be copied into without editing.

IOC/ is the exception, and it is the one folder whose purpose is obvious from the name alone. An indicators of compromise collection is usually a set of hashes, domains and addresses, which is a different shape of artefact from a query: it feeds a watchlist or a join in another query rather than being pasted into a hunting pane.

The consequence for an adopter is straightforward. Before you copy anything, you need to know which of your workspaces ingests which tables, and the directory names give you the vocabulary to ask that question of your own environment.

Queries as detection engineering starting points

The README describes the intent as helping uncover activities that may not trigger alerts by default, by leveraging logs so that otherwise hidden behaviours can be surfaced and investigated. That is the job of a detection engineer, and the repository is best read as a set of starting points for that work.

The gap between a query and a deployed detection is where most of the work lives. A hunting query returns rows; it does not decide what a row means. To become a detection rule in Defender XDR or a Sentinel analytic rule, the query has to be given a schedule, a severity, an entity mapping so the alert lands on the right host or user, an entity mapping for the investigation graph, a suppression rule for noise, and a response playbook. None of that is described here, and the repository contains no YAML or ARM template at the top level that would automate it.

That is not a criticism so much as a scope statement. Detection content without tuning is a starting point, and content that arrives without entity mapping will produce alerts that nobody can action.

The visualisations deserve a separate note. A Visualization in the Microsoft Security ecosystem is a workbook or an HTML file that can be loaded into a Defender XDR dashboard to visualise data from a query. They are the fastest way to give a hunting team a shared picture of what is in the logs, and they also happen to be the easiest artefacts to copy verbatim into a workspace without any change.

BSD-3-Clause, plus an attribution request in the README

The licence field on the repository says BSD-3-Clause, and the LICENSE file sits at the top level. For detection content that is a good fit: the permissive terms let you copy a query into a production analytic rule, modify it for your environment, and keep the modification private, with the usual obligation to retain the copyright notice and disclaimer.

The README adds a term that the licence itself does not contain. It states that presenting this material as your own is illegal and forbidden, and that a reference to LinkedIn @0x534c or GitHub @SLimKQL is much appreciated when sharing or using the content.

Read carefully, that is a request rather than a licence condition. The BSD-3-Clause grant does not require attribution in your internal deployment, and nobody can make presenting it as your own illegal by asking nicely. What it does mean is that the author expects attribution in shared material, and that the phrasing is a boundary the author has drawn.

The practical advice is simple and costs nothing: when you take a query into a shared detection library, a conference talk, or a published report, credit the source. It satisfies the author's stated wish, it does not create a compliance problem, and it is the behaviour that keeps this kind of community repository producing.

A published site alongside the repository

Three files at the top level describe how the content is served. CNAME is the file GitHub Pages uses to point a custom domain at a repository, googlecde3b712e80c0223.html is a Google site verification file that proves ownership of a domain, and BingSiteAuth.xml is the equivalent for Bing. Together they say that this repository is published as a website, indexed by search engines, under a domain the author controls.

That is a small detail with a large implication for defenders. Browsing a GitHub folder tree is a poor way to read query content; a published site can group queries by data source, render the visualisations in a browser, and be searched. The repository structure is the source, and the site is the readable form of it.

The README also points to a second repository, Detections.Ai, and to community workspaces on detections.ai with invite codes, one of them a knowledge group. Those are collaboration spaces rather than code, and their existence tells you the author is trying to build a community around the content rather than just publish a file dump.

The trade-off of a published site is worth stating. Any query content published under a search index becomes visible to defenders and to attackers alike. That is not a reason to avoid it, since detection content ages faster than most published code and a rule that helps one team rarely helps a defender on the other side, but it is a reason to keep your tuned versions of these queries inside your own tenant rather than republishing them.

What you get, and what you still have to build

The repository is not archived and the last push was on 2026-10-10, so the content is being added to. There are no GitHub releases, so there is no versioned stream to pin: you take the current state of the folders, and there is no upstream changelog telling you what changed since the copy you took.

What you get is concrete: KQL text for Azure, Defender XDR, Sentinel and Azure Data Explorer, a set of visualisations, an IOC collection, and the author's contact details. That is a real starting point for a team that would otherwise write every query from a blank editor.

What you still have to build is the larger half. Each query has to be checked against the tables your tenant actually ingests, because a query referencing a table you do not have fails at run time and tells you nothing. Each one has to be run against real data before it is trusted, since a rule that returns everything is as useless as one that returns nothing. The results have to be tuned into something an analyst will act on, and that tuning, along with the entity mapping and the response steps, is yours.

The realistic use is a triage session. Pick the data source you care about most, run the queries in that folder, keep the ones that surface something real in your environment, and discard the rest. The value is in the shortcut past the blank page, not in the queries being right for your tenant.

Editorial conclusion

KQLWizard suits a defender who already runs Microsoft Defender XDR or Sentinel, knows which tables their workspace actually ingests, and wants a starting set of hunting queries to adapt rather than write from scratch. It does not suit a team whose Microsoft 365 or Azure logs are not yet connected, since the queries are only useful against tables that exist in your tenant, and it does not suit anyone who needs packaged detections with tuning, response playbooks and versioning, because this repository ships queries rather than a managed rule set. Before adopting, list the tables your workspace ingests, pick the queries that match those tables, and treat every rule as a draft until you have tested it against your own telemetry.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. Project website
4. README
5. SlimKQL/Hunting-Queries-Detection-Rules on GitHub