What Is Threat Hunting?
Threat Hunting Defined
Continue your mission
Threat Hunting Defined
# What Is Threat Hunting?
Threat hunting is the proactive, analyst-driven process of searching networks, endpoints, and datasets to uncover adversary activity that automated detection systems have failed to surface. It exists because no detection system is complete. Attackers who understand how security tools work will deliberately operate beneath detection thresholds, use legitimate software to move laterally, and blend their activity into normal traffic patterns. Threat hunting addresses this directly: rather than waiting for an alert, a trained analyst forms a hypothesis about how an attacker might behave in the environment, then actively searches for evidence that confirms or disproves it. The output is either a confirmed threat that is escalated to incident response, or validated data that improves detection rules going forward. Both outcomes strengthen the organization's security posture.
---
Threat hunting is a structured, iterative security practice in which analysts proactively search for indicators of compromise, attacker behaviors, or anomalous conditions that have not triggered existing automated controls. The core distinction from traditional security monitoring is intent and initiation: monitoring is reactive (alerts drive investigation), while threat hunting is hypothesis-driven (the analyst drives the search before any alert fires).
Threat hunting is not the same as incident response. Incident response begins after a known compromise is confirmed; threat hunting begins before confirmation, sometimes before any indication of a problem exists. It is also distinct from penetration testing, which simulates attacks in a controlled manner to identify vulnerabilities. Hunting works on live production data and looks for real adversary presence, not simulated activity.
Threat hunting is not threat intelligence analysis, though intelligence heavily informs it. Intelligence tells you what threats exist in the world; hunting tells you whether those threats are present in your specific environment.
Variants and subtypes include:
Each subtype serves a different purpose and requires different data sources, but all share the same foundational requirement: skilled analysts working with high-fidelity telemetry.
---
Threat hunting follows a repeatable cycle with five core phases: hypothesis formation, data collection and preparation, investigation, discovery, and feedback.
Phase 1: Hypothesis Formation
Every hunt begins with a question. Good hypotheses come from three sources: threat intelligence (a known threat actor is actively targeting organizations in your vertical), environmental knowledge (a subsidiary was recently onboarded with unknown security controls), or observed anomalies (a subtle pattern in authentication logs does not match expected behavior for that user population).
A well-formed hypothesis is specific and falsifiable. "Attackers might be in our network" is not a hypothesis. "An attacker using a compromised service account may be performing lateral movement via Windows Management Instrumentation (WMI) on weekday evenings between 7 PM and midnight" is a hypothesis that can be tested with available data.
Phase 2: Data Collection and Preparation
Hunting requires telemetry. The quality of the hunt depends entirely on the quality and completeness of available data. Key data sources include endpoint detection and response (EDR) logs, DNS query logs, network flow data, authentication logs (Active Directory, Okta, Azure AD), process execution logs, and command-line argument captures.
A common failure point is discovering mid-hunt that the required data is either not collected or not retained long enough. Organizations should maintain at minimum 90 days of searchable log data for effective hunting, with 12 months preferred for detecting slow-moving persistent threats.
Phase 3: Investigation
The analyst queries the data, looking for behavior consistent with the hypothesis. Techniques include:
powershell.exe is spawned by winword.exe on three endpoints out of 10,000, that is worth examining.lsass.exe from non-standard processes.Phase 4: A Concrete Scenario
An analyst receives intelligence that a financially motivated threat actor is actively deploying a remote access trojan (RAT) against financial services firms using spearphishing emails with malicious macro-enabled documents. The analyst forms a hypothesis: if this actor has targeted the organization, there may be evidence of macro execution leading to a child process calling out to an external IP.
The analyst queries EDR telemetry for any instance where a Microsoft Office process spawned cmd.exe or powershell.exe in the past 30 days. The query returns 14 results. Eleven are immediately explained by known administrative activity. Three are anomalous: winword.exe spawning powershell.exe, which then executed an encoded command and initiated an outbound connection to an IP address not seen elsewhere in network logs.
The analyst pivots to DNS logs and network flow data. The destination IP resolves to a domain registered 11 days prior with a privacy-protected registrar. The TLS certificate was issued 10 days prior. These are characteristics consistent with attacker-controlled infrastructure. The hunt has produced a confirmed incident, and incident response is engaged.
Phase 5: Feedback and Improvement
Regardless of outcome, every hunt should produce a detection artifact. If the hunt confirmed a threat, the indicators and behavioral patterns should be converted into detection rules or SIEM queries that will catch the same behavior automatically in the future. If the hunt found nothing, the data gap or telemetry coverage issue that limited the hunt should be documented and addressed.
This feedback loop is what differentiates mature threat hunting programs from one-off exercises. Each hunt improves the detection baseline.
---
The practical value of threat hunting is measurable: it reduces dwell time. Dwell time is the period between initial compromise and detection. According to Mandiant's M-Trends reporting, the global median dwell time has historically exceeded weeks or months in environments that rely solely on automated detection. Every day an attacker operates undetected is a day they spend escalating privileges, exfiltrating data, establishing persistence, and mapping the environment.
Organizations without a threat hunting capability are, in effect, trusting that their detection rules are comprehensive and that attackers will behave in ways the rules anticipate. That assumption is routinely wrong.
A documented real-world consequence: The 2020 SolarWinds supply chain compromise (also referred to as the SUNBURST campaign) remained undetected across thousands of organizations for months. The initial access mechanism bypassed traditional signature-based detection because the malicious code was delivered inside a legitimately signed software update. Organizations that relied purely on automated detection did not catch it until FireEye's security team identified anomalous behavior during their own proactive hunting activity. Specifically, FireEye analysts noticed an unexpected device registered under an employee's account during a multi-factor authentication review, which initiated a broader investigation. That discovery, driven by human analysis rather than automated alerting, ultimately led to the exposure of one of the most significant espionage campaigns in recent history.
Common misconceptions:
---
CDA addresses threat hunting within the Threat Intelligence and Detection (TID) domain of the Planetary Defense Model (PDM). The PDM is structured around a foundational principle: organizations must be able to see threats before threats materialize into confirmed incidents. Within TID, threat hunting is not treated as an optional advanced capability reserved for mature programs. It is treated as a core operational function, applied continuously and systematically across the client environment.
CDA's methodology, Predictive Defense Intelligence (PDI), directly informs how hunts are structured. Rather than hunting reactively in response to public advisories alone, CDA analysts develop forward-looking hunt packages based on intelligence about threats likely to target a specific organization given its sector, technology stack, geography, and known adversary interest. This means a financial institution in the United States receives hunt packages informed by actors known to target that sector, including TTPs mapped to MITRE ATT&CK and correlated with telemetry patterns specific to that client's environment.
Operationally, CDA differentiates its approach in three ways. First, every hunt produces a detection artifact: a query, rule, or behavioral indicator that improves automated detection going forward. Hunting is not a standalone exercise; it directly feeds the detection engineering function. Second, CDA maintains a hunt library built from prior engagements, industry intelligence, and original research. This means analysts are not starting from zero on each engagement; they are applying refined, tested hypotheses against new environments. Third, CDA treats telemetry coverage assessment as a precondition of effective hunting. Before executing a hunt, analysts validate that the required data sources are available, correctly configured, and retained at adequate depth. A hunt executed against incomplete telemetry produces incomplete results and false confidence.
The PDI methodology frames threat hunting as an intelligence cycle, not a one-time event. Each hunt generates intelligence about the environment that refines the next hypothesis, continuously tightening the gap between attacker activity and detection.
---
---
---
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Wiki Team
Found an issue? Help improve this article.