In this section
Check My Knowledge
Scenario 1. You receive a threat intelligence report describing a new BEC campaign targeting your sector. The report names the threat actor and the technique (inbox rule creation for mail forwarding). You draft the following hypothesis: "Threat actor group Sapphire Sleet may be targeting our organization." Your team lead reviews it and says the hypothesis is not testable. What is the primary problem?
The hypothesis references a specific threat actor, which makes it too narrow a
Naming a threat actor is not the problem. The hypothesis lacks specificity, not excess specificity. An effective hypothesis names the technique and data source, not just the threat actor. "Sapphire Sleet may be targeting us" could mean anything — you cannot write a query against it.
The hypothesis should be based on detection gap analysis rather than threat intelligence b
Threat intelligence is one of six valid hypothesis sources covered in Section 1.1. The source is not the problem. The problem is that the hypothesis does not specify the technique, the telemetry, or the observable that would make it testable.
The hypothesis does not specify a technique, a data source, or what suspicious activity looks like — it cannot be translated into a query c
Correct. A testable hypothesis requires four properties: a specified technique, identified telemetry, a definition of what suspicious looks like, and a time window. "May be targeting our organization" meets none of these. A testable version would be: "Inbox rules forwarding mail to external domains created in the last 30 days in CloudAppEvents may indicate BEC persistence via T1114.003." That hypothesis can be directly translated into a KQL query. Section 1.1 defines these four properties.
The hypothesis should include a priority score before it can be considered testable d
Priority scoring (relevance, data availability, severity) determines which hypothesis to hunt first, not whether the hypothesis is testable. An untestable hypothesis cannot be prioritised because you cannot hunt it regardless of its score. Testability is a prerequisite for scoring, not a result of it.
Scenario 2. You are scoping a hunt for suspicious OAuth consent grants. Your 30-day query returns 12,000 consent events. A colleague suggests extending the time window to 90 days to capture long-dwell compromises. What is the correct response?
Extend to 90 days — longer time windows always improve hunt coverage a
Advanced Hunting enforces a 30-day maximum query window. Even if the platform allowed 90 days, a larger dataset does not automatically improve coverage. It increases the volume of noise that the analysis phase must process. Broader scope requires proportionally more analyst effort without a guaranteed increase in findings. Section 1.2 explains why the 30-day limit is a practical constraint, not a limitation.
Keep the 30-day window — Advanced Hunting enforces this limit, and the scope should be narrowed by tightening entity boundaries or technique focus rather than expanded by time b
Correct. The 30-day maximum is a platform constraint in Advanced Hunting. When results are too large, the correct response is to narrow other scoping dimensions: restrict the entity boundary (specific application types, specific departments), tighten the technique focus (high-risk permission scopes only), or refine the initial filter. The dual-window baseline in Section 1.2 uses the 30-day window efficiently by splitting it into a baseline period and a hunting period. Expanding time is not an option.
Switch to Sentinel log queries, which support 90-day lookback windows c
Sentinel does support longer lookback windows, but switching platforms mid-scope is a scoping decision that should be documented before the hunt begins, not improvised in response to volume. The larger issue is that 12,000 events in 30 days indicates the initial filter needs refinement — the same volume problem will exist in 90 days of Sentinel data, tripled. Narrow the scope first.
Run the hunt at 30 days but schedule a second hunt for the preceding 30-day period d
Running sequential 30-day hunts is a valid technique for historical investigation, but it does not solve the immediate problem of 12,000 results. The first hunt must be scoped tightly enough to produce a manageable candidate set. Adding a second hunt doubles the analyst workload without addressing the filtering problem. Narrow the scope dimensions before expanding the timeline.
Scenario 3. Your iterative query funnel has narrowed 280,000 sign-in events to 15 candidate entities. You are about to run multi-table correlation to check whether any of these entities also appear in email forwarding rules. A colleague suggests skipping the correlation step because "15 is already a manageable number — just review them manually." What is wrong with this approach?
Manual review of 15 entities would take too long to complete within the hunt time block a
Reviewing 15 entities manually is feasible in terms of time. The problem is not efficiency — it is that single-table review cannot see the cross-table behavioral pattern that distinguishes a genuine compromise from a benign anomaly. An entity that looks suspicious in sign-in logs alone may be explained or confirmed by its activity in email, endpoint, or application tables.
The funnel requires at least three narrowing steps before analysis can begin b
There is no rigid minimum number of steps. The four-step funnel (broad filter, enrich, correlate, extract) is a framework, not a mandatory sequence. However, skipping correlation specifically removes the cross-table context that transforms individual anomalies into behavioral patterns. The issue is what correlation provides, not the step count.
Advanced Hunting cannot display results from multiple tables in a single query c
Advanced Hunting fully supports multi-table joins, unions, and the materialize() operator for cross-table correlation. Section 1.3 demonstrates multi-table correlation using these operators. The platform is not the limitation here.
Single-table review cannot reveal the cross-table behavioral pattern that separates a genuine compromise from a benign anomaly — correlation adds context that manual review of sign-in logs alone cannot provide d
Correct. A suspicious sign-in alone is ambiguous. The same entity appearing in both suspicious sign-ins and email forwarding rule creation within the same time window is a behavioral pattern. Section 1.3 demonstrates this through the funnel that correlates sign-in anomalies with email, endpoint, and application activity. Skipping correlation means you are analysing entities in isolation, which produces either false positives (benign anomalies flagged without context) or missed findings (genuine compromises without the corroborating evidence that confirms them).
Scenario 4. During analysis, you enrich a candidate entity across five dimensions. The entity scores 2 out of 5 (suspicious temporal pattern and unusual permission scope, but normal geography, expected device, and consistent behavioral baseline). According to the confidence scoring framework, what is the correct next action?
Classify as noise and document the assessment — 2 of 5 is below the investigation threshold, but the enrichment record preserves the analysis for future reference a
Correct. The 3-of-5 threshold in Section 1.4 separates "investigate further" from "noise." At 2 of 5, the entity does not meet the threshold for escalation or continued investigation. However, the enrichment dimensions and scores are documented in the hunt record. If this entity appears in a future hunt, the prior assessment provides context. Documenting below-threshold findings is part of the documentation discipline from Section 1.7.
Escalate immediately — any suspicious dimensions warrant incident response involvement b
Escalating every entity with any suspicious dimension would overwhelm incident response with low-confidence referrals. The confidence scoring threshold exists precisely to prevent this. Temporal anomalies and permission scope deviations each have benign explanations (shift changes, legitimate role transitions). Without corroborating evidence from at least one more dimension, the signal is insufficient.
Lower the threshold to 2 of 5 for this hunt because the hypothesis is high priority c
Adjusting the threshold based on hypothesis priority undermines the objectivity of the analysis. The threshold separates signal from noise based on the strength of the evidence, not the severity of the hypothesized threat. A high-priority hypothesis does not make weak evidence stronger. If the evidence is insufficient at the standard threshold, the correct conclusion is that this entity is not confirmed, and the hunt continues to the next candidate.
Add more enrichment dimensions until the entity crosses the threshold d
Adding dimensions to push an entity over the threshold is confirmation bias. The five enrichment dimensions in Section 1.4 were selected because they provide the behavioral context needed to distinguish compromise from normal activity. If the standard dimensions do not produce a sufficient score, the evidence does not support the conclusion — seeking additional dimensions specifically to reach a predetermined outcome is the opposite of objective analysis.
Scenario 5. Your hunt concludes with a refuted hypothesis — no entity in your candidate set scored above the confidence threshold. A junior analyst on your team suggests deleting the hunt record since "nothing was found." Why is this wrong?
Hunt records are required for compliance purposes and must be retained for audit a
While compliance may require retention in some environments, this is not the primary reason to keep the record. The value of a refuted hunt is operational: it proves the technique was searched for and not present, and it produces a detection rule that automates future coverage. Compliance is a secondary benefit.
A refuted hypothesis produces a detection rule that automates the check going forward — the negative finding has permanent value because it confirms coverage and prevents the same technique from being re-hunted unnecessarily b
Correct. Section 1.5 explains that refuted hypotheses carry permanent value. The hunt proved the technique was not present during the hunting window, and the detection rule converted from that hunt (Section 1.6) automates the check going forward. The hunt record documents the methodology, which prevents duplication and provides peer reviewers with the evidence chain. Deleting the record loses both the coverage confirmation and the detection rule justification.
The hunt record is needed so the same hypothesis can be re-run with identical parameters next quarter c
Re-running the identical hunt with identical parameters would be redundant if a detection rule was deployed from the refuted finding. The detection rule automates the check continuously. The hunt record's value is in documenting the methodology and justifying the detection rule, not in serving as a template for repetition.
Without the record, the analyst cannot prove they spent the hunting hours productively d
Productivity tracking is a management concern, not a hunting methodology concern. The hunt record exists to document the evidence chain, support peer review, justify the detection rule, and prevent duplication. Treating it as a timesheet undermines its analytical purpose. Section 1.7 covers the three audiences the hunt record serves: the reviewing analyst, the peer reviewer, and leadership evaluating the program.
Scenario 6. You are converting a hunt query into a detection rule. During the false positive analysis, you discover that a service account triggers the rule 40 times per day due to legitimate automated operations. You add an exclusion for the service account. What additional step must you take before deploying the rule?
Increase the detection frequency to hourly so the rule catches anything the exclusion might miss a
Increasing frequency does not address the risk introduced by the exclusion. The excluded service account will not trigger the rule regardless of how frequently it runs. The problem is that an attacker could masquerade as the excluded account or route activity through it. Frequency adjustment is independent of exclusion risk assessment.
Remove the exclusion and accept the 40 daily false positives to avoid creating a detection gap b
Forty daily false positives would desensitise the SOC team to the alert within days, which is worse than a documented exclusion. Section 1.6 explains that the goal is not zero exclusions — it is exclusions that are documented, evidence-based, and evaluated for exploitation risk. A well-documented exclusion is safer than a noisy rule that analysts learn to ignore.
Document the exclusion with evidence from the false positive analysis and evaluate whether an attacker could exploit it — for example, by compromising the service account or routing malicious activity through it c
Correct. Section 1.6 requires that every exclusion be documented with evidence and evaluated for exploitation risk. The peer review checkpoint (Section 1.9, review point 3) specifically asks: "Could any exclusion be exploited by an attacker routing through an excluded IP range or masquerading as an excluded service account?" If the service account has weak credentials, no MFA, or excessive permissions, excluding it creates a blind spot an attacker can exploit. The exclusion may still be necessary, but the risk must be documented and mitigated.
Schedule the exclusion for automatic removal after 30 days to limit the detection gap window d
Automatic expiry is a useful pattern for temporary exclusions, but a service account generating 40 daily alerts is a permanent operational pattern, not a temporary condition. Removing the exclusion after 30 days reintroduces the same false positive problem. The correct approach is to evaluate and document the exclusion risk, not to set an arbitrary timer.
Scenario 7. You are the only security analyst at your organization. You have no peer available to review your hunts. You completed a hunt that confirmed a suspicious OAuth application with mailbox access. Before escalating, what is the most effective quality assurance adaptation for a solo practitioner?
Skip QA and escalate immediately — a confirmed finding should not be delayed by process a
Urgency does not override quality assurance. A false positive escalated as a confirmed finding wastes IR resources and damages the hunting program's credibility. The 24-hour delay in a time-delayed review is not appropriate for an active finding, but the structured self-review checklist takes minutes and catches errors before escalation. Section 1.9 provides three solo adaptations specifically for this situation.
Wait 24 hours and re-read the hunt record with fresh eyes before escalating b
Time-delayed review is one of the three solo adaptations from Section 1.9, but it is designed for closing hunts and deploying detection rules, not for confirmed active findings. A 24-hour delay on a confirmed malicious OAuth application with active mailbox access extends the compromise window. For an active finding requiring escalation, the structured self-review checklist provides immediate QA without the delay.
Run a quarterly batch review of the current quarter's hunts before escalating any findings c
Quarterly batch review identifies systematic patterns across multiple hunts. It is not a substitute for per-hunt quality assurance and definitely not appropriate for delaying an active finding. The three solo adaptations in Section 1.9 serve different purposes: self-review for immediate QA, time-delayed review for closing documentation, and quarterly batch for programme-level pattern detection.
Walk through the structured self-review checklist before escalating — checking each criterion against the evidence ensures no assumptions were missed, compensating for the absence of a peer reviewer d
Correct. The structured self-review checklist from Section 1.9 is the appropriate solo QA mechanism for an active finding. It takes minutes, not hours, and forces you to evaluate your work against explicit criteria rather than relying on the feeling that the evidence is sufficient. For an active compromise, you need immediate QA (checklist) rather than delayed QA (24-hour review) or periodic QA (quarterly batch). After the checklist confirms the finding, escalate without delay.
Scenario 8. At the quarterly leadership review, the SOC manager reports: "We conducted 18 hunts this quarter." The CISO asks whether the hunting program is effective. The metrics report shows 18 hunts completed, but no detection rules deployed, no findings documented, and no coverage improvement measured. What does this metric pattern indicate?
The program is measuring activity instead of outcomes — 18 hunts without detection rules, documented findings, or coverage improvement represent analyst hours with no lasting value a
Correct. Section 1.9 identifies this exact anti-pattern: measuring hunting by volume alone. Twelve hunts that each produce a documented finding or a deployed detection rule represent permanent value. Eighteen hunts with none of these outputs suggest the hunts are either not completing the full cycle (stopping before detection rule conversion) or not documenting findings properly. The four metrics that demonstrate value — detection coverage delta, dwell time compression, hunt completion rate, and findings per hunt — all measure outcomes, not activity. Volume without outcomes tells leadership nothing about effectiveness.
The hunting program is highly effective — 18 hunts with no findings means no threats are present in the environment b
No findings does not mean no threats. It could indicate that scoping was too narrow, hypotheses targeted well-monitored areas, or the analysis phase missed subtle indicators. More importantly, even refuted hypotheses should produce detection rules (Section 1.5 and 1.6). Zero detection rules from 18 hunts means the hunt-to-detection pipeline is broken. The hunts are not completing the full cycle.
The team needs to increase the cadence to weekly hunts to find more threats c
Increasing volume when the existing hunts produce no outcomes amplifies the problem rather than solving it. If 18 hunts produced zero detection rules, the issue is in the methodology (incomplete cycle, missing documentation, absent conversion step), not the frequency. Adding more hunts without fixing the pipeline produces more activity with no value.
The analyst team lacks the KQL skills needed to write effective hunt queries d
Skill deficiency is a possible contributing factor but not what the metric pattern directly indicates. The team completed 18 hunts, which means they wrote and ran queries. The missing elements are downstream: documented findings, detection rules, and coverage measurement. These are methodology and process gaps (Sections 1.5, 1.6, 1.7), not query writing gaps.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.