Where Hunting Fits

Three disciplines, one data lake

Detection engineering, incident response, and threat hunting operate on the same data. They use overlapping tools and sometimes the same analysts. Confusion about where one ends and another begins is understandable. What distinguishes them is not the tooling. It is the trigger, the method, and the output.

Detection engineering is triggered by a coverage gap. A technique is documented, the data exists, and no rule covers it. A detection engineer writes a KQL rule, tunes it against the environment's false positive patterns, validates it in report-only mode, and promotes it to production. Output: a deployed analytics rule that generates alerts automatically when the pattern appears. The detection engineer's success metric is the number of ATT&CK techniques covered at an acceptable false positive rate.

Incident response is triggered by an alert or an external notification. Something has already happened. The IR team's job is to determine what happened, how far the attacker got, what data was accessed, and how to stop it. The method is forensic investigation: scoping the incident, collecting evidence, identifying affected assets, containing the threat, eradicating the attacker's access, and remediating. Output: a resolved incident with documented findings, timeline reconstruction, containment actions, and remediation steps. The IR team's success metric is time from detection to containment.

Threat hunting is triggered by a hypothesis. No alert has fired. No external notification has arrived. A hunter believes a specific threat may exist based on intelligence, coverage gap analysis, environmental change, or a pattern observed during triage. Its method is hypothesis-driven investigation: formulating what to look for, identifying which data sources contain the relevant telemetry, querying those sources, analyzing the results for patterns that confirm or refute the hypothesis, and documenting everything. Output: a documented finding (positive or negative), a behavioral baseline that defines what normal looks like for that activity, and a detection rule that automates the finding permanently. The hunter's success metric is coverage improvement and detection rules produced.

Six handoffs connect three disciplines in a reinforcing cycle. Solid arrows show the primary flow. Dashed arrows show feedback loops.

The six handoffs

Six explicit handoffs connect the three disciplines that form a reinforcing cycle. Breaking any handoff breaks the cycle.

Detection engineering hands off to incident response when a rule fires and creates an incident. This is the most familiar handoff and the one most organizations implement well. The rule fired, the incident exists, the IR team investigates. Detection engineering also hands off to hunting when a coverage gap analysis reveals techniques with no detection rule and insufficient data for automated detection. That gap becomes a hunting hypothesis because the technique cannot be reliably automated but can be investigated through proactive querying.

Incident response hands off to detection engineering when an investigation discovers a technique that should have been detected automatically but was not. IR's finding becomes a rule requirement: "We discovered AiTM token replay in this incident. We need an analytics rule that catches it next time." IR also hands off to hunting when an investigation reveals indicators that related techniques may be active in the environment but were not part of the current incident scope. Perhaps the attacker established OAuth persistence through consent phishing, but the scope of the IR engagement was limited to the compromised account. Whether other accounts were targeted through the same campaign is a hunting question, not an IR question.

Hunting hands off to detection engineering when a hunt produces a query that identifies a threat pattern. Hunting queries become the foundation for analytics rules that monitors permanently. This is the hunt-to-detection pipeline, the mechanism through which known-unknowns become known-knowns. Hunting also hands off to incident response when a hunt discovers an active compromise. Positive findings become incidents with a head start: the hunter has already identified the affected accounts, the timeline, and the technique, giving IR a scoped starting point rather than a raw alert.

At NE, Rachel structures the handoffs explicitly. Priya's hunt campaigns produce documented hypotheses, queries, and findings. Each finding with a usable detection pattern goes to Marcus for rule conversion. Each finding indicating active compromise goes to Tom for incident response. Each IR investigation that reveals an uncovered technique goes back to Priya for the next hunt cycle. The cycle is continuous, and Rachel tracks the handoffs in the quarterly report: three hunts produced two detection rules and one IR escalation this quarter, and two IR investigations produced three hunting hypotheses for next quarter. The numbers prove the disciplines are connected, not duplicated.

Without explicit handoffs, the three disciplines drift into isolation. Detection engineering writes rules without knowing what IR found. IR closes incidents without feeding uncovered techniques to hunting. Hunting produces findings that never become detection rules. Each discipline generates value in isolation, but the compounding value of the cycle is lost.

The objections you will face

When you propose a hunting program, you will encounter resistance grounded in misunderstandings about what hunting requires. Knowing the objections in advance lets you address them with evidence rather than improvisation.

"You need a dedicated threat hunting team." You do not. The minimum viable hunting program is one analyst with four protected hours per week, the ability to write intermediate KQL, and a prioritized backlog of hypotheses. Priya runs NE's hunting program alongside her SOC duties. Dedicated hunting teams exist at mature organizations with annual budgets that support them, but every program starts with a SOC analyst on protected rotation time. What matters is not whether you have a hunting team. What matters is whether one analyst can protect four hours per week, execute the Hunt Cycle methodology, and produce documented output that justifies more time.

"You need threat intelligence feeds to hunt." Threat intelligence makes hunting more targeted, but it is not a prerequisite. The three hypothesis sources that drive a hunting program are: coverage gap analysis (which ATT&CK techniques have no detection rule in your environment), environmental change (what new applications, users, or configurations were deployed this quarter), and incident patterns (which techniques appeared in recent investigations). None of these require paid intelligence subscriptions. The ATT&CK framework itself is free and publicly maintained. The MITRE ATT&CK Navigator that you used for the coverage ratio in Section 0.1 is the backlog generator. Intelligence feeds refine the priority order. They do not create the backlog.

"If our EDR/XDR is good enough, we don't need to hunt." Four of the five threat categories from Section 0.3 operate entirely in the cloud: AiTM session hijacking, OAuth persistence, living-off-the-cloud, and cross-plane exploitation. EDR has zero visibility into techniques that do not involve endpoint processes or files. Storm-2949's entire data exfiltration campaign never touched an endpoint in a way EDR would flag. EDR is a detection tool for endpoints. Hunting is an investigation method for the environment.

"We tried hunting and found nothing. It doesn't work for us." A hunt that finds no evidence of the hypothesized activity is not a failed hunt. It is a documented negative finding that provides four things: uncertainty reduction (the technique is not currently active), audit evidence (the organization proactively tested for it), a behavioral baseline (you now know what normal looks like for that data), and a detection rule (the query converts to an automated rule that monitors permanently). Section 0.5 covers the ROI of negative findings in detail.

"Hunting is just running queries and hoping to find something." Hunting is hypothesis-driven investigation with a structured methodology. The Hunt Cycle that Module 1 teaches has six defined steps: hypothesis formulation, data identification, query execution, analysis, documentation, and rule conversion. Each step produces a documented artifact. The hypothesis is scoped before a single query runs. The data sources are identified before the KQL editor opens. The results are analyzed against the specific hypothesis, not browsed for anything interesting. And the documentation captures the finding, the methodology, and the detection rule, regardless of whether the finding was positive or negative. The methodology distinguishes hunting from ad-hoc querying the same way a scientific experiment differs from casual observation.

"AI will replace threat hunting." AI-assisted analysis tools accelerate specific hunting tasks: summarizing large result sets, suggesting related queries, correlating across data sources. Microsoft's Security Copilot and Sentinel's AI features are useful accelerators for investigations already in progress. They do not replace hypothesis formulation, environmental context, or the judgment that distinguishes a finding from a coincidence. A hunter who asks Copilot "summarize this user's activity over the past 7 days" is using AI as a data retrieval tool. The hunter decided which user to investigate, why, and what the results mean. AI tools assist the hunter the same way KQL assists the hunter: execution tools that accelerate the work, not decision-making substitutes that perform it. The five cognitive skills from Section 0.7 are precisely the skills AI does not replicate.

The compliance angle

Many compliance frameworks require evidence of proactive threat monitoring. ISO 27001 Annex A control A.8.16 requires monitoring of networks, systems, and applications for anomalous behavior. NIST CSF 2.0 DE.CM (Continuous Monitoring) requires monitoring the computing environment for cybersecurity events. PCI DSS 4.0 requires intrusion detection techniques beyond automated alerting. NIS2 Article 21 requires risk management measures including incident handling and network security monitoring.

A hunting program with quarterly reports showing campaigns completed, detection rules produced, and coverage improvements provides stronger audit evidence than a policy document stating "the organization conducts threat monitoring." The quarterly report is the proof that the policy is implemented.

Rachel uses this at NE. During the annual ISO 27001 audit, the auditor asks for evidence of A.8.16 compliance. Instead of pointing to a policy document, Rachel produces four quarterly hunting reports: 12 campaigns completed, 12 detection rules deployed, coverage improved from 23% to 35%, two active compromises discovered and remediated. The auditor grades the control as "effective" without further questions. The same evidence satisfies the Cyber Essentials Plus assessor and the insurance underwriter reviewing NE's cyber policy renewal. Compliance alone rarely justifies a hunting program, but it removes a barrier that skeptics use to defer the investment.