Perform threat hunting

Microsoft's own example is a query that lists the most uncommon processes running on your machines: you would not want an alert every time one of them runs, because most are innocent, but you do want to look at the list now and then. That is threat hunting: proactively searching data you already collect for threats that your security products and scheduled analytics rules (Microsoft Sentinel's form of the detection rule defined at the end of this principle) have not detected, usually by testing a hypothesis (a suspicion you can check against the data, such as "an attacker is reusing a stolen account"). Each tool in this domain answers one kind of question about a hypothesis, and the tools come in two toolsets: the Microsoft Defender XDR (extended detection and response) toolset in the Defender portal, and the Microsoft Sentinel platform toolset, built on Sentinel, Microsoft's cloud SIEM (security information and event management) service. The classic trap is expecting a hunt to keep watch: no hunting tool raises an alert on its own, so a finding you want caught every time must become a detection rule (a custom detection rule in Defender XDR, an analytics rule in Microsoft Sentinel; the next principle places each), a separate rule that runs the query at regular intervals and raises alerts when it matches.

Detect threats by using Microsoft Defender XDR covers the Defender XDR toolset's three tools, which that page calls hunting surfaces because each is a separate experience in the Defender portal: Advanced hunting runs KQL (Kusto Query Language) queries that return rows from event and entity tables, threat analytics pairs Microsoft researchers' reports on tracked threats with your own alerts, exposure, and indicators of compromise (IOCs), and Sentinel graph draws entities as nodes and their relationships as edges to show where an attacker could go next; despite its name, it sits in the Defender XDR toolset here, because you use it through the hunting graph and an incident's blast radius view in the Defender portal. When a finding there needs to alert, the Advanced hunting query becomes a custom detection rule. Detect threats by using the Microsoft Sentinel platform covers the Sentinel platform toolset's four tools, sorted by when they run and what they leave behind: hunting queries that you run interactively and whose results you keep as bookmarks (the selected result rows saved with the query that produced them) and hunts (Sentinel items that group queries, bookmarks, and comments around one hypothesis, not the activity of hunting itself), KQL jobs that query the Sentinel data lake (the low-cost, long-term storage tier) once or on a schedule and write the results to a table, summary rules that aggregate high-volume incoming logs in the background into a smaller table, and notebooks that run Python code for analysis KQL cannot express, together with the Sentinel MCP (Model Context Protocol) server, a Microsoft-hosted service that gives an AI agent tools to search tables and run KQL against the data lake. Interactive KQL queries that you run against the data lake on the KQL queries page in the Defender portal (the same editor where you create KQL jobs, and not the hunting queries above, which search recent data), KQL jobs, and notebooks that run on the data lake form the native data lake experience, which tenants that onboarded to the data lake before September 23, 2026 can keep using; tenants onboarding after that date are directed to Advanced hunting for interactive lake queries and to Microsoft Fabric for scheduled KQL pipelines and notebooks (what's new in Microsoft Sentinel), a split the Sentinel subtopic explains. When a finding there needs to alert, you create an analytics rule from the hunting query or over the result table, or a custom detection rule over the tables of a Sentinel workspace onboarded to the Defender portal, because custom detection rules are built from Advanced hunting queries.

Several tools in this domain run KQL, so the language rarely separates the answers; what separates them is which data the tool can reach and what remains when it finishes. Advanced hunting and hunting queries suit an interactive search of recent data, a recurring aggregation of a high-volume log belongs in a summary rule rather than in a query someone must remember to run, and a search over history kept in the data lake depends on the onboarding date set out in the previous principle: in the native data lake experience it can run as an interactive KQL query on the KQL queries page, while a KQL job writes results to a table on demand or on a schedule. Treat every result as a lead to confirm, not a verdict: an empty result can mean the data sits outside the tool's reach, and a path drawn by Sentinel graph or a threat that ranks high on exposure shows what could happen, so confirm what actually happened with event records in Advanced hunting before you act. The decision tree on this page asks these questions in order: does it need to alert, does it start from a tracked threat, does it need relationships rather than rows, does it need Python code, is it an interactive search of recent data, and is it an aggregation of recent high-volume logs; its last leaf follows the native data lake experience.