1. Your Sentinel workspace has 85 active analytics rules. Your SOC lead reports that the team has "strong detection coverage." You run the ATT&CK coverage mapping query from TH0.1 and find that these 85 rules map to 22 distinct ATT&CK techniques. Your relevant M365 technique set is approximately 95 techniques. What is your detection coverage ratio, and what does the gap between rule count and technique coverage tell you?
Coverage ratio is 23% (22 ÷ 95). The 85 rules are clustered on 22 techniques — an average of nearly 4 rules per technique. Multiple rules detecting variants of the same technique provide depth but not breadth. 73 techniques have no detection rule at all. Rule count is a vanity metric; technique coverage is the operational metric. The 73 uncovered techniques are the hunting surface.
Coverage ratio is 89% (85 ÷ 95). The 85 rules cover most of the 95 relevant techniques. The SOC lead's assessment is correct.
Coverage ratio is 23%, but since Defender XDR's built-in detections cover the remaining techniques, the actual coverage is much higher. The gap is smaller than it appears.
The ratio cannot be calculated without also counting Defender XDR's built-in detections, which are not visible in the SecurityAlert query.
Correct. 22 ÷ 95 = 23%. The 85 rules map to only 22 techniques because many rules are variants covering the same technique (e.g., multiple phishing detection rules all map to T1566). Defender XDR's built-in detections add coverage but are tuned for high-confidence patterns and do not close the gap for techniques requiring environmental context. The 73 uncovered techniques represent real blind spots regardless of Defender XDR's contribution.
2. An analyst proposes a threat hunting program. The CISO responds: "Our mean time to respond is 3 hours. Our detection is working well — I do not see the need for hunting." Using the concepts from TH0.2, what is the flaw in this reasoning?
The CISO is correct — a 3-hour MTTR demonstrates effective detection and rapid response. Hunting would be redundant.
MTTR measures response speed after an alert fires, not how long the attacker was present before the alert fired. A 3-hour MTTR with a 30-day median dwell time means the SOC responds quickly to incidents it eventually detects — but the attacker had 30 days of unmonitored access before the response began. The metric that matters for hunting justification is MTTD (mean time to detect), not MTTR. Hunting compresses MTTD by finding compromises before any detection rule fires.
MTTR should be measured in minutes, not hours. A 3-hour MTTR is actually slow and indicates detection problems.
The flaw is that MTTR only measures incidents detected by rules. It should also include incidents discovered by external notification, which would raise the average.
Correct. MTTR and MTTD measure different things. MTTR = time from alert to resolution. MTTD = time from attacker's first activity to first detection. A fast MTTR says nothing about dwell time. The intrusions hunting finds are the ones with the longest dwell times — because no rule fired to start the MTTR clock.
3. A SOC analyst runs the dwell time query from TH0.2 and finds a median of 8 days, P75 of 22 days, and P90 of 67 days across 35 incidents. Which number should drive the hunting business case, and why?
The median (8 days), because it represents the typical incident and is below the industry benchmark of 10 days, suggesting detection is performing well.
The P75 (22 days), because it represents a balanced view between the median and the extreme.
The P90 (67 days), because it represents the long-tail intrusions where the attacker had extended undetected access. These are the intrusions that cause the most organizational damage — and they are the intrusions hunting is most likely to compress. A 67-day dwell time indicates an attacker who reached the entrenchment phase (identity infrastructure, backdoor accounts, complete data access). Additionally, this dataset only includes detected intrusions — the true P90, including undiscovered compromises, is likely higher.
All three numbers equally — the business case should present the full distribution.
Correct. The P90 drives the business case because it represents the incidents with the most damage potential — extended dwell time intrusions where the attacker had weeks or months of access. These are the incidents where hunting delivers the greatest dwell time compression and cost avoidance. The median is useful for benchmarking but understates the long-tail risk.
4. A detection engineer argues: "If we hire two more detection engineers and triple our rule output, we can close the detection gap without hunting." Using TH0.4, identify the structural limitation this argument overlooks.
The argument is correct — sufficient detection engineering investment closes the gap. Hunting is only needed when detection engineering is under-resourced.
The primary limitation is budget — tripling rule output requires tripling the detection engineering budget, which is unlikely to be approved.
More rules still encode anticipation (limitation 1) — each rule catches what its author predicted and misses variants. More rules still require ingested telemetry (limitation 2) — missing data sources remain blind. More rules still trade sensitivity for specificity (limitation 3) — thresholds create hiding places. More rules are still static (limitation 4) — they decay as techniques evolve. More rules still lack context (limitation 5). The limitations are properties of the detection method, not the team size. Tripling the team produces three times as many rules operating under the same five structural constraints.
The limitation is that detection rules take too long to build. The answer is to use AI to generate rules faster, not to hunt.
Correct. The five limitations are architectural — they persist regardless of team size, budget, or rule count. More detection engineers produce more rules, which is valuable for the known-known layer. But the known-unknown layer (hunting) and the structural limitations of rules remain unchanged.
5. Your organization discovers a BEC incident through an external report from a defrauded vendor. Investigation reveals the attacker was present for 28 days. The CFO asks: "How could hunting have prevented this?" Which response best frames hunting's value?
Hunting would have prevented the BEC by blocking the attacker's initial phishing email before it reached the user.
Hunting would not have prevented the initial compromise — that is a detection engineering and email security problem. Hunting would have discovered the attacker during the persistence or reconnaissance phase (days 1–5) by identifying the inbox rule manipulation, the OAuth consent, or the authentication anomaly before the attacker had 28 days to study the organization's financial processes and execute the fraud. At day 3, remediation is a password reset and session revocation. At day 28, remediation includes forensic investigation, vendor notification, potential financial recovery efforts, and regulatory reporting. Hunting compresses dwell time — it does not prevent initial access.
Hunting would have found the attacker by scanning all emails for fraudulent content, catching the BEC email before it reached the vendor.
Hunting cannot prevent BEC because BEC uses legitimate credentials and legitimate email. The only solution is stronger email authentication (DMARC, SPF).
Correct. Hunting compresses dwell time — it does not prevent initial access. The value is in discovering the attacker during the early phases of the intrusion before they achieve their objective. The cost differential between day 3 discovery and day 28 discovery — in remediation effort, financial loss, and regulatory exposure — is the hunting ROI argument.
6. You run a hunt for OAuth application consent abuse (TH6 campaign). After examining 90 days of AuditLogs data, you find no evidence of malicious application consent. Your SOC lead says the hunt was unproductive. Is the SOC lead correct?
Yes — the hunt consumed analyst hours and produced no findings. The time would have been better spent on alert triage.
No. The hunt produced a documented negative finding: "OAuth consent abuse was searched for across 90 days of AuditLogs data on [date]. No evidence of malicious application consent was found." This reduces organizational uncertainty, provides audit evidence of proactive monitoring, validates that current consent controls are effective (or that the technique has not been used — both are useful information), and establishes a baseline of normal consent activity for future comparison. Additionally, the hunting query, if validated, can be converted to a scheduled detection rule — permanent automated coverage of a technique that previously had none.
The hunt should be considered inconclusive rather than unproductive, because 90 days may not be a sufficient time window.
The hunt was unproductive this time, but should be repeated quarterly in case the technique appears later.
Correct. Negative findings have documented value — uncertainty reduction, compliance evidence, baseline establishment, and detection rule production. The fourth option (repeat quarterly) is also partially correct operationally, but the premise that the initial hunt was "unproductive" is wrong.
7. Your SOC is at Stage 2 maturity (active detection engineering, 45 analytics rules deployed, functioning alert pipeline). You want to start hunting but can only protect 4 hours every two weeks. Is this sufficient to begin?
No — 4 hours every two weeks is insufficient. Wait until you can protect at least 8 hours per week.
Yes. 4 hours every two weeks is enough for one structured hunt campaign per month. That produces approximately 6 campaigns in six months — with documented findings, detection rules, and measurable coverage improvement. Start with the TH3 coverage analysis (one session to build the backlog), then execute one campaign per month from the prioritized backlog. Scale up when the results justify it.
Yes, but only if the analyst is a dedicated threat hunter rather than a SOC analyst on rotation.
No — you should prioritize reaching 100+ analytics rules before starting hunting.
Correct. The minimum viable hunting program is modest — protected hours, a prioritized backlog, and a structured methodology. 4 hours every two weeks produces meaningful output. Waiting for ideal conditions delays value that compounds over time.
8. You calculate your detection coverage ratio at 28%. After 12 months of monthly hunting campaigns, each producing one new detection rule covering a new ATT&CK technique, your relevant technique set remains 95 techniques. What is your new coverage ratio, and what is the percentage improvement attributable to hunting?
The ratio depends on whether the detection engineering team also added rules during the same period. Hunting's contribution cannot be isolated.
28% + 12 rules = 40%. The improvement is 12 percentage points.
Original coverage: 28% (approximately 27 techniques covered out of 95). After 12 hunts each producing 1 new rule covering 1 new technique: 27 + 12 = 39 techniques. New ratio: 39 ÷ 95 = 41%. The improvement from 28% to 41% is a 46% relative improvement in detection coverage directly attributable to hunting. If the detection engineering team also added rules during the same period, the total improvement would be higher — but the 12 techniques added through hunting would not have been added otherwise, because they were in the known-unknown layer that detection engineering had not prioritized.
The ratio is still approximately 28% because the new rules replace old rules rather than adding net coverage.
Correct. 27 + 12 = 39 techniques covered. 39 ÷ 95 = 41%. The 13 percentage point absolute improvement (28% → 41%) represents a 46% relative improvement in coverage. This is the compounding return from TH0.7 — each hunt produces permanent coverage that did not previously exist.
9. Your organization has Defender XDR and Sentinel deployed, but AADNonInteractiveUserSignInLogs is not ingested into Sentinel. Which hunt campaigns from this course are impacted, and why does this specific table matter?
No campaigns are significantly impacted — SigninLogs covers all authentication events.
TH4 (authentication anomalies) and TH6 (OAuth abuse) are directly impacted. AADNonInteractiveUserSignInLogs records token refresh events and application-based sign-ins — this is where AiTM token replay appears. When an attacker steals a session token through AiTM and uses it to obtain new access tokens, the refresh events appear in this table, not in SigninLogs. Without it, the primary AiTM detection technique (token refreshes from IPs not matching interactive sign-in history) is impossible. Similarly, service principal authentication for OAuth applications appears here. This is the table gap described in TH0.4 (Limitation 2: rules require known telemetry) — a missing data source that creates a blind spot regardless of rule quality.
Only TH4 is impacted. TH6 uses AuditLogs for OAuth monitoring, not sign-in logs.
All campaigns are impacted equally because all campaigns use authentication data.
Correct. AADNonInteractiveUserSignInLogs is one of the most critical and most commonly missing tables in M365 hunting. Without it, AiTM token replay detection and service principal authentication monitoring are both blind. Enabling ingestion of this table is a prerequisite fix that the readiness assessment in TH0.8 would identify.
10. The detection pyramid (TH0.3) describes three layers. Your organization currently invests in detection engineering (known-known layer) only. A vendor offers a managed UEBA service that monitors behavioral anomalies continuously. If you purchase it, which layers of the pyramid are now covered, and which remains unaddressed?
All three layers are covered. Detection engineering handles known-known. UEBA handles known-unknown and unknown-unknown.
The known-known and unknown-unknown layers are covered. UEBA replaces the need for hunting entirely.
The known-known (detection rules) and unknown-unknown (UEBA anomaly detection) layers are now covered. The known-unknown layer — techniques that are documented but have no detection rule or behavioral baseline — remains unaddressed. UEBA flags statistical deviations from normal but does not formulate hypotheses, test specific threat techniques, or convert findings into detection rules. A known technique like OAuth consent phishing (T1098.003) with no detection rule and no behavioral anomaly signature sits in the known-unknown layer that only hypothesis-driven hunting can address. The UEBA service is valuable — it covers the top of the pyramid. But the middle layer (hunting) remains empty.
Only the unknown-unknown layer is covered by UEBA. Detection engineering and UEBA together still miss the known-unknown layer, but the known-unknown layer is not significant enough to require dedicated investment.
Correct. UEBA covers the unknown-unknown layer (behavioral anomalies without predefined hypotheses). Detection engineering covers the known-known layer (automated rules for anticipated patterns). The known-unknown layer — documented techniques with no rule and no anomaly signature — requires human-driven, hypothesis-based investigation. That is hunting. All three layers are necessary. UEBA and detection engineering together still leave the middle layer unmonitored.
