A community-maintained collection of KQL detection, hunting, and visualization queries aimed at Microsoft Defender for Endpoint and Microsoft Sentinel deployments in authorized defensive operations.
| Tool | Bert-JanP/Hunting-Queries-Detection-Rules — curated KQL detection rules, hunting queries, and visualizations for Microsoft security products |
| Category | Detection engineering / threat hunting query library (Python repo, BSD-3-Clause) |
| Primary Use | Extending detection coverage with KQL queries against DeviceEvents and related tables in Defender XDR Advanced Hunting and Sentinel Logs |
| Safe Use | Purely defensive: designed for authorized blue team, DFIR, and threat hunting work on environments the analyst is contracted to protect |
| Telemetry Note | The collection is entirely passive detection content; it generates analytics/audit activity in security.microsoft.com and portal.azure.com rather than touching attacker infrastructure |
Bert-JanP/Hunting-Queries-Detection-Rules is one of the more substantial community efforts in the Microsoft detection engineering space, sitting at roughly 1,746 stars with a BSD-3-Clause license. The premise is straightforward and stated plainly in the README: not every suspicious activity generates a default alert in Microsoft security products, but much of it is observable in the logs. The repository closes that gap by sharing readable KQL detection rules, hunting queries, and visualizations that anyone operating Microsoft Defender for Endpoint or Microsoft Sentinel can lift into their own tenant. It is an unambiguously blue team artifact, maintained by an author who also documents his methodology extensively at kqlquery.com.
The organization of the repository is its strongest architectural signal. Rather than a flat dump of query files, content is split into a MITRE ATT&CK section with a dedicated Mapping.md, per-product directories (Defender For Endpoint, Defender For Identity, Defender For Cloud Apps, Office 365, Defender XDR, Azure Active Directory, Sentinel, MISP, Windows Security Events, Graph API), process-oriented directories (DFIR, Threat Hunting, Threat Hunting Cases, Vulnerability Management), and an informational tier covering KQL helper functions, a regex example list, and Azure Resource Graph queries. That taxonomy mirrors how a mature SOC actually segments its content library — by telemetry source, by analyst workflow, and by framework mapping — and it makes the repo navigable as a reference rather than a curiosity.
The per-query naming convention is worth studying because it encodes detection metadata directly in filenames. Queries like ttp_t1219_netsupportrat_fin7.md, ttp_t1562-001_disabledefender.md, and ttp_t1059-001_powershell_windowsappsdir_fin7.md carry the ATT&CK technique ID, the detected behavior, and where applicable the threat actor cluster (FIN7, Scattered Spider, Yellow Cockatoo) associated with the pattern. This is a lightweight but effective convention: an analyst triaging a FIN7 intrusion can grep the repository for fin7 and immediately surface detections relevant to that actor's tradecraft without needing a separate mapping database.
The contributor table is unusually informative about coverage. Gavin Knapp's contributions alone span NetSupport RAT execution from unexpected directories (technique T1219), PowerShell disabling Defender components (T1562.001), suspicious network connections from MSBuild (T1127.001), PowerShell encoded commands (T1027.010), Azure ARC persistence associated with Scattered Spider, Conditional Access abuse, Kerberos attack patterns, and PowerShell creating LNK files in startup directories. Alex Teixeira adds rare outgoing IPv4 connections, known RAT/RMM process patterns, and NTDS.DIT file modification detection — the classic credential-dumping sentinel. Babak Mahmoodizadeh contributes webshell detection and AD delegation enumeration from Windows Security Events. Together these represent the intersection of real intrusion tradecraft and the telemetry tables that expose it.
A distinguishing detail is the DetectionTemplate.md standardization effort. Contributions must use the template, queries must run and be readable, and the README lists several downstream repositories that have adopted the same format — forks by Alex Verboon, Gianni Castaldi (KustoKing), Steven Lim (SlimKQL), SecurityAura's DE-TH-Aura, and m4nbat's KQL collection. The stated rationale is machine-parseability: standardized metadata and query structure allow automation to crawl multiple repositories and collect detections programmatically. For teams building internal query pipelines, this is the most practically important feature of the project — it turns a hand-curated list into something that can feed a detection-as-code workflow with CI validation.
The README also functions as a mini-primer on the operational difference between the two target platforms. In Sentinel, the time filter field is TimeGenerated; in Defender for Endpoint it is Timestamp. The two quickstart snippets demonstrate this — DeviceEvents | where Timestamp > ago(7d) | take 10 versus DeviceEvents | where TimeGenerated > ago(7d) | take 10. It is a small thing, but it is exactly the friction point that trips analysts moving queries between portals, and the repository acknowledges it explicitly rather than leaving users to discover it through errors. Deployment paths are documented too: Advanced Hunting under security.microsoft.com, and Logs under portal.azure.com in Sentinel.
Where this fits in an authorized workflow is clear: a detection engineering team auditing coverage gaps can pull candidate queries from the ATT&CK-mapped directories, adapt the time fields, tune thresholds to their environment's baseline, and promote them into custom detection rules or analytics. The threat hunting directories, including documented full hunting cases and a ransomware leaksite monitoring query, support proactive hypothesis-driven work. The Vulnerability Management section pairs naturally with the author's blog post on prioritizing using the CISA Known Exploited Vulnerabilities catalog — a workflow that joins DeviceTvmInfoGathering and TVM tables against KEV data for patch prioritization.
Analysts evaluating the content should apply the usual review discipline before promoting anything to production. Community queries encode assumptions about baseline behavior — 'rare' outgoing connections, 'anomalous' URL click volumes — that need recalibration per tenant to avoid alert fatigue. The README explicitly warns that presenting the material as one's own is forbidden and asks for attribution to @BertJanCyber or @Bert-JanP, which matters for teams that redistribute detections internally or commercially. Every query should still be read line by line: understand which table it hits, what the where clauses assume, and whether the logic matches the current schema version of the product, since Microsoft tables evolve.
Finally, the surrounding ecosystem the README points to — kqlsearch.com as a KQL search engine, the Kusto Insights newsletter, the cheat sheet PDF, and the linked Sentinel-Automation repository for orchestration — positions this project as a hub rather than an island. For defenders and authorized security teams running Microsoft-centric stacks, Hunting-Queries-Detection-Rules is best treated as a curated, attributed, template-standardized seed corpus: clone it, fork the template, tune aggressively, and contribute back detections that work in your environment. That contribution loop, gated by working-and-readable pull requests, is what has kept the library current enough to reference actors like Scattered Spider and techniques relevant to 2024-era intrusions.
Bert-JanP/Hunting-Queries-Detection-Rules.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.