3.3 Advanced Hunting

50 minutes · Module 3 · Free

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.

This is where investigation gets real

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.

ADVANCED HUNTING — UNIFIED QUERY SURFACEDevice* tablesEndpointEmail* tablesOffice 365Identity* tablesEntra + on-premCloudApp* tablesCloud AppsSingle KQL query across all tables

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:

1
2
3
4
5
6
CloudAppEvents
| where TimeGenerated > ago(7d)
| where ActionType == "New-InboxRule"
| extend RuleName = tostring(RawEventData.Parameters[0].Value)
| project TimeGenerated, AccountDisplayName, RuleName, IPAddress
| sort by TimeGenerated desc

Find sign-ins from IPs that have never been associated with any user in your organisation:

1
2
3
4
5
6
7
8
9
let known_ips = SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| distinct IPAddress;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where IPAddress !in (known_ips)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, Location

Try it yourself

If you have access to a Defender XDR tenant, open Advanced Hunting at security.microsoft.com/v2/advanced-hunting. Run a simple query: 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.
The schema explorer groups tables by product source. You should see sections for Defender for Endpoint (Device* tables), Defender for Office 365 (Email* tables), Defender for Identity (Identity* tables), and Defender for Cloud Apps (CloudApp* tables). Each table can be expanded to see its columns and data types. Clicking a column name inserts it into your query — a useful shortcut when you cannot remember the exact field name.

Check your understanding

1. What is the difference between using advanced hunting and waiting for the incident queue?

They show the same data
The incident queue shows what automated detections caught; advanced hunting lets you query all recorded data, including activity that did not trigger any detection
Advanced hunting is slower

2. You write a KQL query that reliably finds suspicious inbox rule creation. What should you do with it?

Run it manually every morning
Save it as a bookmark
Save it as a custom detection rule that runs automatically and generates alerts when it finds matches