SC-200: Perform Threat Hunting

What to know

Threat hunting in SC-200 centers on KQL (Kusto Query Language) in Microsoft Sentinel and Defender XDR advanced hunting. You must know the hunting workflow: form a hypothesis, query telemetry, validate findings, and promote results into detections. Core concepts: the difference between scheduled analytics rules and custom detections (Defender XDR), hunting queries and livestream, bookmarks to capture results, and search jobs for long-term data. You should be fluent in KQL operators: where, project, summarize, join, union, extend, parse, mv-expand, ago(), bin(), and make_set.

Traps to expect

• Table names differ between portals. Sentinel uses Log Analytics tables (e.g., SecurityEvent, SigninLogs); Defender XDR advanced hunting uses schema tables like DeviceProcessEvents and IdentityLogonEvents. Questions test which table belongs where.
• summarize vs project. summarize aggregates; project selects columns. A common distractor swaps them.
• Time filtering. Use where TimeGenerated > ago(24h) in Sentinel; advanced hunting uses Timestamp. Mixing these is a frequent error.
• Promote vs. save. Saving a hunting query does not create an alert; you must create an analytics rule or custom detection to alert.

Worked example

Hypothesis: unusual PowerShell encoded commands. In Sentinel, query DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has "-enc" | summarize count() by DeviceName, AccountName. Review outliers, bookmark the results, then promote the query into a scheduled analytics rule with entity mapping so it generates incidents. Rule of thumb: a hunt that finds nothing is still useful - document the hypothesis so future hunts don't repeat it.

Rule of thumb

Always filter on time first, aggregate with summarize to spot outliers, and remember: hunting queries are silent - only analytics rules and custom detections create alerts.