Threat hunting is the disciplined, human-led practice of proactively searching through networks, endpoints, and data to find malicious activity that automated detection tools have missed. It exists because no automated control catches everything. Adversaries deliberately design their techniques to evade signature-based detection, blend into normal traffic, and persist inside environments for weeks or months before triggering an alert. TID-B03 establishes the structural mission framework organizations need to run threat hunting as a repeatable program, not a one-time exercise. It defines objectives, assigns ownership, sets cadence, and produces measurable outputs that improve detection capability over time.
---
Threat hunting is a proactive security operation in which analysts formulate hypotheses about adversary behavior and then search for evidence confirming or disconfirming those hypotheses within the organization's environment. It operates on the premise that some threats are already present and have not been detected, rather than waiting for an alert to signal a problem.
Threat hunting is NOT the same as incident response. Incident response is reactive: an alert fires, a ticket opens, and analysts investigate a known event. Threat hunting begins with no confirmed event. Analysts start from intelligence, anomaly data, or behavioral assumptions and go looking for evidence that may or may not exist.
Threat hunting is also NOT the same as threat intelligence. Threat intelligence describes what adversaries do in general or what campaigns are active globally. Threat hunting applies that intelligence operationally inside a specific environment to determine whether those adversary techniques are present.
Variants of threat hunting include:
Hypothesis-driven hunting. Analysts start with a structured hypothesis based on MITRE ATT&CK techniques or threat intelligence reports. Example: "We hypothesize that an adversary using T1055 (Process Injection) would exhibit anomalous parent-child process relationships."
Indicator-based hunting. Analysts search for specific indicators of compromise (IOCs) such as known-malicious IP addresses, file hashes, or domain names obtained from threat intelligence feeds.
Machine-learning-assisted hunting. Analysts use anomaly detection outputs from security analytics platforms as starting points for manual investigation, combining automated pattern recognition with human judgment.
A mature program runs all three variants on a regular cadence rather than defaulting exclusively to indicator-based searches, which are the easiest to execute but also the least likely to catch sophisticated adversaries who rotate infrastructure frequently.
---
A structured threat hunting program follows a repeatable cycle. Each phase produces outputs that feed the next phase and improve the organization's detection capabilities over time.
Phase 1: Intelligence and hypothesis development.
Before analysts open a query tool, they need a hunting hypothesis. This hypothesis comes from two sources: external threat intelligence and internal environment knowledge. External intelligence includes reporting from government sources (such as CISA advisories), commercial threat intelligence providers, Information Sharing and Analysis Centers (ISACs), and open-source reporting on active campaigns. Internal knowledge includes knowledge of the organization's architecture, known assets, user behavior baselines, and prior incident history.
A well-formed hypothesis follows a structured format: "If an adversary were using [specific technique or tactic], we would expect to observe [specific artifact or behavior] in [specific data source]." For example: "If an attacker is performing credential dumping via LSASS memory access (ATT&CK T1003.001), we would expect to observe processes other than standard security tools accessing lsass.exe with PROCESS_VM_READ permissions in Windows Security Event Log data."
Phase 2: Data source identification and collection.
The hypothesis determines which data sources the analyst needs. Common sources include Windows Event Logs, EDR telemetry, network flow data, DNS query logs, proxy logs, and authentication logs from Active Directory or identity providers. Analysts must confirm that the required data is actually being collected and retained before proceeding. A hunt that requires 90-day EDR telemetry is impossible if retention is set to 14 days.
This phase frequently exposes logging gaps. Documenting those gaps is itself a valuable output of the hunting program, feeding directly into detection engineering and log management improvement efforts.
Phase 3: Active hunting and query execution.
Analysts execute structured searches against the identified data sources. In a SIEM or EDR console, this typically means writing queries in the platform's native language (KQL in Microsoft Sentinel, SPL in Splunk, YARA-L in Chronicle). Analysts look for deviations from established baselines, presence of specific artifacts, or behavioral patterns consistent with the hypothesis.
A concrete scenario: An analyst at a mid-size financial services firm reads an ISAC report describing a threat group targeting financial institutions using PowerShell-based lateral movement. The analyst forms the hypothesis that if this group is present, they would observe encoded PowerShell execution followed by network connections to external hosts from workstations. The analyst queries Splunk for PowerShell events with Base64-encoded command arguments (Event ID 4104) originating from non-server endpoints, filtered for a 30-day window. The query returns 12 results. Eleven are attributable to a known software deployment tool. One is unexplained: encoded PowerShell executed from an accounting workstation at 2:14 AM, followed by a DNS query to a domain registered six days prior. That single result becomes an incident investigation.
Phase 4: Analysis and triage.
Not every result is malicious. Analysts must triage findings against known good activity, asset context, and business process knowledge. This phase requires judgment, not just technical skill. The analyst documents each finding, its disposition, and the reasoning behind that disposition.
Phase 5: Output and feedback.
Every hunt, whether it finds malicious activity or not, produces outputs. These include: documented hypotheses tested, data gaps identified, new detection rules developed from confirmed findings, and updates to baseline definitions. When a hunt finds nothing, that is still useful information: either the hypothesized threat is not present, or the data needed to detect it is missing. Both outcomes inform next steps.
Over time, this cycle builds a library of tested hypotheses, a backlog of detection engineering work, and demonstrable evidence of proactive security operations.
---
The core security problem that threat hunting addresses is dwell time: the period between an adversary's initial access to an environment and the organization's detection of that access. According to Mandiant's M-Trends reporting, global median dwell time has decreased over the past decade but still measured in double-digit days, meaning adversaries routinely operate inside environments for weeks before detection. During that window, they establish persistence, expand access, identify valuable data, and prepare for their ultimate objective.
Automated controls catch a significant percentage of threats, but they are specifically less effective against adversaries who study defensive products and adapt their techniques accordingly. Advanced persistent threat (APT) groups and ransomware operators with significant operational resources design their tools and techniques to avoid triggering common detection signatures. A security program that relies entirely on automated detection gives sophisticated adversaries a reliable path to undetected persistence.
A real-world example of what happens without proactive hunting: the 2020 SolarWinds supply chain compromise. The adversary, later attributed to Russia's SVR intelligence service, operated inside victim environments for months in many cases before detection. The initial detection came not from any victim's internal security monitoring but from a third-party security firm (FireEye, now Mandiant) discovering the compromise through their own internal threat hunting. Multiple victims had all standard enterprise security controls in place. None of those controls detected the adversary. The techniques used, specifically DLL side-loading, token impersonation, and careful mimicry of legitimate administrator behavior, were specifically chosen to avoid triggering existing detection logic.
A common misconception about threat hunting is that it requires a large, specialized team and is therefore only feasible for enterprise organizations. In practice, a threat hunting program can begin with a single analyst dedicating structured time to hypothesis-driven investigation. The key is structure and repeatability, not team size. A small organization running two hunts per month with documented outputs and detection engineering follow-through will materially reduce dwell time compared to an organization of any size that relies entirely on automated alerting.
---
CDA approaches TID-B03 through the Planetary Defense Model (PDM), which organizes security work into domains that together produce a predictive, intelligence-driven security posture. The TID domain covers all threat intelligence and threat detection functions, with the governing methodology being Predictive Defense Intelligence (PDI): see the threat before it sees you.
Within PDI, threat hunting is not treated as an optional enhancement available only to mature programs. It is a foundational operational function. CDA's position is that a security program without regular threat hunting is operating reactively by design, regardless of how sophisticated its automated tooling is. Automated detection answers the question "Did this known thing happen?" Threat hunting answers the question "Is something happening that we don't yet have a rule to catch?"
CDA structures TID-B03 execution around three operational commitments:
First, cadence. Hunts must occur on a defined schedule, not opportunistically when time permits. CDA recommends a minimum of one structured hunt per two-week period, with hypothesis selection driven by current threat intelligence relevant to the organization's sector and architecture.
Second, output accountability. Every hunt produces a written output document regardless of findings. This document records the hypothesis, the data sources queried, the results, the disposition of each finding, and any detection engineering or logging improvement work generated. This output feeds CDA's PDM measurement framework and provides demonstrable evidence of proactive security operations for audit and compliance purposes.
Third, feedback integration. Confirmed findings from threat hunts feed directly into detection engineering work, producing new SIEM rules, EDR policies, or network monitoring signatures. Identified logging gaps feed into the organization's log management program. This feedback loop is the mechanism by which threat hunting improves the overall security program rather than remaining a standalone activity.
CDA also distinguishes between hunting campaigns and standing hunts. Hunting campaigns are time-bounded efforts focused on a specific threat actor, technique, or incident hypothesis. Standing hunts are recurring searches run on a regular schedule to check for specific persistent risks. Both have a place in a mature program.
---
---
---