Microsoft SC-200 Threat Hunting by Scenario

Threat hunting in Microsoft SC-200 is an investigative discipline: start with a hypothesis, search across relevant telemetry, test alternative explanations, preserve useful evidence, and decide whether the activity should become a detection or incident. KQL is central, but query syntax is only one part of the skill. A hunter must choose the right data, time range, entities, baseline, and follow-up pivots.

Scenario practice is the fastest way to build that judgment. Instead of memorizing isolated operators, work through suspicious sign-ins, endpoint persistence, unusual cloud activity, or data-access anomalies and ask what evidence would raise or lower confidence. The sections below use that workflow.

Frame a hypothesis that can be tested

A hunt should be specific enough to guide data selection. “Look for attackers” is not a hypothesis. “A compromised account may be authenticating from a new network and accessing resources it rarely touches” is testable. It suggests sign-in telemetry, resource access, historical behavior, device context, and perhaps role information. If the data shows the user regularly performs the same pattern from a managed travel device, the hypothesis weakens.

Good hypotheses also define a time horizon. Credential theft discovered today may require looking backward days or weeks for initial access and forward for persistence or lateral movement. The time range should follow the behavior you are investigating rather than a convenient default in the portal.

Select data sources before writing the query

Choosing tables is an investigative decision. Identity activity belongs in identity and sign-in sources; process lineage belongs in endpoint telemetry; cloud control-plane actions belong in resource activity logs; security findings may come from Defender products; and Sentinel can bring these sources together. Starting with the first familiar table often produces a narrow hunt that misses the decisive evidence.

Identity-centric hunts benefit from the concepts covered by Microsoft SC-300, especially when Conditional Access, privileged roles, workload identities, or authentication methods affect the meaning of an event. A risky sign-in to an ordinary user is not the same as the same pattern on a privileged administrator or service principal.

Establish a baseline before labeling an anomaly

Anomalous does not automatically mean malicious. A new IP address may be normal travel; a large download may be quarter-end reporting; a process rarely seen on one host may be common on a developer workstation. Baselines help distinguish change from threat. They can be user-specific, device-specific, department-specific, or organization-wide depending on the scenario.

In KQL, this often means calculating historical counts, typical geographies, usual parent processes, or normal resource sets and then comparing current behavior. The exact statistical sophistication can vary. What matters is that the hunt makes “unusual” explicit rather than relying on intuition after seeing one event.

Use joins and parsing only when they add evidence

Hunters often need to connect identity, device, network, or cloud events. Joins are powerful but can multiply rows or hide missing matches if used carelessly. Before joining, decide which side should be authoritative, which keys are stable, and how much time difference is acceptable. Sometimes a union or lookup-style enrichment is clearer than a large multi-table join.

Parsing has similar risks. Dynamic fields and embedded JSON can contain valuable attributes, but a query that silently assumes a property always exists may miss events when the schema changes. Project the fields you need, handle nulls deliberately, and test the query against multiple event shapes. Hunt queries should be robust enough to revisit later.

Pivot through entities instead of staring at one event

A single suspicious process should lead to its parent, user, device, hashes, network destinations, and nearby processes. A suspicious sign-in should lead to device identity, session behavior, authentication method, resource access, and role changes. Each pivot either strengthens the original hypothesis or offers a benign explanation. The goal is to build a connected story, not a pile of unrelated search results.

Entity pivots also reveal scope. If the same destination appears on five devices, or the same account touches several sensitive resources, the investigation may be broader than the initial alert suggested. Conversely, if all unusual activity is confined to a disposable test system, the business impact may be lower.

Preserve discoveries with bookmarks and notes

Useful hunting results should not disappear when the query tab closes. Bookmarking significant events, recording why they matter, and linking them to an incident or case preserves investigative reasoning. The saved evidence should include enough context that another analyst can understand the finding without reconstructing every step.

This habit is especially important when the hunt spans multiple hours or shifts. Security operations is collaborative. A concise note explaining “new administrator role, followed by unfamiliar sign-in and mailbox access from the same session” is more valuable than a bookmark with no interpretation.

Promote repeated findings into detections

If a hunt repeatedly identifies the same malicious pattern, consider turning the logic into an analytic detection. The hunt query may need simplification, performance tuning, entity mapping, severity logic, and false-positive handling before it becomes production-ready. A good hunter therefore understands detection engineering even when the immediate task is exploratory.

This is the bridge between hunting and the detection-engineering discipline covered elsewhere in the SC-200 learning path: hunts discover useful patterns; detections operationalize the patterns that are stable enough to monitor continuously. Not every hunt should become a rule, but every strong candidate should be evaluated.

Walk a compromised-account hunt end to end

Assume a finance user reports an unexpected MFA prompt. Start with sign-in activity around the report, compare the network and device with recent history, and inspect successful sessions that followed denied or risky attempts. Pivot into mailbox or application access, role changes, endpoint activity from the user’s devices, and any matching IP or session indicators across other accounts. The hunt should test both credential theft and benign explanations such as a newly enrolled phone.

Broader threat references like common enterprise security threats can suggest hypotheses, but the hunt succeeds only when the evidence supports a conclusion. Document the strongest facts, what remains uncertain, and which action would reduce risk without overstating confidence.

Practice with scenario notebooks, not query flashcards

A useful study notebook has one page per scenario: hypothesis, data sources, first query, pivots, baseline, decisive evidence, and possible detection candidate. Rewrite the KQL from memory, but also explain why each table and time range was chosen. That reasoning makes syntax easier to retain because it has a purpose.

By exam time, you should be comfortable starting from a story rather than a preselected operator. If the scenario says “rare privileged access followed by suspicious cloud activity,” you should know which evidence to seek, how to compare it with normal behavior, and how to turn the results into an investigation or detection.

Build hunts that deliberately test competing explanations. If a user downloads an unusually large amount of data, one hypothesis is collection before exfiltration; another may be a legitimate reporting job. Search for the user’s normal download volume, destination application, device state, role, and whether similar activity occurs at the same business cycle. A hunt becomes stronger when it can disprove a benign explanation rather than merely find something unusual.

Practice time reasoning explicitly. Many attack steps are related but not simultaneous. Password spraying may occur hours before a successful sign-in; privilege escalation may occur days after initial access; exfiltration may happen after long reconnaissance. Use windows that reflect the scenario and explain why you chose them. Arbitrary “last 24 hours” filters can miss the story or create too much noise.

Performance matters in hunting as well. A query that scans unnecessary columns and months of high-volume telemetry may be correct but impractical. Apply time filters early, project only useful fields, summarize where appropriate, and test expensive joins on smaller samples before widening the search. Efficient hunting allows faster iteration during a real investigation.

Finally, close the hunt with a decision. The result may justify an incident, a detection rule, a data-quality improvement, a documented benign pattern, or no action. “Interesting query results” are not an outcome. SC-200 scenarios reward the analyst who can turn evidence into the next operational step.

Hunts should also include a stopping rule. Endless exploration can consume analyst time without changing the decision. Define what evidence would be sufficient to escalate, close as benign, or convert the question into a longer investigation. The stopping rule keeps the hunt aligned with risk rather than curiosity.

Create reusable query fragments carefully. A tested function or let statement for normalizing account identifiers can accelerate multiple hunts, but it should have clear assumptions and ownership. Reuse is valuable when it reduces mechanical work; it is dangerous when analysts inherit logic they no longer understand.

When reviewing your hunt afterward, keep both successful and unsuccessful queries. The failed paths show which assumptions were wrong and often reveal missing telemetry or ambiguous identifiers. A short hunt journal—hypothesis, queries tried, evidence found, decision, and next improvement—turns each investigation into reusable analytical knowledge.

Treat every useful hunt as a candidate for future operational improvement, even when it closes benign. Every hunt should record its original hypothesis and the evidence that would disprove it, so later analysts can distinguish an investigation from a reusable detection.