Bert-JanP/Hunting-Queries-Detection-Rules

KQL hunting queries for Microsoft Defender XDR and Sentinel, published as markdown by one practitioner — Bert-Jan Pals. The execution model is the same as Azure-Sentinel: KQL against Microsoft's tables, either interactively in Advanced Hunting or scheduled as a custom detection.

What differs is provenance and intent. This is an individual's collection, not a vendor-maintained ruleset with a review process behind it, and most of it is written as hunting content — a starting point you run, read and refine — rather than tuned detections you schedule and alert on.

Each query is a markdown file with a prose header — an ATT&CK technique table, a description, a "Risk" paragraph, references — followed by fenced KQL blocks under product headings:

# AMSI Script Detection

| Technique ID | Title | Link |
| T1059.001 | Command and Scripting Interpreter: PowerShell | ... |

#### Description
This detection lists all *AmsiScriptDetection* events ...

## Defender XDR
```KQL
DeviceEvents
| where ActionType == "AmsiScriptDetection"
```

Content is filed by product — Defender for Endpoint, Defender for Identity, Azure AD, Office 365, Sentinel, Graph API and a couple of dozen more — so the directory a query lives in tells you which tables it assumes.

ATT&CK comes from the technique table in the markdown header, which is why mapping here is good despite the informal format. The description and risk prose carry through as the rule's description.

A single upstream file may hold more than one KQL block, targeting different products from the same premise.

• Hunting queries are not tuned detections. Many will return volume by design — the AMSI example above deliberately lists every detection event, including benign ones. Read the description before scheduling anything here.
• One maintainer, no release cadence or deprecation process. Check the upstream repository before treating a query as current.