In this section
TH0.9 Common Hunting Myths
Section 0.8 assessed your organization's readiness across five prerequisites — data ingestion, detection rules, KQL proficiency, IR process, and protected time. You know whether you're ready to hunt. But readiness is not the only barrier. Misconceptions about what hunting is, what it requires, and what it produces prevent organizations from starting even when all five prerequisites are met. This section dismantles the seven most common myths with evidence from the sections you've already completed. These are the objections you'll hear when proposing or defending the program.
Scenario
Rachel Okafor presents the hunting proposal at the security steering committee. Phil Greaves has approved the budget. The readiness assessment is complete. Then Marcus Webb's peer at a partner organization leans in: "We tried hunting for six months and found nothing. Waste of time." Another attendee: "Isn't Security Copilot supposed to do this now?" A third: "We're a mid-size company — hunting is for banks and defense contractors." Rachel needs to answer each objection with data, not philosophy. The answers exist in what you've already learned.
The objections you will face
Every security capability has to survive organizational scrutiny. Hunting is no different — and in many ways, it faces a harder scrutiny than established capabilities like vulnerability management or endpoint protection. Those capabilities are understood. Hunting is newer, less standardized, and harder to explain in a two-minute elevator pitch. The following seven myths are real objections raised by SOC managers, CISOs, CFOs, and peer organizations when hunting programs are proposed. Each contains a kernel of truth that makes it persuasive, and a fundamental error that makes it wrong. Knowing both prepares you for the conversation you will have at the proposal meeting, the quarterly review, or the post-incident debrief where someone asks whether hunting would have caught the threat earlier.
Myth 1 — "You need a dedicated threat hunting team"
The kernel of truth: dedicated hunters produce more consistent output than analysts who hunt between alert triage sessions. A dedicated team develops deeper expertise and runs more complex, multi-week campaigns.
The error: dedicated teams are the ideal end-state, not the prerequisite. Most organizations that hunt effectively started with a rotational model — one senior analyst spending 4–8 hours per week on hunting duty while the rest of the team handles alerts. That rotational model, as Section 0.8 described, is sufficient for 12 structured campaigns per year. Each campaign produces documented findings and at least one detection rule. Twelve new detections per year, measurable coverage improvement, documented negative findings, and a growing body of environmental knowledge. That output justifies the program and builds the case for dedicating more resources later. Starting with "we need to hire a team" before proving the value inverts the sequence. Start with hours. Prove value. Then grow.
Myth 2 — "You need threat intelligence to hunt"
The kernel of truth: threat intelligence improves hypothesis quality. A hypothesis derived from a specific TI report about a threat actor targeting your industry is more likely to produce findings than a generic hypothesis about "suspicious sign-in activity."
The error: threat intelligence is one of several hypothesis sources. The others — ATT&CK coverage gaps, prior incident findings, environmental changes, detection rule failures, and peer community sharing — require no TI subscription at all. The ATT&CK coverage analysis taught in TH3 produces a prioritized hunt backlog using only your own detection data and the public ATT&CK framework. An organization with zero threat intelligence budget can run every campaign in this course by hypothesizing from coverage gaps and prior incidents. TI makes hunting better. It is not required to start.
Myth 3 — "If our EDR/XDR is good enough, we don't need to hunt"
The kernel of truth: modern EDR and XDR platforms — Defender XDR, CrowdStrike Falcon, SentinelOne — have extensive built-in detection capabilities, including behavioral analysis, machine learning models, and cloud-delivered protection that evolves continuously.
The error: built-in detections are tuned for high confidence across millions of tenants. They deliberately don't alert on behaviors that are ambiguous at scale — and those ambiguous behaviors are exactly where sophisticated attackers operate. Section 0.1 showed that enterprise SIEMs cover only 21% of ATT&CK techniques despite ingesting enough data to cover 90%. The gap isn't a failure of the tools. It's a structural limitation of automated detection. More critically, three of the five dominant M365 attack categories from Section 0.5 operate entirely in the cloud identity and application plane: AiTM session hijacking, OAuth consent abuse, and living-off-the-cloud. These produce zero endpoint artifacts. The world's best EDR cannot detect what it cannot see. Cloud-plane hunting requires cloud data sources — SigninLogs, AuditLogs, CloudAppEvents — that EDR does not collect.
In most M365 environments, cloud tables contain more events than endpoint tables but receive far less hunting attention. That imbalance is itself a gap — the attacker surface has shifted to the identity and application plane, but hunting effort remains concentrated on endpoints.
Myth 4 — "Hunting is just running queries and hoping to find something"
The kernel of truth: ad hoc hunting — opening the Advanced Hunting console and running random queries without a hypothesis — does look like "running queries and hoping." And it produces poor results, because without a hypothesis there is no way to know whether empty results mean "no threat" or "wrong query." Unstructured query sessions frequently generate false positives that waste analyst time and erode confidence in the program.
The error: structured hunting is hypothesis-driven. The Hunt Cycle taught in TH1 starts with a specific, testable hypothesis derived from a concrete source — a coverage gap, a threat report, a prior incident. The hypothesis defines the data sources, the query logic, and the success criteria before the first query runs. The analyst is not hoping to find something. They are testing a prediction. Each campaign has a documented scope, a defined time window, a methodology section, and an outcome that gets recorded regardless of whether the results are positive or negative. The difference between ad hoc querying and structured hunting is methodology, systematization, and documentation — the same difference as wandering a building versus conducting a systematic search with a floor plan, a checklist, and a report filed at the end.
Myth 5 — "We tried hunting and found nothing — it doesn't work for us"
The kernel of truth: some hunting programs are shut down after 3–6 months because every campaign returned negative findings. If the organization expected hunting to discover compromises weekly, the reality of mostly-negative findings feels like failure. Leadership that funded the program based on a promise of "finding threats" interprets negative results as the program not delivering.
The error: Section 0.7 covered this in depth. Negative findings are not failures. They are documented evidence that a specific threat technique was searched for and not found in the available telemetry. The value includes uncertainty reduction, baseline establishment, detection rule validation, and compliance documentation. If hunting consistently finds nothing, the explanation is one of three things: the organization genuinely has no active compromises for the techniques hunted (possible, especially for smaller environments with limited external exposure), the hunts are targeting the wrong techniques (fix the backlog prioritization using TH3's coverage analysis to focus on techniques with high environmental relevance), or the queries aren't sensitive enough (fix the query methodology using TH2's iterative refinement approach). The answer to "we found nothing" is to refine the program. Not to shut it down.
Myth 6 — "Hunting is only for large enterprises"
The kernel of truth: large enterprises have more data, more attack surface, more threat actor attention, and more resources to dedicate. The highest-profile hunting programs described at conferences tend to be at Fortune 500 scale.
The error: the detection gap exists in every M365 environment. A 500-user organization with Defender XDR and Sentinel has the same structural limitation as a 50,000-user organization: detection rules cover a fraction of relevant techniques, and the rest is unmonitored. The difference is scale, not applicability. A small organization running one campaign per month produces the same structural benefits — coverage improvement, dwell time compression, and detection rule production. The queries are the same. The data sources are the same. The methodology is identical.
Smaller environments are often easier to hunt in because the baselines are cleaner and the normal patterns are well-defined. In a 500-user tenant, a single anomalous sign-in pattern stands out sharply against a well-defined normal. In a 50,000-user tenant, the same anomaly requires statistical methods to isolate from noise. A small organization's analyst who knows the environment intimately — who recognizes every service account, every admin role, every OAuth application — has contextual advantages that no tool can replicate.
Myth 7 — "AI will replace threat hunting"
The kernel of truth: AI-powered security tools — Microsoft Security Copilot, vendor-specific AI assistants, purpose-built hunting platforms — are improving rapidly. They can summarize incidents, suggest investigation steps, generate KQL queries from natural language prompts, and identify statistical patterns in large datasets faster than human analysts.
The error: AI tools accelerate hunting. They do not replace it. An AI assistant can generate a KQL query from a natural language hypothesis — but it cannot formulate the hypothesis in the first place. That requires understanding the environment's specific risk profile, its detection gaps, its business context, and its attack surface. AI can identify statistical anomalies in a dataset — but it cannot determine whether the anomaly represents a business trip, a VPN configuration change, or an account takeover. It can summarize results — but it cannot decide whether to escalate to IR or document a negative finding. The judgment that hunting requires — contextual analysis, environmental knowledge, risk assessment, escalation decisions — is exactly what current AI tools don't reliably provide. AI makes the analyst faster. It does not make the analyst unnecessary. TH2 includes techniques for using AI assistants during hunt campaigns to accelerate query construction and result analysis — as tools, not replacements.
Figure TH0.9 — Seven common hunting myths and their corrections. Each myth is a real objection that arises when proposing or defending a hunting program.
The compliance angle
A related objection deserves separate treatment: "Our compliance framework doesn't require threat hunting, so we don't need to do it." Most compliance frameworks don't use the words "threat hunting." They do require "proactive monitoring," "continuous improvement of detection capabilities," or "regular assessment of security controls."
PCI DSS 4.0 Requirement 11.3 requires penetration testing but also expects ongoing monitoring improvements. ISO 27001 Annex A Control A.5.25 requires assessment of information security events — which means you need evidence that you actively looked for events, not only that you responded to alerts. SOC 2 CC7.2 requires monitoring for anomalies. NIST CSF 2.0 DE.CM expects continuous monitoring across the environment.
Hunting produces documentation that satisfies each of these requirements more convincingly than alert triage alone, because it demonstrates proactive security activity rather than reactive response. A hunt report documenting the hypothesis, data sources queried, methodology, findings, and resulting actions is exactly the evidence auditors look for when evaluating whether an organization actively monitors its environment. The question is not "does our framework require hunting?" The question is "does our framework require us to actively look for threats?" The answer is almost always yes.
The hunting proposal gets seven minutes at the steering committee. One attendee raises Myth 3 ("our XDR covers it"). The analyst responds with "hunting is important for defense in depth" — a true statement that answers nothing specific. The attendee is unconvinced. The committee tables the proposal. The correct response is concrete: "AiTM session hijacking, OAuth consent abuse, and cloud-native exfiltration operate entirely in the identity and application plane. They produce zero endpoint artifacts. XDR behavioral models don't see them because the evidence exists in SigninLogs and CloudAppEvents, not DeviceProcessEvents. We need cloud-plane hunting to address the 79% of ATT&CK techniques our rules don't cover." Evidence wins the argument. Generic appeals to "defense in depth" do not.
Threat Hunting Principle
Every hunting myth contains a kernel of truth that makes it persuasive and a fundamental error that makes it wrong. Your job is to know both — the truth that gives the objection its power, and the error that makes the objection incorrect. The response to each myth is not opinion ("hunting is important"). The response is evidence: coverage ratio data, dwell time statistics, cost comparisons, and structural analysis of what detection tools can and cannot see. The objection you can't answer with data is the objection that kills the program.