3.3 Advanced Hunting
Advanced Hunting
Advanced hunting is the KQL query interface that gives you direct access to every data table across all Defender products. The incident queue shows you what the system detected. Advanced hunting shows you everything the system recorded — whether it triggered an alert or not. This is where you go when the automated detections are not enough and you need to ask your own questions.
The incident queue is reactive — it shows you what the system flagged. Advanced hunting is proactive — you write the query, you define the question, you find things nobody built a detection for. Module 2 taught you the KQL. This subsection shows you where to use it.
Two modes: KQL and guided
KQL mode is the raw query editor. You type KQL directly and run it against the unified schema. This is what experienced analysts use daily. The schema explorer on the left shows every available table, grouped by product: Device tables from Defender for Endpoint, Email tables from Defender for Office 365, Identity tables from Defender for Identity, CloudApp tables from Defender for Cloud Apps, and Alert/Incident tables that span all products.
Guided mode is a point-and-click query builder for analysts who are learning KQL or building simple queries quickly. You select a table, pick columns, add conditions through dropdown menus, and the system generates the KQL for you. It is useful for getting started, but you will outgrow it quickly — the investigation scenarios in Phase 3 require queries that guided mode cannot build.
Figure 3.3: Advanced hunting provides a single query surface across all product data tables.
Custom detection rules
Advanced hunting is not just for ad-hoc investigation. You can save a query as a custom detection rule that runs on a schedule and generates alerts or incidents when results are found. This is how you create detections for threats that Microsoft’s built-in rules do not cover — and it is the bridge between Module 2 (writing queries) and Module 10 (building analytics rules in Sentinel).
The workflow: write a query that surfaces the activity you want to detect, test it against historical data to verify it finds what you expect without excessive false positives, then save it as a custom detection with an alert title, severity, entity mapping, and run frequency.
Practical examples
Hunt for inbox rule creation across all mailboxes:
| |
Find sign-ins from IPs that have never been associated with any user in your organisation:
| |
Try it yourself
SigninLogs | take 10. Then try switching between the schema explorer tabs to see what tables are available from each product. If you do not have access, the Log Analytics demo environment at aka.ms/LADemo provides a similar experience.Check your understanding
1. What is the difference between using advanced hunting and waiting for the incident queue?
2. You write a KQL query that reliably finds suspicious inbox rule creation. What should you do with it?