11.2 The Sentinel Hunting Experience

The Sentinel Hunting Experience

Introduction

Required role: Microsoft Sentinel Reader (minimum for hunting queries). Sentinel Contributor for bookmark and hunt management.

Sentinel provides a dedicated Hunting blade — a purpose-built interface for managing hunting queries, tracking active hunts, creating bookmarks, and analysing results. While you can hunt using the Logs blade (raw KQL execution), the Hunting blade adds structure: query organisation, MITRE ATT&CK mapping, result tracking, and integration with the bookmark and incident systems.

The Hunting blade

Navigate to Sentinel → Threat management → Hunting.

The Hunting blade has four tabs: Queries, Bookmarks, Livestream, and Results (for search jobs).

Queries tab. Displays all available hunting queries — both built-in (from Content Hub solutions) and custom (created by your team). Each query shows: the query name, description, MITRE ATT&CK tactic and technique mappings, data sources required, and the last time results were found.

Filtering queries. Filter by: MITRE tactic (Initial Access, Execution, Persistence, etc.), data source (SigninLogs, SecurityEvent, CommonSecurityLog, etc.), and required data connectors. This filtering is critical — running a hunting query that references a table with no data is a waste of time. Filter by your connected data sources first.

Running a query. Select a query → click “Run query.” The results appear in a preview pane. If the query returns results, you can: view the full results in the Logs blade, add results as bookmarks, or promote findings to an incident.

Query result counts. The Queries tab shows the result count from the most recent execution of each query. Sort by result count (descending) to find queries that are currently returning results — these are your highest-priority investigation targets.

Built-in hunting queries

Content Hub solutions deploy hunting queries alongside analytics rules and workbooks. The Entra ID solution includes queries for: unusual sign-in patterns, dormant account activation, bulk directory operations, and OAuth application consent anomalies. The Defender XDR solution includes queries for: suspicious process chains, encoded PowerShell, unusual network connections, and email-based attack patterns.

Evaluating built-in queries. Not every built-in query is useful for your environment. Before running a query, review its KQL: does it reference tables that are populated? Does the time range make sense? Are the thresholds appropriate for your environment size?

Customising built-in queries. Clone a built-in query to create a custom version: select the query → click “Clone.” Modify the KQL to add your environment-specific filters (exclude known-benign patterns, adjust thresholds, add additional fields to the output). Save as a custom query.

Creating custom hunting queries

Built-in queries cover common patterns. Custom queries target your environment’s specific threat profile. Every investigation you conduct (Modules 11-15) produces KQL that should become a permanent hunting query.

Custom query structure: Name the query with a consistent convention: Hunt-[Tactic]-[Technique]-[Description]. Example: Hunt-InitialAccess-T1566-PhishingURLClickNewIP. Map the MITRE ATT&CK tactic and technique. Set the required data sources. Write a description that explains what the query finds and why it matters.

Converting investigation KQL to hunting queries. The AiTM correlation query from Module 12.5 (Step 4) — phishing click followed by sign-in from new IP — is an investigation query. To make it a hunting query: remove the incident-specific values (specific IP, specific user), parameterise the time range (ago(24h) instead of a fixed datetime), add exclusions for known-benign patterns (corporate IPs, VPN), and add output formatting (project relevant fields, add comments).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

// Custom hunting query: AiTM pattern — phishing click → new IP sign-in
// Tactic: Initial Access | Technique: T1566.002
// Data sources: UrlClickEvents, SigninLogs
// Description: Identifies users who clicked a URL in an email and then had
// a successful sign-in from a non-corporate IP within 30 minutes.
let CorporateIPs = _GetWatchlist('CorporateExternalIPs') | project SearchKey;
UrlClickEvents
| where TimeGenerated > ago(24h)
| where ActionType == "ClickAllowed"
| project ClickTime = TimeGenerated, AccountUpn, Url, UrlDomain
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(24h)
    | where ResultType == "0"
    | where IPAddress !in (CorporateIPs)
    | project SigninTime = TimeGenerated, UserPrincipalName, IPAddress,
        AppDisplayName, Location = tostring(LocationDetails.countryOrRegion)
) on $left.AccountUpn == $right.UserPrincipalName
| where SigninTime between (ClickTime .. (ClickTime + 30m))
| project AccountUpn, ClickTime, Url, UrlDomain,
    SigninTime, IPAddress, AppDisplayName, Location,
    GapMinutes = datetime_diff('minute', SigninTime, ClickTime)

Save this as a custom hunting query. Run it daily. Any results require immediate investigation — this pattern should not occur in normal operations.

Query management at scale. As your custom query library grows (you will produce 5-10 custom queries per investigation module), organise by: MITRE tactic (group Initial Access queries together, Persistence queries together), data source (queries that require Defender for Endpoint vs Sentinel-only), and priority (queries that run daily vs weekly vs monthly).

Exporting and sharing queries. Custom hunting queries can be exported as ARM templates or included in Content Hub solutions. If you manage multiple tenants (MSP scenario), export your query library and deploy to each tenant — ensuring consistent hunting coverage across environments.

Hunting dashboard daily workflow

The Hunting blade is not a tool you use once and forget. It is a daily operational dashboard.

Morning triage (5 minutes). Open the Hunting blade. Sort by “Results in last 24 hours” (descending). Review the top 10 queries with results. Most will be benign (known activity matching broad queries). Flag any with unexpected results for investigation.

Post-incident query deployment (15 minutes). After closing an incident, convert the investigation’s best KQL into custom hunting queries. Deploy them to the Hunting blade. This ensures the same attack pattern is hunted for proactively — not just detected reactively by analytics rules.

Weekly review (30 minutes). Review all custom hunting queries: are any consistently returning zero results (the pattern may have changed — update the KQL)? Are any returning excessive results (too broad — refine the filters)? Have new data connectors been added that enable new queries?

Query versioning and maintenance

Hunting queries are code. Like code, they require maintenance.

Version control. Store hunting queries in a Git repository alongside your analytics rules. Each query file includes: the KQL, the MITRE technique mapping, the required data sources, and a description of what the query finds. When you refine a query (better filters, new thresholds), the Git history preserves the evolution.

Query testing after Microsoft changes. Microsoft periodically renames tables, adds columns, or changes field formats. After a Sentinel or Defender update: run all custom hunting queries to verify they still execute without errors. Queries that reference renamed tables fail silently (zero results rather than an error) — which looks like “no threats found” when the reality is “the query is broken.” Include query validation in your monthly maintenance cycle.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Query health check: verify all hunting query tables are populated
let RequiredTables = datatable(TableName:string) [
    "SigninLogs", "AADNonInteractiveUserSignInLogs", "AuditLogs",
    "CloudAppEvents", "EmailEvents", "EmailUrlInfo", "UrlClickEvents",
    "DeviceProcessEvents", "DeviceNetworkEvents", "DeviceFileEvents"
];
RequiredTables
| extend HasData = iff(
    toscalar(union withsource=T * | where TimeGenerated > ago(1d)
        | summarize count() by T | where T == TableName | count) > 0,
    "✅ Populated", "❌ Empty")

Run this monthly. Any table showing “Empty” is a data gap — either the connector stopped ingesting, the table was renamed, or the licence that enables the data source expired.

Query retirement. When a hunting query is promoted to a permanent analytics rule (subsection 11.6, NRT promotion), do not delete the hunting query. Archive it with a note: “Promoted to analytics rule [rule name] on [date]. Hunting query retained for: manual deep-dive investigations that need broader output than the rule provides, and as the reference implementation for future rule tuning.” The hunting query and the analytics rule serve different purposes — the query remains useful even after the rule is deployed.

Creating custom hunting queries

Navigate to Sentinel → Hunting → Queries → New query.

Query name. Use a descriptive name that includes the technique and data source: “Hunt - Token Replay from New IP - SigninLogs” is better than “Suspicious sign-in hunt.”

Query description. Explain: what the query hunts for, what a positive result means, and what the analyst should do with the results.

KQL query. The hunting query. Unlike analytics rule queries (which must be optimised for scheduled execution), hunting queries can be complex and computationally expensive — they run on-demand, not on a schedule.

Entity mapping. Map entities in hunting queries just as you do in analytics rules. When you promote a hunting finding to a bookmark or incident, the entities are preserved.

MITRE ATT&CK mapping. Map the query to the technique it hunts for. This enables the MITRE ATT&CK-driven hunting workflow (subsection 11.9).

Data sources. Tag the query with the data sources it requires. This enables filtering — hunters can quickly find all queries that work with their connected data sources.

Organising the hunting query library

A workspace with 200+ hunting queries becomes unmanageable without organisation. Structure your library for rapid access during hunts.

Naming convention: [MITRE Tactic]-[Technique]-[Description]-[DataSource]. Examples: InitialAccess-T1566-PhishingURLClicks-EmailUrlInfo, Persistence-T1098-AdminRoleAssignment-AuditLogs, LateralMovement-T1021-RDPFromUnusualIP-SecurityEvent. This convention enables: alphabetical sorting by tactic, search by technique ID, and quick identification of the data source.

Folder structure in Content Hub: Content Hub does not support folders, but you can use tags and the naming convention to create virtual organisation. Tag queries with: the tactic (InitialAccess, Persistence, etc.), the data source category (Identity, Endpoint, Network, Email), and the hunt type (Hypothesis, IOC, Analytics, MITRE).

Query lifecycle management: Hunting queries should be maintained like analytics rules. Review quarterly: does the query still reference populated tables? Has the table schema changed? Is the query still relevant given the current threat landscape? Archive (disable) queries that target retired data sources or obsolete techniques.

The daily hunting triage workflow

Even when you are not actively hunting, the Hunting blade provides situational awareness. Add this to the daily shift-start routine (alongside the connector health check from Module 7.11 and the incident queue review from Module 10.5).

Step 1 (2 minutes): Check the Hunting dashboard. Review the result counts for all active queries. Are any queries showing new results since yesterday? Sort by “Results in last 24 hours.”

Step 2 (5 minutes): Review high-result queries. For each query with new results: is the result count expected (a broad query that always returns results) or unexpected (a query that normally returns zero suddenly showing 15 results)? Unexpected results warrant a brief investigation.

Step 3 (5 minutes): Check UEBA priorities. Review the top 5 entities by investigation priority score. Any score above 7 that was not there yesterday warrants a brief review.

Total daily hunting triage: 12 minutes. This is not a full hunt — it is a scan for obvious signals that trigger a full hunt if something looks wrong. It catches: sudden spikes in hunting query results (indicating a new threat pattern), UEBA anomalies that are not covered by analytics rules, and changes in the hunting landscape that inform hypothesis development.

The hunting dashboard

The Hunting blade’s overview shows: total queries available, queries with results, MITRE ATT&CK coverage of your hunting queries, and bookmarks created from hunts. This dashboard gives you a high-level view of your hunting programme’s coverage and activity.

Coverage gaps in hunting. Compare the MITRE ATT&CK coverage of your hunting queries against the coverage of your analytics rules (Module 10.11). Techniques that have neither analytics rules NOR hunting queries represent complete blind spots — no automated detection and no proactive hunting. These are your highest-priority gaps.

Building the hunting workbook

Create a dedicated workbook for hunting programme visibility — separate from the SOC operational dashboard (Module 10.9).

Tile 1: Hunting query results heatmap. Show all hunting queries with their most recent result count, colour-coded by recency and volume. Queries with new results in the last 24 hours in red. Queries with results in the last 7 days in yellow. Queries with no recent results in green.

Tile 2: Bookmarks created this month. Count and list of bookmarks, broken down by hunt type (hypothesis, IOC, MITRE, UEBA). Shows hunting productivity at a glance.

Tile 3: Hunt-to-rule conversion. Count of analytics rules created from hunting findings in the last 90 days. This is the key output metric — hunting that does not produce rules is incomplete.

Tile 4: MITRE coverage overlap. A Venn-style breakdown: techniques covered by analytics rules only, techniques covered by hunting queries only, techniques covered by both, and techniques covered by neither. The “neither” count is the most important number on the dashboard.

1
2
3
4
5
6
7
8

// Hunting productivity — bookmarks and incidents from hunts
HuntingBookmark
| where TimeGenerated > ago(30d)
| summarize
    TotalBookmarks = count(),
    PromotedToIncident = countif(isnotempty(IncidentId)),
    UniqueHunters = dcount(CreatedByName)
| extend PromotionRate = round(PromotedToIncident * 100.0 / TotalBookmarks, 1)

Sharing hunting queries across the team

In multi-analyst environments, hunting queries should be shared assets — not locked in individual analysts’ personal libraries.

Sentinel custom queries are shared by default. Any custom query created in the Hunting blade is visible to all users with Sentinel Contributor (or above) permissions. Use the naming convention from earlier in this subsection to ensure queries are discoverable.

Git-based query library. Store hunting queries in the same Git repository as analytics rules (Module 10.11 detection-as-code). This enables: version control (track changes to hunting queries), pull request review (another analyst reviews the query before deployment), and multi-workspace deployment (the same hunting queries deployed across all Sentinel workspaces).

Query documentation template. For each shared hunting query, include:

Purpose: “Hunts for [technique] targeting [entity type].” MITRE mapping: T[number] — [technique name]. Data sources: [table names]. Verify these connectors are active before running. Expected results: “Returns [description]. If zero results: [interpretation]. If results exist: [investigation steps].” Last validated: [date]. The query was last run and confirmed working. Author: [analyst name].

Hunting in the unified Defender portal

With the unified security operations platform (Module 7.9), hunting queries are accessible in the Defender portal’s Advanced Hunting alongside Defender XDR queries. The unified hunting surface lets you: run Sentinel hunting queries and Defender Advanced Hunting queries from the same interface, join Sentinel tables with Defender tables in a single query, and use Defender’s AI-assisted query builder for complex hunting queries.

When to hunt in Sentinel vs Defender. Use Sentinel’s Hunting blade when: you want to use the bookmark system, you are tracking hunts formally, or you are running queries against Sentinel-only tables (Syslog, CommonSecurityLog, custom tables). Use Defender’s Advanced Hunting when: you are hunting across Defender endpoint, email, and identity data with the full Advanced Hunting schema, or you want to use Defender’s query builder.

Knowledge check