A community-maintained collection of KQL hunting and detection queries covering Microsoft Defender XDR, Microsoft Sentinel, Entra ID, and Azure, built for defenders and authorized blue teams.
| Tool | alexverboon/Hunting-Queries-Detection-Rules — a curated repository of KQL hunting queries and detection rules for Microsoft security platforms |
| Category | Detection engineering and threat hunting content library |
| Primary Use | Accelerating detection development and proactive hunting across Defender for Endpoint, Defender for Identity, Microsoft Sentinel, Azure, and Entra ID telemetry using KQL |
| Safe Use | Purely defensive resource for authorized security teams: SOC analysts, detection engineers, and purple-team staff operating within their own tenant or during contracted assessments |
| Telemetry Note | The repository itself is content-only — no agents, no network callbacks, nothing to detect in the wild; the queries simply run read-only against your own Log Analytics and advanced hunting stores |
Every blue team running Microsoft security stack eventually confronts the same problem: the platform gives you an enormously powerful query language in KQL, but turning that language into a meaningful detection coverage program is a long, manual slog. alexverboon/Hunting-Queries-Detection-Rules is a community-driven answer to that problem — a standing collection of hunting queries and detection rules written in KQL against the data surfaces of Microsoft Defender XDR, Microsoft Sentinel, Defender for Endpoint, Defender for Identity, Azure, and Entra ID. At roughly 210 stars under a BSD-3-Clause license on the main branch, it sits firmly in the 'useful working reference' tier of security GitHub rather than the abandoned-snippet tier, and that distinction matters when you are deciding what to lift into a production detection pipeline.
The repository's shape is immediately recognizable to anyone who has worked a Microsoft-centric SOC. It is not a tool with a binary, an installer, or a runtime dependency — there is no language runtime, no package manifest, nothing to build. What you get is query content: KQL statements organized around the various Microsoft telemetry tables, intended to be pasted into Advanced Hunting in the Microsoft 365 Defender portal, or into Log Analytics / Sentinel query blades, or adapted into scheduled analytics rules. The repo topics — kql, hunting, detection, sentinel, defenderxdr, defenderforendpoint, defenderforidentity, azuread, entraid, azure, dfir, security — read like a coverage map of the entire modern Microsoft security estate, from endpoint to identity to cloud control plane.
Because the README surface in this context is empty, the honest analytical frame is what the metadata itself tells you, and it tells you quite a lot. The presence of both defenderxdr and sentinel topics signals that the collection is not siloed to one product console — that matters operationally because Defender XDR advanced hunting and Sentinel Log Analytics share KQL syntax but not always table schemas. A query written against DeviceProcessEvents in XDR hunting needs schema translation before it becomes a Sentinel analytics rule joined against SecurityEvent or the Sentinel-side DeviceInfo tables. A collection that spans both implicitly documents those translation patterns, which is often the most valuable part for a detection engineer under deadline.
The identity-side topics — azuread, entraid, defenderforidentity — deserve their own paragraph because identity is where most contemporary intrusions spend their early hours. Hunting content aimed at Entra ID sign-in and audit telemetry, and at Defender for Identity signals from domain controllers, targets exactly the behaviors defenders most need to catch early: anomalous authentication patterns, suspicious consent grants, privilege escalation in the directory, and lateral-movement precursors. For an authorized purple-team exercise, queries in this vein give you a ready-made detection hypothesis list — run the technique, then run the query, and measure whether your telemetry and detection logic actually meet. That loop, technique against query, is the core of modern detection validation, and a query library is the cheaper half of the equation.
The dfir topic indicates the collection also serves forensic and incident-response use cases rather than purely proactive hunting. In practice, KQL hunting queries double as investigation scripts during an active incident: when you have one confirmed compromised host or account, the same table joins that power a detection query let you scope the blast radius across every other device and identity in the tenant. This dual use — hunting when you have no incident, scoping when you do — is why content collections like this one accrue value over time in a way single-purpose tools do not. A query validated during one investigation becomes a scheduled detection afterward, and the repo functions as a shared memory for that progression.
Integration into an authorized workflow is deliberately low-friction. Getting the content is a standard git clone https://github.com/alexverboon/Hunting-Queries-Detection-Rules — from there the queries are text artifacts you review, adapt, and paste into the appropriate console. There is nothing to install beyond git itself, and no telemetry leaves your environment because the queries execute server-side against your own Log Analytics workspace or Advanced Hunting store. For teams that want the content inside Sentinel proper, individual queries can be promoted to Analytics rules with a schedule and incident generation, or stored as Hunting queries in the portal's saved-queries gallery for analyst reuse.
Quality control is where the senior operator's skepticism should focus, and the review discipline is the real work here. Community KQL is written against the author's tenant, their table retention, their schema vintage, and their threat model — Microsoft deprecates and renames tables regularly, and a query that ran cleanly eighteen months ago can fail on a renamed column or return vacuous results after a schema change. Before promoting anything from this repo into a scheduled detection, run it interactively, confirm the tables exist in your workspace, sanity-check the result volume against a baseline window, and strip any assumptions about environment-specific naming. That last point is the recurring failure mode of shared detection content: hardcoded device names, sign-in filter logic tuned to someone else's geographic footprint, or lookback windows sized for a different data retention tier.
From a pure detection-engineering maturity standpoint, a repository like this also functions as a vocabulary lesson. Reading how an experienced hunter structures a KQL query — which tables they join, how they use let statements for staged logic, where they apply summarize versus project, how they bound time windows with ago() — transfers pattern knowledge faster than any syntax documentation. Junior analysts who read the collection as prose rather than copy-paste fodder consistently produce better original queries within weeks, because the repo demonstrates idiomatic KQL against real analytical questions instead of toy examples.
There is also a defensive-intelligence angle worth naming explicitly. Detection content repositories are an underused mirror of attacker tradecraft: every hunting query encodes a hypothesis about how a specific technique manifests in telemetry, which means the query list itself is a coarse map of what contemporary attackers are actually doing in Microsoft estates. Reading the collection top to bottom gives you a threat-model refresher grounded in the author's operational experience, and gaps in the collection — techniques with no query, platforms with thin coverage — are themselves actionable input for your own detection backlog.
Licensing and provenance are clean for enterprise adoption: BSD-3-Clause is permissive, allowing internal redistribution and modification of the queries inside your own detection pipeline, wiki, or Sentinel repository without copyleft obligations. That matters more than it sounds for SOC teams, because detection content often ends up embedded in internal runbooks, automation, and CI pipelines that validate detection-as-code; a permissive license means you can vendor the queries and diff them against upstream pulls without legal review cycles.
The honest caveats: with an empty README in this context, you should verify current maintenance state and internal structure directly on the repository before standardizing on it — check recent commit activity and whether queries are organized by platform, technique, or table, since that organization determines how quickly you can find coverage for a given investigation. Community query repos live and die by maintenance cadence, and KQL content rots faster than most code because its dependencies are external schemas you do not control. Treat this as a living reference to be re-synced periodically rather than a one-time download.
For the right audience — defenders and authorized security teams operating Microsoft estates, whether in-house SOC, MSSC, or purple-team capacity — alexverboon/Hunting-Queries-Detection-Rules is the kind of quiet infrastructure that compounds: every query you adapt, validate, and promote into Sentinel or Defender XDR detection logic is permanent coverage you did not have to write from scratch. It will not replace a detection-as-code pipeline, but it seeds one cheaply, and for a 210-star community collection under a permissive license, that is a strong return on a git clone.
alexverboon/Hunting-Queries-Detection-Rules.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.