Perform threat hunting
Defender XDR Advanced Hunting
CoreSelect the event schema that matches the hypothesis, write precise KQL, preserve entity context, and use threat and graph views to expand a hunt without overstating evidence.
Aligned to SC-200 skills measured as of July 28, 2026; product behavior verified September 18, 2026.
Why this matters
A hunt is only as reliable as its table choice, filters, joins, and interpretation. Queries that return plausible rows can still join unrelated events, miss values because of case, or aggregate away the device needed for response.
Must Know
- Choose tables by event type: process, network, file, registry, identity, email, cloud application, or alert evidence.
- Use explicit time bounds, correct string semantics, projections, aggregations, and join keys that match the hunting hypothesis.
- Validate reusable Advanced Hunting queries on known examples before saving or converting them into detections.
- Threat analytics combines campaign context with organization-specific exposure and detections; exposure is not proof of compromise.
- Hunting graphs and Sentinel Graph reveal typed relationships. Shared infrastructure and proximity are leads, not verdicts.
Compare and Distinguish
- Start from a schema table that contains the event type; joining unrelated tables first increases cost and ambiguity.
- `where` filters rows, `project` selects or derives columns, `summarize` aggregates groups, and `join` correlates rows between tabular inputs.
- Threat analytics provides Microsoft threat context and exposure guidance; Advanced Hunting tests organization-specific hypotheses against telemetry.
Scenario examples
- Scenario: Hunt for process launches on endpoints. Think: begin with the process-event table rather than email or identity tables.
- Scenario: Count failed actions by account. Think: filter the time and failure condition, then summarize by account.
- Scenario: An entity may connect several alerts. Think: visualize supported relationships in a hunting graph and validate every edge.
Exam traps
- Joining only on DeviceId can pair unrelated processes and connections from different times.
- A syntactically valid query can still test the wrong event population.
- Zero related incidents in threat analytics does not erase a documented exposure.
- A shared proxy IP is weak evidence until users, sessions, time, and other entities align.
Key takeaways
- Start with the schema that records the event you need.
- Test filters and joins independently before trusting a correlated result.
- Distinguish direct observation, exposure, and inferred relationship in every hunt.
How it works
- Advanced Hunting queries event tables with KQL and preserves rows that analysts can pivot into entities and incidents.
- Threat analytics and graphs add campaign, exposure, and relationship context to raw hunting evidence.
Objects and administrative surfaces
- Advanced Hunting query editor, schema, sample queries, and results in the Microsoft Defender portal.
- Threat analytics reports with affected assets and related incidents.
- Hunting graphs and Sentinel Graph for explicit entity relationships and blast-radius analysis.
When to use it
- Use Advanced Hunting for proactive questions that raw alerts do not answer.
- Use threat analytics to prioritize mitigations and focused hunts for campaigns relevant to deployed assets.
Security and governance implications
- Avoid exporting more raw identity or device evidence than the investigation requires.
- Validate shared infrastructure and inferred graph paths before labeling another entity compromised.
Troubleshooting signals
- Test each side of a join separately, then verify keys and temporal proximity on known cases.
- If expected strings are missing, check case sensitivity, timestamp boundary, schema, and null values.
More detail
- Choose tables by event type: process, network, file, registry, identity, email, cloud application, or alert evidence.
- Use explicit time bounds, correct string semantics, projections, aggregations, and join keys that match the hunting hypothesis.
- Validate reusable Advanced Hunting queries on known examples before saving or converting them into detections.
- Threat analytics combines campaign context with organization-specific exposure and detections; exposure is not proof of compromise.
- Hunting graphs and Sentinel Graph reveal typed relationships. Shared infrastructure and proximity are leads, not verdicts.
Ready for the quiz?
- Which table contains endpoint process creation?
- What makes a process-to-network join defensible?
- How should exposed assets with no related incidents be handled?
Related objectives
- D3.1.S1 — Identify the appropriate table to use in a KQL query
- D3.1.S2 — Identify threats by using Kusto Query Language (KQL)
- D3.1.S3 — Create Advanced Hunting queries
- D3.1.S4 — Interpret threat analytics in Microsoft Defender XDR
- D3.1.S5 — Create hunting graphs, including blast radius
- D3.1.S6 — Analyze relationships between entities by using Sentinel Graph