TH1.2 Scoping the Hunt

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

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:

1
2
3
4
5
6

// 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

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 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

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. Privilege escalation (TH7) should focus on accounts with administrative roles or PIM-eligible assignments. Insider threat (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 authentication anomaly 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).

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