10.2 The Sentinel Hunting Experience

The Sentinel Hunting Experience

Introduction

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

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 10.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 9.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 9.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 9.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 9.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