Microsoft SC-500: Threat Hunting with Defender XDR

Threat hunting in Microsoft Defender XDR is the practice of asking focused security questions across identity, endpoint, email, application, and cloud evidence before every suspicious pattern becomes a formal alert. The modern hunting surface lives in the Microsoft Defender portal, where advanced hunting uses Kusto Query Language and can also query Microsoft Sentinel data after a Sentinel workspace is onboarded.

Microsoft currently positions threat hunting as useful before, during, and after incidents. Proactive hunts look for behavior that has not generated an alert, reactive hunts expand an active investigation, and post-incident hunts turn lessons learned into new detections. The portal also includes guided mode, the Go hunt pivot, hunting graphs, and prerelease Security Copilot hunting assistance.

Threat hunting therefore belongs inside Microsoft Identity & Security as a repeatable investigation discipline rather than an occasional dashboard exercise.

Start with a hypothesis

A productive hunt begins with one security question: Which devices executed this tool after a suspicious sign-in? Which users contacted this domain? Did any other endpoint create the same persistence mechanism?

Threat hunting is strongest when the question comes before the query. The hypothesis determines which tables, entities, and time window matter.

Beginning with every available table usually creates noise and makes it harder to distinguish evidence from coincidence.

Use advanced hunting as the query layer

Defender advanced hunting provides raw Defender XDR data and, in the unified portal, can include Microsoft Sentinel workspace data according to the workspace’s configured retention.

KQL investigations should filter early, select useful fields, join only when relationships matter, and preserve time context.

The same hunting query can become the basis for a custom detection once the team has proven that the behavior is repeatable and meaningful.

Pivot from incidents with Go hunt

During incident response, the Go hunt action can pivot from an entity or event into an automatically generated advanced-hunting query.

This is useful for expanding scope from one device, user, IP address, file, or other entity already visible in the incident.

Incident triage becomes faster when analysts can move from the incident story into raw evidence without rebuilding the first query manually.

Use guided mode for fast investigation

Analysts who do not know KQL can use guided mode to build queries visually.

Guided mode lowers the barrier to hunting without changing the investigative requirement to understand what the result means.

As analysts become comfortable with the schema, advanced mode provides more flexibility for joins, functions, time-series logic, and reusable hunting libraries.

Use the hunting graph for relationships

Microsoft Defender now provides a hunting graph experience that renders entities and relationships as interactive nodes and edges.

This can help analysts see chains that are difficult to recognize in a tabular result, such as one identity touching several devices or one IP appearing across otherwise separate incidents.

The graph complements KQL; it does not replace the need to validate the underlying events and timestamps.

Hunt across Defender and Sentinel

When Microsoft Sentinel is onboarded to the Defender portal, advanced hunting can query data from both Defender XDR and Sentinel.

Sentinel hunting adds broader SIEM data, functions, and historical context that may not exist in native Defender telemetry.

This convergence reduces context switching and makes it easier to correlate identity, endpoint, network, SaaS, and custom data during one investigation.

Turn proven hunts into detections

A hunt that consistently identifies malicious or high-risk behavior should move toward a custom detection or Sentinel analytics rule.

Detection engineering needs a clear hypothesis, false-positive review, severity, response owner, and defined action.

Do not convert every exploratory query into a scheduled alert. A useful hunting query can be too broad, expensive, or context-dependent for continuous detection.

Keep action separate from evidence

Advanced hunting can support response actions on devices, identities, files, and email in supported scenarios.

Those actions require appropriate permissions and should be proportional to the evidence.

Incident response should preserve the difference between “the query found this entity” and “the evidence justifies isolating or disabling it.”

Build a hunting program from lessons

Successful hunts should improve the organization’s query library, detections, incident runbooks, and architecture.

Identity incidents often reveal that the same user, device, or cloud resource needs broader investigation across Microsoft security signals.

For analysts working around SC-200, the durable workflow is hypothesis → query → validate → pivot → scope → detect → improve. Hunting creates value when it changes what the SOC can find or prevent next time.

A hunting program should define data readiness before it defines query sophistication. Analysts need to know which Defender products are licensed, which Sentinel workspaces are connected, how long each table retains data, and whether important log sources arrive with enough freshness to answer the intended question. A beautiful KQL query is not useful if the relevant events were never collected or aged out before the hunt began.

Schema knowledge should be shared. Device, identity, email, cloud-app, and Sentinel tables use different identifiers and event semantics. Maintain a small reference for common join keys, timestamps, and entity identifiers so hunters do not repeatedly rediscover the same relationships or create many-to-many joins that inflate results.

Time windows should follow the hypothesis. A credential-theft hunt may begin with a one-hour window around a risky sign-in, then expand backward to identify the entry point and forward to identify persistence or lateral movement. Starting with thirty days of every event can slow queries and hide the sequence analysts are trying to reconstruct.

Use saved queries and shared functions for proven investigative patterns. One team member’s query for suspicious PowerShell, OAuth abuse, unusual mailbox activity, or credential replay can become a reviewed starting point for the whole SOC. Keep the query small enough that another analyst can explain what it proves before they use it during an incident.

Hunting results should be preserved with the exact query, parameters, time range, and tenant context. Screenshots can help communicate findings but do not provide enough evidence to reproduce the result later. This is especially important when a hunt contributes to containment, legal review, or a post-incident narrative.

Security Copilot features in advanced hunting can accelerate natural-language exploration and KQL generation, but Microsoft currently documents those experiences as prerelease. Treat generated hunting logic like analyst-authored logic: inspect the schema, validate sample results, and understand the query before it drives an operational decision.

Hunting graphs can reveal relationships that deserve deeper KQL validation. A visual path between a user, device, and IP is a hypothesis accelerator, not the final proof. Use the graph to identify a choke point, then inspect the events and timestamps that create the edge.

Post-incident hunting is one of the highest-value stages because the team already knows what malicious behavior looked like. Search historical and adjacent data for the same technique, update detections, and record which query finally separated the attack from normal activity. That is how one incident improves coverage for the next.

Measure hunting outcomes, not query volume. Useful measures include hunts that discovered previously unknown scope, hunts that produced new detections, time saved during active incidents, and coverage gaps discovered in telemetry. A SOC that runs hundreds of queries with no change in detection or response has activity, not a mature hunting program.

Threat hunting should also account for data-retention differences. Defender XDR advanced hunting currently exposes a rolling raw-data window, while Sentinel-connected data can follow workspace retention. A query that finds nothing in Defender after several weeks may need to move to Sentinel or restored historical data before analysts conclude the behavior never occurred.

Hunt libraries should include ownership and review dates. Microsoft security schemas evolve as products add tables, fields, and unified-portal capabilities. A saved query that silently stops matching the intended activity can be worse than one that fails loudly, so important hunts need periodic validation.

Threat intelligence should refine the question rather than replace it. Indicators such as domains, hashes, and IP addresses can seed searches, but hunters should look for behaviors and relationships that survive infrastructure rotation. This produces more durable coverage than building the entire program around static indicators.

For mature teams, hunting can become an input to purple-team exercises. Use known attack techniques to generate expected telemetry, then test whether the hunt finds the behavior quickly and whether the resulting query is stable enough for detection. That creates evidence that the data source, query, and response path all work together.

The best hunting culture rewards useful negative results too. A well-designed hunt that finds no malicious scope but proves the environment is observable can still validate a hypothesis, eliminate one branch of an incident, or reveal where the telemetry is insufficient. The value is better security decisions, not the number of threats “discovered.”