This chapter dives deep into the Threat Hunting Query Library in Microsoft Sentinel, a critical feature for proactive threat detection. For the SC-200 exam, understanding how to leverage, create, and manage hunting queries is essential, as it directly relates to objective 2.6: 'Conduct threat hunting in Microsoft Sentinel.' Expect approximately 5–10% of exam questions to touch on this area, focusing on query creation, the use of the Hunting blade, and integration with other Sentinel features. We'll cover the mechanics of the library, step-by-step hunting workflows, and exam-critical details like KQL basics and query scheduling.
Jump to a section
Imagine you are a detective in a large police department. Over the years, you and your colleagues have solved hundreds of cases—each one involving a unique modus operandi (MO) used by criminals. Instead of starting every new investigation from scratch, you maintain a library of case files. Each file, say 'Burglary via Unlocked Window,' contains the step-by-step methods, evidence markers, and patterns that were observed in past cases. When a new burglary report comes in, you don't reinvent the wheel. You go to the library, pull the relevant file, and use its checklist to guide your investigation. You look for specific evidence (e.g., pry marks on windows, footprints in the garden) that the file says to expect. If you find them, you can quickly link the new crime to a known pattern, identify the likely suspect, and take action. The library is not static; you update it with new MOs as they emerge. Similarly, in Microsoft Sentinel, threat hunting queries are pre-built, tested, and stored in a query library. When a security analyst wants to hunt for a specific threat—like 'Pass-the-Hash' or 'Lateral Movement via RDP'—they don't write a query from scratch. They select the appropriate query from the library, run it against their data, and look for the indicators described in the query. The library is curated by Microsoft security researchers and the community, and it is updated regularly to reflect new attack patterns. This dramatically speeds up hunting and ensures consistency across investigations.
What is the Threat Hunting Query Library?
The Threat Hunting Query Library in Microsoft Sentinel is a centralized repository of Kusto Query Language (KQL) queries designed to help security analysts proactively search for suspicious activity that may evade automated detection rules. Unlike scheduled alerts that fire based on predefined conditions, hunting queries are typically run manually or on a schedule to explore data for signs of compromise. The library includes built-in queries from Microsoft (first-party), community-contributed queries from the Azure Sentinel GitHub repository, and custom queries created by your organization.
Why Does the Library Exist?
Traditional security monitoring relies on signature-based detection (e.g., SIEM rules) to generate alerts. However, advanced threats often use novel techniques that do not match known signatures. Hunting queries allow analysts to hypothesize about adversary behaviors (e.g., 'Is there evidence of credential dumping?') and then search across historical and real-time data to confirm or refute the hypothesis. The library standardizes these efforts, providing a starting point for both novice and expert hunters.
How It Works Internally
When you open the Microsoft Sentinel workspace in the Azure portal, you navigate to the 'Hunting' blade. Here, you see a list of all available queries. Each query has:
Name: A descriptive title (e.g., 'Mimikatz Detected via Event ID 4673').
Description: Explains what the query detects and where to look.
Tactics: MITRE ATT&CK tactics (e.g., Credential Access, Lateral Movement).
Techniques: Specific MITRE techniques (e.g., T1003 for Credential Dumping).
Query: The KQL code that runs against your Log Analytics workspace.
Results: The output of the query when executed.
Frequency: How often the query runs if scheduled.
When you run a query, Sentinel executes the KQL against your workspace's data tables (e.g., SecurityEvent, CommonSecurityLog, SigninLogs). The query returns matching results, which you can then investigate. You can also 'Add to Bookmarks' to save specific results for further analysis or 'Create Alert Rule' to turn a successful query into a scheduled detection rule.
Key Components and Defaults
Built-in Queries: Microsoft provides over 100+ queries covering various attack techniques. These are updated regularly via the Azure Sentinel GitHub repository. For example, the 'Mimikatz detection' query looks for Event ID 4673 (Sensitive Privilege Use) with a specific process name.
Custom Queries: You can create your own queries by writing KQL. They are stored in the workspace and can be shared via Azure Resource Manager (ARM) templates.
Query Frequency: When scheduled, queries can run every 1, 2, 6, 12, or 24 hours, or weekly. The default is 'Not scheduled' (manual execution).
Retention: Query results are stored in the 'HuntingQueryResult' table in your Log Analytics workspace for 30 days by default.
Permissions: To create or edit queries, you need at least 'Microsoft Sentinel Contributor' role on the workspace.
Configuration and Verification Commands
To create a custom query, you can use the Azure portal:
Go to Sentinel -> Hunting -> New Query.
Fill in the form: name, description, tactics, techniques, and the KQL query.
Optionally set a schedule and define the data source (e.g., tables).
You can also use the REST API or PowerShell. For example, to list all queries via PowerShell:
$workspaceId = "your-workspace-id"
$queries = Get-AzSentinelHuntingRule -ResourceGroupName "rg" -WorkspaceName $workspaceIdTo create a query via ARM template, you would define a resource of type Microsoft.OperationsManagement/solutions/watchers.
Interaction with Related Technologies
MITRE ATT&CK Framework: Each query is tagged with tactics and techniques, enabling you to hunt based on the MITRE matrix. This aligns with the 'Threat Intelligence' integration in Sentinel.
Analytics Rules: You can promote a hunting query to a scheduled alert rule by clicking 'Create Alert Rule' on the results page. This automatically pre-fills the KQL and schedule settings.
Bookmarks: During hunting, you can bookmark interesting results. Bookmarks store the query, timestamp, and any notes. They can be escalated to incidents.
Livestream: You can also run hunting queries in a livestream mode (Preview) where the query runs continuously on incoming data, alerting you in near real-time.
Exam Critical Details
The SC-200 exam expects you to know the difference between 'Hunting' and 'Analytics' rules. Hunting queries are manual or scheduled but do NOT generate alerts by default. Analytics rules are designed to generate alerts and incidents.
You must understand how to use MITRE ATT&CK tags to filter queries in the hunting blade.
Know that you can save hunting results as bookmarks and later create incidents from bookmarks.
Be aware of the 'Livestream' feature (Preview) and its limitations: it uses a separate cost model (pay per GB of data scanned).
The exam may ask about the default retention of hunting query results: 30 days.
Trap Patterns
Wrong Answer: 'Hunting queries automatically create incidents.' Reality: They do not; you must manually create an alert rule or escalate a bookmark.
Wrong Answer: 'All hunting queries are real-time.' Reality: Most are historical; only Livestream offers near real-time.
Wrong Answer: 'You need Global Admin to create hunting queries.' Reality: Microsoft Sentinel Contributor is sufficient.
Step-by-Step Threat Hunting Workflow
Formulate Hypothesis: Based on threat intelligence or recent incidents, decide what to hunt for (e.g., 'Is there evidence of Pass-the-Hash?').
Select a Query: In the Hunting blade, use filters (e.g., tactic = 'Credential Access') to find relevant queries.
Run the Query: Click 'Run' to execute the KQL against your workspace. Results appear in a table below.
Analyze Results: Review the returned data. Look for anomalies like unusual process creation, logon events, or network connections.
Bookmark Interesting Results: Select rows and click 'Add to Bookmarks'. Provide a rationale.
Investigate: Use the investigation graph or other tools to dive deeper into bookmarked entities.
Escalate: If malicious activity is confirmed, create an incident from the bookmark or create an alert rule to detect future occurrences.
This workflow is central to the SC-200 exam scenario questions.
Formulate a Hypothesis
Begin with a clear hypothesis about potential adversary behavior. For example, 'I suspect an attacker is using PowerShell to download payloads from a remote server.' This hypothesis should be based on threat intelligence, recent vulnerabilities, or observed anomalies. The hypothesis drives the selection of the appropriate hunting query. In the exam, you may be given a scenario (e.g., 'A user received a phishing email with a malicious attachment') and asked to choose the best query to run. The correct query would target the technique used in the attack (e.g., 'Suspicious PowerShell command lines').
Select a Query from the Library
Navigate to the Microsoft Sentinel Hunting blade. Use the search bar and filters (e.g., by MITRE tactic, technique, or keyword) to find relevant queries. For the PowerShell download hypothesis, you might filter by tactic 'Execution' and technique 'T1059.001 (PowerShell).' The library displays each query's name, description, and tags. The exam may test your ability to identify the correct query given a specific threat. Remember that built-in queries are updated via GitHub; custom queries are stored in the workspace.
Run the Query and Review Results
Click 'Run' to execute the selected query. The KQL runs against your Log Analytics workspace, scanning historical data (default time range: last 24 hours, but you can adjust). Results appear in a table with columns like TimeGenerated, Computer, Account, and ProcessName. Analyze the results for indicators of compromise (IoCs). For example, if the query looks for PowerShell downloading files, you might see entries with 'Invoke-WebRequest' or 'System.Net.WebClient'. The exam may ask about interpreting query results or adjusting time ranges.
Bookmark and Investigate Findings
If you find suspicious results, select them and click 'Add to Bookmarks'. Provide a name, description, and tags (e.g., 'Phishing campaign'). Bookmarks store the query, the specific result, and any notes. They appear in the 'Bookmarks' tab for later review. You can then investigate further using the investigation graph: right-click an entity (e.g., IP address) and choose 'Investigate'. This opens a graphical map of related events. The exam may test the purpose of bookmarks and how to escalate them to incidents.
Escalate or Create Alert Rule
If the investigation confirms malicious activity, you can escalate the bookmark to an incident by selecting 'Create Incident' from the bookmark details. Alternatively, you can create a scheduled alert rule from the query results by clicking 'Create Alert Rule'. This pre-fills the KQL and schedule settings, allowing you to automatically detect similar behavior in the future. The exam emphasizes that hunting queries do not automatically generate alerts; you must explicitly create an alert rule or incident.
Enterprise Scenario 1: Detecting Lateral Movement with Pass-the-Hash
A large financial institution uses Microsoft Sentinel to monitor its Active Directory environment. The security team hypothesizes that an attacker might be using Pass-the-Hash (PtH) to move laterally between servers. They use the built-in hunting query 'Potential Pass-the-Hash Attack' which looks for Event ID 4624 (Logon) with LogonType 3 (Network) and a specific account that appears on multiple computers within a short time. The query uses KQL to group by Account and count distinct computers. When run, it returns a list of accounts that have logged into more than 5 computers in under 10 minutes. The team bookmarks suspicious results and investigates. They find that a service account has been compromised. They create an alert rule to detect similar patterns in the future. In production, this query runs every 6 hours against millions of events. Performance considerations: the query must be optimized with time filters and aggregation to avoid timeouts. Misconfiguration: if the query is too broad, it generates many false positives; if too narrow, it misses attacks. The team adjusts the threshold based on baseline behavior.
Enterprise Scenario 2: Hunting for Data Exfiltration via DNS
A technology company is concerned about data exfiltration using DNS tunneling. They use a custom hunting query that looks for DNS queries with unusually long subdomains or high query volumes to a single domain. The query joins DnsEvents (from Azure DNS or Windows DNS logs) with ThreatIntelligenceIndicator to see if the domain is known malicious. In production, the query runs every 12 hours. Scale: the company generates 10 million DNS queries per day. The query uses summarize to count queries per domain and filters where count > 1000. Performance issues arise if the time range is too large; they partition the query by hour. Misconfiguration: if the threshold is too low, they get flooded with alerts from legitimate CDN traffic. They tune the threshold by analyzing baseline traffic during non-peak hours.
Scenario 3: Insider Threat Detection with Unusual Office 365 Access
A healthcare organization wants to detect insider threats accessing patient records outside business hours. They use the built-in query 'Unusual Office 365 Access by User' which looks at SigninLogs for successful logins from unusual IP addresses or outside normal hours. The query uses where timestamp between (datetime(01-01-2023) .. datetime(12-31-2023)) and where isnotempty(IPAddress). In production, they schedule it to run daily. They also integrate with Azure AD Identity Protection to enrich results. Misconfiguration: if the time zone is not set correctly, the query may flag legitimate after-hours work as suspicious. They adjust the query to use the user's time zone from Azure AD.
SC-200 Objective 2.6: Conduct Threat Hunting in Microsoft Sentinel
This objective specifically tests your ability to use the Hunting blade, understand the query library, and differentiate between hunting and detection. Expect questions on:
Creating and managing hunting queries: You may be asked to identify the correct steps to create a custom query or to schedule a query.
Using MITRE ATT&CK tags: Questions may present a scenario and ask which tactic/technique filter to apply.
Bookmarks and incidents: Know how to escalate a bookmark to an incident and what information is preserved.
Livestream: Understand that it is a preview feature for continuous hunting, with separate billing.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: 'Hunting queries automatically create incidents when results are found.' Why: Candidates confuse hunting with scheduled analytics rules. Hunting queries only return results; you must manually create an incident or alert rule. 2. Wrong: 'All hunting queries run in real-time.' Why: They assume 'hunting' implies live monitoring. In reality, most queries are historical; only Livestream is near real-time. 3. Wrong: 'You need Global Administrator permissions to manage hunting queries.' Why: They overestimate permissions. Microsoft Sentinel Contributor is sufficient. 4. Wrong: 'Hunting query results are stored indefinitely.' Why: They don't know the default retention of 30 days in the HuntingQueryResult table.
Specific Numbers and Terms That Appear Verbatim
Default time range: 24 hours (when running a query manually).
Result retention: 30 days.
MITRE ATT&CK version: The exam may reference tactics like 'Initial Access', 'Execution', 'Persistence', etc.
KQL operators: summarize, where, join, extend, project are commonly tested.
Event IDs: For example, 4624 (logon), 4673 (sensitive privilege use), 4688 (process creation).
Edge Cases and Exceptions
If a query returns no results: The exam may ask what to do next. Answer: Adjust the time range or modify the query to be less restrictive.
Scheduling a query with a time range that exceeds the workspace retention: The query will fail for data outside retention. You must ensure the schedule aligns with data retention (default 90 days for Log Analytics, but can be extended).
Using Livestream: It is not available in all regions and requires enabling via preview features.
How to Eliminate Wrong Answers
Focus on the purpose: Hunting is proactive, not reactive. If an answer suggests automatic alerting, it's likely wrong.
Remember that hunting queries are KQL-based; if an answer mentions SQL or other languages, eliminate it.
Permissions: Look for 'Microsoft Sentinel Contributor' as the minimum role. 'Global Admin' is overkill.
Retention: Anything other than 30 days for hunting results is incorrect.
Hunting queries are KQL-based and stored in the Hunting blade; they do not automatically create incidents.
Built-in queries are updated via the Azure Sentinel GitHub repository; custom queries are workspace-specific.
You can filter queries by MITRE ATT&CK tactic and technique to find relevant queries.
Bookmarks preserve query results, timestamps, and notes; you can create incidents from bookmarks.
Default retention for hunting query results is 30 days in the HuntingQueryResult table.
To create a scheduled alert rule from a hunting query, use the 'Create Alert Rule' option from the results.
Livestream is a preview feature for continuous hunting; it uses separate billing based on data scanned.
Minimum permission to manage hunting queries is Microsoft Sentinel Contributor.
These come up on the exam all the time. Here's how to tell them apart.
Hunting Queries
Run manually or on a schedule to search for threats proactively.
Do not generate alerts or incidents by default.
Results are stored in HuntingQueryResult table (30-day retention).
Ideal for hypothesis-based investigation and ad-hoc hunting.
Can be promoted to an analytics rule after validation.
Scheduled Analytics Rules
Run automatically on a defined schedule (e.g., every 5 minutes).
Generate alerts and incidents when conditions are met.
Incidents are stored in the Incidents blade indefinitely (until resolved).
Ideal for continuous detection of known threats.
Cannot be demoted to a hunting query; they are separate.
Mistake
Hunting queries automatically generate security incidents.
Correct
Hunting queries only return results. To create an incident, you must either bookmark the result and then create an incident from the bookmark, or create a scheduled alert rule from the query.
Mistake
All hunting queries run in real-time on streaming data.
Correct
Most hunting queries run against historical data in the Log Analytics workspace. Only the Livestream feature (Preview) runs continuously on incoming data, and it incurs additional costs.
Mistake
You need Global Administrator permissions to create or edit hunting queries.
Correct
Microsoft Sentinel Contributor role on the workspace is sufficient to create, edit, and delete hunting queries.
Mistake
Hunting query results are stored forever.
Correct
Results are stored in the HuntingQueryResult table with a default retention of 30 days. You can adjust retention at the table level, but it is not indefinite by default.
Mistake
The built-in hunting queries are static and never updated.
Correct
Microsoft updates the built-in queries regularly via the Azure Sentinel GitHub repository. You can also download community-contributed updates.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
To create a custom hunting query, navigate to the Hunting blade in Microsoft Sentinel, click 'New Query', and fill in the name, description, MITRE tactics/techniques, and the KQL query. Optionally, set a schedule. The query will appear in the list. You must have Microsoft Sentinel Contributor role or higher.
Yes. When creating or editing a hunting query, you can set a frequency (e.g., every 6 hours). The query will run on schedule and store results in the HuntingQueryResult table. However, scheduled hunting queries do not generate alerts; they only store results for review.
A hunting query is used for proactive investigation and does not automatically generate alerts or incidents. A scheduled analytics rule runs on a schedule and creates incidents when the query returns results. You can convert a hunting query into an analytics rule by using the 'Create Alert Rule' option.
By default, hunting query results are stored in the HuntingQueryResult table for 30 days. You can change the retention period of this table in the Log Analytics workspace settings.
You need at least Microsoft Sentinel Contributor role on the workspace to create, edit, or delete hunting queries. Reader role can view and run queries but not modify them.
In the Hunting blade, you can filter queries by tactic (e.g., 'Credential Access') or technique (e.g., 'T1003'). This helps you find queries relevant to your hypothesis. When creating a custom query, you assign these tags so they appear in filters.
Livestream is a preview feature that allows you to run a hunting query continuously on incoming data, providing near real-time results. It is billed separately based on the amount of data scanned. It can be useful for monitoring high-priority threats.
You've just covered Threat Hunting Query Library — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?