In this section

TH1.2 Scoping the Hunt

3-4 hours · Module 1 · Free

Operational Objective

An unscoped hunt either drowns in data or misses the target. Scoping defines what you search, where, when, and for whom — before the first query runs. It is the boundary that makes a hunt manageable and its results interpretable. This subsection teaches you to scope hunts that are narrow enough to produce actionable results and broad enough to catch the threat you are looking for.

Deliverable: The ability to define hunt scope across four dimensions (data sources, time window, population, success criteria) and to recognize the two scope traps that waste hunt hours.

⏱ Estimated completion: 25 minutes

Scope before you query

The hypothesis tells you what to look for. The scope tells you where to look. Skip this step and one of two things happens: you query everything, get 500,000 rows, and cannot distinguish signal from noise. Or you query too narrowly, get zero rows, and conclude the threat is absent when it was just outside your filter.

Scope has four dimensions. Define all four before writing the first KQL line.

Dimension 1: Data sources

// Verify the table has recent data before building a complex hunt query
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| count
// If this returns 0, the table is not ingested or is delayed
// Do not proceed with a hunt that depends on this table until confirmed

// Example: 30-day baseline, 7-day detection window
let baselineStart = ago(37d);  // 30 days before detection window
let baselineEnd = ago(7d);     // End of baseline = start of detection
let detectionStart = ago(7d);
let detectionEnd = now();
// Baseline query
let baseline = SigninLogs
| where TimeGenerated between (baselineStart .. baselineEnd)
| summarize NormalIPs = make_set(IPAddress, 20) by UserPrincipalName;
// Detection query — compare current against baseline
SigninLogs
| where TimeGenerated between (detectionStart .. detectionEnd)
| join kind=inner baseline on UserPrincipalName
| where not(IPAddress in (NormalIPs))
// Findings: sign-ins from IPs not seen in the baseline period

Expand for Deeper Context

Which tables do you need? The hypothesis determines this. "Authentication anomalies" means SigninLogs and AADNonInteractiveUserSignInLogs. "Inbox rule manipulation" means CloudAppEvents filtered to Exchange operations. "Endpoint persistence" means DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents.

Do not add tables speculatively. More tables does not mean better hunting. Each additional table adds query complexity, increases execution time (Advanced Hunting has a 10-minute timeout), and introduces noise from legitimate activity in that data source. Start with the minimum tables required to test the hypothesis. Add tables only when initial results indicate the investigation should expand.

Check before querying: is the required table actually populated in your workspace? The readiness assessment from TH0.8 covers this at the program level. At the individual hunt level, run a quick existence check:

Dimension 2: Time window

How far back do you search? The answer depends on the hypothesis and the data retention in your environment.

Standard hunt window: 30 days. This covers most active compromises. If an attacker has been present for more than 30 days, either the technique has produced other indicators that should appear in this window, or the attacker is sufficiently advanced that you need a targeted long-dwell hunt using Sentinel search jobs for archived data (covered in TH16).

Short hunt window: 1–7 days. Appropriate when the hypothesis is driven by a very recent TI report with fresh IOCs, or when hunting for a technique that produces high-volume data where 30 days would be unmanageable.

Extended hunt window: 90+ days. Appropriate for long-dwell hypotheses (APT, supply chain compromise) or when hunting for slow, low-volume techniques (one OAuth consent per week over three months). Requires Sentinel's long-term retention or search jobs if the standard retention has been exceeded.

The baseline window. Several campaign modules (TH4, TH8, TH13) use behavioral baselining — comparing recent activity against a historical norm. These hunts need two windows: a baseline window (typically 30–90 days of historical data to establish "normal") and a detection window (typically 1–7 days of recent data to find "abnormal"). The baseline window must predate the detection window — you cannot baseline on data that might contain the attack you are looking for.

Dimension 3: Population

Who or what are you searching? The full tenant? A specific department? Privileged accounts only? A specific device group?

Full tenant hunts are appropriate for technique discovery — "does this technique occur anywhere in our environment?" They produce comprehensive results but generate more noise. Most campaign modules start here.

Targeted population hunts are appropriate when the hypothesis applies to a specific group. Email-based threats (TH7) should focus on accounts with administrative roles or PIM-eligible assignments. Insider threats (TH13) focuses on a specific HR-flagged population. Data exfiltration (TH8) may focus on users with access to sensitive SharePoint sites.

Device-scoped hunts apply to endpoint campaigns (TH9, TH10, TH12). Servers versus workstations behave differently — a scheduled task created on a server is more likely legitimate than one created on a user workstation. Scoping by device type reduces false positives in endpoint hunts.

Narrowing the population reduces noise but increases the risk of missing a threat outside the population. The recommendation: start broad for the first run. If results are too noisy, narrow the population on subsequent iterations. Document why you narrowed — the excluded population represents a known blind spot in this particular hunt.

Dimension 4: Success criteria

How do you know the hunt is done? Without success criteria, hunts drift — the analyst keeps querying because there might be something else to find, long after the hypothesis has been adequately tested.

Success criteria answer two questions:

When have you found something? Define what constitutes a positive finding before you start. For the identity compromise hunt (TH4): a positive finding is a sign-in from a device and location not in the user's 30-day baseline, for a user account, that cannot be explained by known VPN configurations or legitimate travel. If you find this, the hunt has produced a result. Escalate or investigate further.

When have you found nothing? Define what constitutes adequate coverage. For the same hunt: if you have examined all active user accounts over a 30-day detection window against a 30-day baseline, and zero accounts show unexplained new device + new location combinations, the hypothesis is refuted for this time window. Document and close. You do not need to check again tomorrow — the detection rule you create from this hunt will monitor continuously going forward.

The two scope traps

Trap 1: Too broad. The hypothesis is about OAuth abuse, but the analyst decides to "also check for inbox rules while we are looking at CloudAppEvents." The hunt expands. Then they notice some suspicious sign-ins in the data and pivot to authentication analysis. Three hours later, the analyst has partial results in three domains, completed analysis in none, and documentation for nothing. Scope discipline means: test the hypothesis you started with. If you discover a new lead during the hunt, add it to the backlog as a separate hypothesis. Do not pivot mid-hunt.

Trap 2: Too narrow. The hypothesis specifies "inbox rules created via PowerShell." The analyst queries for New-InboxRule operations where the client is PowerShell. The query returns zero results. The analyst concludes that no malicious inbox rules exist. But the attacker used the Graph API, not PowerShell — and the query did not cover that path. The scope was too narrow for the hypothesis. The correct scope for "inbox rule manipulation" includes all creation methods: Outlook, OWA, PowerShell, EWS, and Graph API. Narrow the technique, not the detection surface.

Figure TH1.2 — Four scoping dimensions. Define all four before the first query runs. Scope discipline prevents both analysis paralysis (too broad) and false negatives (too narrow).

Try it yourself

Exercise: Scope one of your hypotheses

Take one of the three hypotheses you wrote in TH1.1. Define the four scope dimensions:

Data sources: Which tables will you query? Confirm they are ingested.

Time window: How far back will you search? Do you need a separate baseline window?

Population: Full tenant, or a targeted subset? If targeted, what is excluded and why?

Success criteria: What constitutes a positive finding? What constitutes adequate coverage for a negative finding?

Write the scope definition in 3–5 sentences. If you cannot define all four dimensions, the hypothesis needs refinement before you hunt.

⚠ Compliance Myth: "The longer the time window, the more thorough the hunt"

The myth: A hunt covering 365 days is more thorough than one covering 30 days. Longer windows catch more.

The reality: Longer windows produce more data and more noise without necessarily producing more signal. A 365-day hunt against SigninLogs may return millions of rows and overwhelm both the query engine (Advanced Hunting has execution time limits) and the analyst. The appropriate window depends on the technique: active credential abuse is detectable in 7–30 days. Long-dwell APT persistence may require 90+ days. C2 beaconing may be detectable in 7 days of network data. Longer is not better. Matched is better — match the window to the technique's expected dwell time and the data's noise level.

Extend this approach

If your Sentinel workspace has data retention beyond 90 days (configured via retention policies or Log Analytics archive), you can use Sentinel search jobs to hunt in archived data. Search jobs run asynchronously against long-retention storage, allowing hunts that span 6–12 months of historical data without the interactive query timeout constraints of Advanced Hunting. TH16 covers search jobs in detail. For most campaign modules in this course, the standard 30-day window in Advanced Hunting is sufficient.

📋 Operational Artifact — Hunt Scope Template

Hunt scope definition (complete before first query):

Hypothesis: [from TH1.1]

Data sources: [table names] | Confirmed populated: Y/N

Time window: Detection: [start] to [end] | Baseline (if needed): [start] to [end]

Population: [full tenant / targeted — specify group and exclusion rationale]

Success criteria — positive finding: [what constitutes evidence of compromise]

Success criteria — negative finding: [what constitutes adequate coverage to close the hunt]

References Used in This Subsection

Microsoft. "Advanced Hunting — Query Limits and Quotas." Microsoft Learn. https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-limits
Microsoft. "Search Jobs in Microsoft Sentinel." Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/search-jobs

Decision point

You have time for one hunt this quarter. Do you hunt for the threat in the latest advisory or for the gap in your ATT&CK coverage matrix?

Hunt the coverage gap. Advisories describe threats that are CURRENT but may not target NE. Coverage gaps describe techniques that COULD target NE and would succeed undetected. The coverage gap hunt produces a detection rule (closing the gap permanently). The advisory-driven hunt produces a point-in-time assessment (confirming the specific threat is not present today). Both are valuable — but the coverage gap hunt has a longer-lasting impact because it produces a permanent detection improvement.

A hunt query returns 200 results. You have 4 hours remaining in the hunt window. You can investigate 20 results thoroughly or review all 200 superficially. Which approach produces better hunt outcomes?

Review all 200 — you might miss a critical finding in the 180 you skip.

Investigate 20 thoroughly. A superficial review of 200 results produces 200 'looked at it, seemed okay' assessments that provide no investigative value and no documentation for future reference. A thorough investigation of 20 results produces: confirmed findings (true positives requiring remediation), confirmed benign patterns (documented baselines for future comparison), and inconclusive results (flagged for monitoring). Prioritise the 20 by: highest anomaly score, highest-value assets involved, and highest-risk users involved. Document why the remaining 180 were not investigated and recommend a follow-up hunt with refined query criteria to reduce the result set.

Investigate 20 — but only if they are from the most recent 24 hours.

Neither — refine the query first to reduce the result set below 50.

You understand the detection gap and the hunt cycle.

TH0 showed you what detection rules fundamentally cannot catch. TH1 gave you the hypothesis-driven methodology that closes that gap. Now you run the hunts.

10 complete hunt campaigns — from hypothesis through KQL execution through finding disposition, each campaign based on a real TTP
70 production hunt queries — every one mapped to MITRE ATT&CK and tested against realistic telemetry
Advanced KQL for hunting — UEBA composite risk scoring, retroactive IOC sweeps, and hunt management metrics
Hypothesis-Driven Hunt Toolkit lab pack — 30 days of realistic M365 and endpoint telemetry with multiple attack patterns seeded in
TH16 — Scaling hunts across a team — the operating model for a production hunt program

Unlock the full course with Premium See Full Syllabus

← Previous Next →