This chapter covers threat hunting in Microsoft Sentinel, a core skill for the SC-200 exam. Threat hunting is the proactive search for malicious activity that evades existing detection rules. It accounts for approximately 10-15% of exam questions under objective 2.6, focusing on creating and managing hunting queries, using bookmarks, and leveraging livestream sessions. You will learn the hunting lifecycle, KQL techniques, and how to operationalize findings into custom detections.
Jump to a section
Threat hunting is like a detective reopening a cold case file. The detective doesn't wait for a new crime report (alert) to come in — they proactively review old evidence, interview witnesses again, and look for patterns that were missed initially. In the same way, a threat hunter in Microsoft Sentinel doesn't wait for detection rules to fire. They use KQL queries to sift through historical data, looking for subtle indicators of compromise like unusual logon times, anomalous process creation chains, or beaconing network traffic. The detective might notice that a witness's timeline was off by 10 minutes, leading to a new suspect. Similarly, a hunter might find that a user logged in from two different countries within 5 minutes — impossible for a human, but a sign of credential theft. The detective uses a case management system to document findings and share with the team; the hunter uses Sentinel's bookmarks and hunting livestream to preserve evidence and collaborate. Just as a detective must understand criminal behavior to spot deviations, a hunter must understand normal network behavior to identify anomalies. The goal is the same: find the hidden truth before it's too late.
What Is Threat Hunting in Sentinel?
Threat hunting is a proactive cybersecurity practice where analysts search for signs of adversarial activity that may have bypassed automated detection mechanisms. In Microsoft Sentinel, threat hunting leverages the platform's log ingestion, Kusto Query Language (KQL), and built-in hunting queries to identify suspicious behavior. Unlike incident response, which reacts to alerts, hunting assumes compromise and seeks evidence of it.
Why Threat Hunting Exists
Automated detection rules have limitations: they rely on known signatures, predefined thresholds, and specific event patterns. Sophisticated attackers can evade these by:
Using living-off-the-land binaries (LOLBins) that blend with normal admin activity.
Slow, low-and-slow attacks that stay below alert thresholds.
Custom malware that triggers no known signatures.
Credential theft and lateral movement that mimic legitimate user behavior.
Threat hunting fills these gaps by using hypothesis-driven analysis and anomaly detection.
The Hunting Lifecycle in Sentinel
The hunting process in Sentinel follows a structured lifecycle:
Hypothesis: Formulate a theory about potential attacker behavior (e.g., "An attacker might be using PowerShell to download Cobalt Strike").
Query Development: Write KQL queries to test the hypothesis against historical data.
Investigation: Analyze results, use bookmarks to tag interesting events, and pivot to related data.
Livestreaming: For active threats, create a livestream session to monitor real-time data.
Operationalization: Convert successful hunting queries into custom analytics rules for continuous detection.
Key Components of Threat Hunting in Sentinel
Hunting Queries: Pre-built KQL queries in the Sentinel repository that cover common attacker techniques (e.g., pass-the-hash, DCSync). You can run them immediately or customize.
Bookmarks: Save specific query results for later investigation. Bookmarks preserve the query, timestamp, entity mapping, and notes. They can be promoted to incidents.
Livestream: Real-time query execution that continuously streams results. Useful for monitoring active threats.
MITRE ATT&CK Mapping: Many hunting queries are tagged with MITRE techniques, helping you align hunts with known adversary behaviors.
Entity Mapping: Bookmark results can include entities (user, host, IP, etc.) for enrichment and correlation.
How to Create and Run Hunting Queries
To access hunting queries: 1. In Azure Sentinel, navigate to Threat Management > Hunting. 2. The Hunting blade shows a list of built-in queries with descriptions, MITRE tags, and severity. 3. Select a query and click Run Query to execute against the selected workspace. 4. Results appear in the query window. You can modify the KQL directly.
Example built-in query: "Suspicious process execution from unusual locations"
// Look for processes executed from temporary folders
let suspicious_paths = dynamic([@"\\Windows\\Temp", @"\\Users\\*\\AppData\\Local\\Temp"]);
DeviceProcessEvents
| where InitiatingProcessFileName has_any ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe")
| where FileName !in ("svchost.exe", "conhost.exe")
| where FolderPath matches regex @"\\Windows\\Temp|\\Users\\.*\\AppData\\Local\\Temp"
| project TimeGenerated, DeviceName, FileName, FolderPath, InitiatingProcessFileNameUsing Bookmarks for Investigation
Bookmarks allow you to save interesting events for later analysis. To create a bookmark: 1. Run a hunting query. 2. Select one or more rows in the results. 3. Click Add bookmark. 4. Provide a name, description, and entity mapping (e.g., map the Account field to the User entity). 5. The bookmark appears in the Bookmarks tab under Hunting.
Bookmarks can be: - Investigated: Open the bookmark to see saved entities, timeline, and notes. - Promoted to incident: If you confirm malicious activity, you can create an incident from the bookmark. - Exported: Bookmarks can be exported to a CSV file for external analysis.
Livestream Sessions
Livestream is a real-time hunting feature. To start a livestream:
1. In the Hunting blade, click Livestream.
2. Write a KQL query that filters on ingestion_time() > ago(5m) or similar.
3. Click Start to begin streaming results.
4. The session runs for up to 24 hours (default) but can be stopped manually.
Livestream is ideal for monitoring ongoing attacks, such as a brute-force attempt or lateral movement.
Operationalizing Hunting Queries into Analytics Rules
When a hunting query consistently yields true positives, convert it into a scheduled analytics rule: 1. From the query results, click New alert rule. 2. Configure the rule: set frequency (e.g., every 5 minutes), threshold, and entity mapping. 3. Enable the rule for automatic detection and incident creation.
This closes the loop between proactive hunting and automated detection.
Best Practices for Effective Hunting
Use MITRE ATT&CK: Align queries with known techniques to increase coverage.
Focus on Unusual Behavior: Look for anomalies like logons outside business hours, unusual RDP connections, or service account logons to workstations.
Correlate Multiple Data Sources: Combine Windows Event Logs, Sysmon, network logs, and Azure AD sign-ins for a fuller picture.
Document Hypotheses: Keep a log of hunts and outcomes to avoid duplication.
Tune Queries: Start broad, then narrow down using time filters, entity exclusion, and threshold adjustments.
Performance Considerations
Hunting queries can be resource-intensive. To optimize:
Use time filters (e.g., | where TimeGenerated > ago(7d)) to limit scope.
Use materialized views for frequently accessed data.
Avoid cross-workspace queries unless necessary.
Leverage summarization and aggregation to reduce result sets.
Default Values and Timers
Livestream default duration: 24 hours (can be stopped earlier).
Bookmark retention: Retained as long as the workspace exists (subject to retention policy).
Hunting query results: Visible for 14 days in the query history.
MITRE ATT&CK version: Sentinel uses MITRE ATT&CK v10+ (check current version in portal).
Integration with Other Sentinel Features
UEBA: User and Entity Behavior Analytics can surface anomalies that feed hunting hypotheses.
Investigation Graph: Bookmarks can be added to investigation graphs for visual correlation.
Watchlists: Use watchlists to exclude known benign IPs or include suspicious indicators.
Common Hunting Scenarios
Credential Theft: Look for multiple failed logons followed by a successful logon from a different location.
Lateral Movement: Search for remote service creation (e.g., sc.exe create) or WMI execution.
Data Exfiltration: Identify large outbound file transfers via HTTP or FTP.
Persistence: Hunt for scheduled tasks created by non-admin users.
Defense Evasion: Detect disabled security tools or cleared event logs.
Formulate a Hunting Hypothesis
Start with a hypothesis based on threat intelligence, recent incidents, or common attacker behaviors. For example: 'An attacker may be using scheduled tasks for persistence.' This hypothesis guides your query design. Document the hypothesis in a notebook or the Sentinel comments field. A good hypothesis is specific, testable, and aligned with MITRE ATT&CK techniques (e.g., T1053.005). Avoid vague hypotheses like 'check for bad stuff.'
Create or Select a Hunting Query
Use built-in hunting queries or write a custom KQL query. For the hypothesis above, query for scheduled tasks created by non-system accounts: `ScheduledTasks | where TaskName !startswith "Microsoft" and UserId != "SYSTEM"`. Modify the query to include relevant data sources (e.g., Event ID 4698). Use time filters to limit to recent data (e.g., `where TimeGenerated > ago(7d)`). Run the query and review initial results.
Analyze Results and Create Bookmarks
Examine query results for suspicious entries. If you find a scheduled task created by a low-privilege user on a domain controller, select that row and click 'Add bookmark.' Provide a descriptive name (e.g., 'Suspicious task on DC-01'), add notes about why it's suspicious, and map entities (e.g., map the Account field to the User entity). Bookmarks preserve the query and time context for later investigation.
Investigate Using Bookmarks and Pivoting
Open the bookmark from the Bookmarks tab. Review the saved query and results. Use the entities (e.g., user, host) to pivot: run additional queries on that user's logon history, or check for related processes on the host. For example, query `DeviceLogonEvents | where AccountName == "jdoe"` to see if the user logged in from unusual IPs. Document findings and update the bookmark with new notes.
Promote to Incident or Livestream
If the investigation confirms malicious activity, promote the bookmark to an incident: select the bookmark and click 'Promote to incident.' This creates a formal incident in Sentinel with all associated entities. For ongoing threats, start a livestream session with a query that monitors the same behavior (e.g., `ScheduledTasks | where ... | where ingestion_time() > ago(5m)`). This provides real-time visibility.
Operationalize as Analytics Rule
Once the hunting query proves effective, convert it into a scheduled analytics rule. From the query results, click 'New alert rule.' Configure the rule: set frequency (e.g., every 5 minutes), threshold (e.g., 1 occurrence), and entity mapping. Enable the rule. This ensures future occurrences automatically generate incidents, closing the loop between proactive hunting and automated detection.
Enterprise Scenario 1: Proactive Hunt for Credential Theft
A large enterprise with 10,000 endpoints uses Sentinel to hunt for credential theft. The security team hypothesizes that attackers are using Mimikatz to extract credentials. They run a built-in hunting query that looks for procdump.exe or mimikatz.exe execution with unusual parent processes. The query returns a match on a developer workstation where procdump.exe was launched from cmd.exe with arguments targeting lsass.exe. The team creates a bookmark, investigates the user's recent logons, and finds a logon from an external IP. They promote the bookmark to an incident, which triggers IR. The query is later converted to an analytics rule to catch future attempts. At scale, the team runs hunting queries weekly, focusing on high-value assets like domain controllers and admin workstations. Performance is managed by limiting queries to the last 7 days and using workspace-level resource limits.
Enterprise Scenario 2: Detecting Lateral Movement via WMI
A financial institution uses Sentinel to hunt for lateral movement. The hypothesis: attackers use WMI for remote command execution. The team writes a KQL query for Event ID 5861 (WMI activity) filtered by Namespace = "root\cimv2" and Query containing "SELECT * FROM Win32_Process". They run the query against all servers and find a workstation making WMI calls to a domain controller—unusual for a standard user. The team bookmarks the event, maps the source and destination hosts, and investigates the user's privileges. They discover the user is a helpdesk admin who shouldn't be using WMI. The bookmark is promoted to an incident. The team also starts a livestream on WMI events from that workstation. The query is operationalized with a threshold of 5 calls in 10 minutes to reduce noise.
Common Misconfigurations
Not using time filters: Running queries against all historical data can be slow and expensive. Always add a time range.
Ignoring false positives: Without tuning, hunting queries can produce many false positives. Use watchlists to exclude known good processes or IPs.
Failure to document: Without notes on hypotheses and findings, hunts cannot be repeated or improved.
Not operationalizing: If a query consistently finds true positives but is never converted to an analytics rule, the detection gap remains.
What SC-200 Tests on Threat Hunting
Objective 2.6: "Create and manage hunting queries" is a key exam area. Questions typically cover: - Creating hunting queries: Using KQL to filter, project, and summarize data. - Using bookmarks: How to create, modify, and promote bookmarks to incidents. - Livestream sessions: Starting, stopping, and configuring livestreams. - MITRE ATT&CK integration: Mapping queries to techniques. - Operationalizing queries: Converting to analytics rules.
Common Wrong Answers and Why
Wrong: 'Hunting queries can only be run on live data.' Reality: Hunting queries run against historical data in the workspace. Livestream is for real-time.
Wrong: 'Bookmarks are automatically promoted to incidents.' Reality: You must manually promote a bookmark to create an incident.
Wrong: 'Livestream sessions run indefinitely.' Reality: Default duration is 24 hours, but can be stopped manually.
Wrong: 'All built-in hunting queries are enabled by default.' Reality: They are available but not scheduled; you must run them manually.
Specific Numbers and Terms
Default livestream duration: 24 hours.
Bookmark retention: As long as the workspace exists.
Query history retention: 14 days.
MITRE ATT&CK version: v10+ (check exam version).
KQL operators to know: where, project, summarize, join, extend, make-series, bin.
Edge Cases and Exceptions
Cross-workspace queries: Hunting queries can reference multiple workspaces using the workspace() function, but this is less common.
Bookmark permissions: Only users with Sentinel Contributor role can create bookmarks.
Livestream limits: Maximum of 10 concurrent livestream sessions per workspace.
Query timeout: Hunting queries time out after 10 minutes by default.
How to Eliminate Wrong Answers
If an answer says 'hunting is reactive,' eliminate it — hunting is proactive.
If an answer says 'bookmarks are deleted after 30 days,' eliminate it — they persist with workspace.
If an answer says 'livestream runs until stopped,' it's partially correct but default is 24 hours.
If an answer mentions 'UEBA' as a hunting feature, it's not directly — UEBA provides insights but hunting queries are separate.
Threat hunting in Sentinel is proactive; you search for threats before alerts fire.
Hunting queries use KQL and can be run against historical data.
Bookmarks preserve query results and entities for later investigation.
Bookmarks must be manually promoted to create incidents.
Livestream sessions run in real-time for up to 24 hours.
Successful hunting queries should be converted to analytics rules.
MITRE ATT&CK mapping helps align hunts with known adversary behaviors.
Only Sentinel Contributors can create bookmarks and modify queries.
Query history is retained for 14 days.
Use time filters and summarization to optimize query performance.
These come up on the exam all the time. Here's how to tell them apart.
Hunting Queries
Run manually or on-demand
Used for proactive investigation
Results are not automatically alerted
Can be scheduled via Livestream for real-time
Ideal for hypothesis testing
Analytics Rules
Run automatically on a schedule
Used for automated detection
Generate alerts and incidents
Configured with frequency and threshold
Ideal for continuous monitoring
Mistake
Threat hunting is the same as incident response.
Correct
Threat hunting is proactive — you search for threats before alerts fire. Incident response is reactive, triggered by an alert or incident. In Sentinel, hunting queries run against historical data; incidents are created from alerts.
Mistake
Hunting queries can only be run by administrators.
Correct
Any user with at least Sentinel Reader role can run hunting queries. Creating or modifying queries requires Sentinel Contributor. Bookmarks require Contributor role.
Mistake
Livestream sessions can run forever.
Correct
Livestream sessions have a default maximum duration of 24 hours. They can be stopped manually earlier, but they will automatically stop after 24 hours if not stopped.
Mistake
Bookmarks are automatically converted to incidents after review.
Correct
Bookmarks are saved for investigation but must be manually promoted to create an incident. There is no automatic promotion.
Mistake
Built-in hunting queries cover all MITRE ATT&CK techniques.
Correct
Built-in queries cover many common techniques but not all. You can create custom queries for any technique. Microsoft regularly updates the repository.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Navigate to Threat Management > Hunting. Click 'New query' or select an existing query to edit. Write your KQL query in the query window, add a description, and optionally map to MITRE ATT&CK techniques. Click 'Create' to save. You can then run the query immediately or schedule it via Livestream.
A hunting query runs once against historical data. A livestream runs continuously in real-time, streaming new results as they are ingested. Livestream sessions have a default maximum duration of 24 hours and are useful for monitoring active threats.
Yes. Hunting queries are stored in the Sentinel workspace and are visible to all users with appropriate permissions (at least Sentinel Reader). You can also export queries as JSON files and import them into other workspaces.
In the Bookmarks tab, select the bookmark you want to promote. Click 'Promote to incident' in the toolbar or context menu. This creates a new incident with the bookmark's details and entities. The incident will appear in the Incidents blade.
Hunting queries have a default timeout of 10 minutes. If a query times out, you can optimize it by adding time filters, using summarization, or reducing the data scope. You can also increase the timeout in the query settings (up to 30 minutes).
Yes. Microsoft periodically updates the built-in hunting query repository with new queries and improvements. These updates are applied automatically to your workspace. You can also add custom queries that are not affected by updates.
Yes. You can use the `workspace()` function in KQL to reference tables from other workspaces. For example: `union workspace('workspace1').SecurityEvent, workspace('workspace2').SecurityEvent`. However, this may impact performance.
You've just covered Threat Hunting in Sentinel — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?