Threat Hunting Playbook: A Step-by-Step Guide for Security Teams

Every hunt starts with a hypothesis: a testable statement about a threat actor technique that might be present in your environment. Hypotheses without threat intelligence grounding waste hunting time on low-probability scenarios. Hypotheses grounded in current threat intelligence direct hunting toward techniques that adversaries targeting your sector are actively using.

Four inputs should drive hypothesis generation. First, threat intelligence relevant to your sector and technology stack: if your organization is a financial institution and a recent Mandiant report documents a threat group targeting financial sector networks using a specific living-off-the-land technique, that technique is a high-priority hypothesis. Second, MITRE ATT&CK: ATT&CK provides a comprehensive taxonomy of adversary techniques with detection notes and data source requirements. For each tactic (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration), ATT&CK lists specific techniques that can be translated directly into hunt hypotheses. Third, your own detection gaps: techniques for which you have no existing detection rules are the highest-value hunt targets because automated detection is provably absent. Fourth, prior hunt findings and red team results: if a previous hunt found evidence of credential dumping activity or a red team exercise demonstrated that a specific technique was undetected, follow-up hunting in those technique areas is high-yield.

A well-formed hunt hypothesis follows the structure: 'If [threat actor type] with [objective] has been present in our environment, I would expect to find evidence of [specific technique] in [specific data source].' This structure makes the hypothesis testable and defines the data required before the hunt begins.

The quality of a threat hunt is bounded by the quality and completeness of available telemetry. Hunting for credential dumping with no EDR telemetry, no process creation logging, and no LSASS access events is not possible regardless of analyst skill. Data source validation must occur before the hunt begins.

For endpoint hunting, the minimum data requirements are: process creation events with full command lines (Windows Event ID 4688 with command line auditing enabled, or EDR process telemetry); network connection events from endpoints (source/dest IP, port, process); file creation, modification, and deletion events for sensitive paths; registry modification events for persistence-relevant keys; PowerShell script block logging (Event ID 4104); and module load events for detecting reflective loading and injection techniques.

For identity and authentication hunting, required data includes: all logon events (4624, 4625, 4648); Kerberos ticket requests and service ticket events (4768, 4769, 4771); NTLM authentication events (4776); and Active Directory changes (4720, 4728, 4732, 4756 for group membership changes).

For network hunting, required data includes: full DNS query logs (not just failed queries); proxy logs with full URLs and response codes; NetFlow or PCAP for east-west traffic; and firewall logs with connection state information.

Retention is as important as collection. Attackers with median 24-day dwell times may have established persistence two to three weeks before the hunt begins. Hunting with seven days of logs misses evidence from most of the dwell period. The minimum useful hunting retention is 90 days; 180 days or more is recommended for hunts targeting APT dwell periods.

Threat hunting uses a defined set of analytic techniques. Selecting the right technique for each hypothesis improves hunt efficiency and reduces the time spent processing irrelevant data.

Stack counting (frequency analysis) is the most widely applicable technique. Sort every instance of a value in a dataset by frequency. The items at the extremes (very common or very rare) often warrant investigation. Process creation events where a specific parent/child process combination appears only once across your entire fleet in 30 days is worth investigating. PowerShell commands that appear once in three months among 5,000 endpoints are worth examining.

Clustering groups similar events to identify outliers. Clustering endpoint behavior by process tree patterns identifies systems that exhibit unusual behavior compared to their peer group. A finance workstation running the same processes as a developer workstation is an outlier worth investigating.

Baselining establishes the normal distribution of a value and flags deviations. Time-based baselining (processes running at 3 AM that never run at 3 AM in baseline data) and volume-based baselining (DNS query volume from a single endpoint 10x above baseline) surface anomalies that rule-based detection misses because they are statistically defined rather than signature-defined.

Graph analysis maps relationships between entities (users, systems, IP addresses, processes) to identify unusual connection patterns. This is particularly effective for lateral movement hunting: visualizing which accounts authenticated to which systems in a time window reveals unusual access chains that tabular queries miss.

IOC-based pivoting starts from a known indicator (an IP address, domain, file hash, or username) and pivots through related data to identify additional activity from the same actor or campaign. IOC-based hunting is the most reactive technique but is useful when starting from threat intelligence that includes specific indicators.

TTP-based hunting maps a specific ATT&CK technique to the data patterns it produces and searches for those patterns. For example, hunting for T1003 (OS Credential Dumping) searches for LSASS memory reads (Sysmon Event ID 10), outbound network connections shortly after mimikatz-associated process execution, or SAM database access events from non-system accounts.

When a hunt query returns suspicious results, the analyst transitions from hunting to investigation. The investigation goal is to determine: is this a true positive (actual malicious activity) or a false positive (legitimate but unusual behavior); if true positive, what is the scope and timeline of the activity; and what other evidence exists in other data sources that corroborates or contradicts the initial finding.

Investigation methodology follows the same patterns as alert-driven investigation: pivot from the initial finding through process trees, network connections, file system activity, and authentication events to build a timeline of the attacker's activity. Document every pivot, every query, and every finding, including negative findings. Hunt investigations frequently reveal that what appeared to be a single suspicious event is actually a pattern of activity spanning weeks and multiple systems.

Documentation is the most underinvested part of hunting programs. Every hunt should produce: the hypothesis tested, the data sources and time range queried, the analytic technique applied, all queries and their syntax, the findings (positive or negative), the disposition (confirmed true positive, false positive, or inconclusive), and recommendations for follow-up hunts or detection improvements.

Converting hunt findings into detection improvements is the mechanism by which hunting raises the overall security baseline. Every confirmed true positive finding, and every technique that was huntable but undetected by existing rules, should produce a new detection rule, a refinement to an existing rule, or a documented data source gap that needs to be addressed. A hunting program that does not systematically feed findings back into detection engineering produces the same value indefinitely rather than raising the baseline over time. Track hunt coverage against the ATT&CK matrix to measure which techniques are covered by automated detection, which are covered only by periodic hunting, and which have no coverage at all.

A mature threat hunting program requires defined processes, dedicated analyst capacity, adequate tooling, and leadership commitment to an activity that produces value over time rather than through individual discrete incidents.

The minimal viable threat hunting program is one dedicated analyst running two to four structured hunts per month against a defined hypothesis backlog, with outputs systematically fed into detection engineering. This level of program produces measurable value: reduced MTTD, increased detection coverage, and periodic discovery of active threats that automated detection missed.

Hunting tooling is separate from alert-driven SOC tooling. Hunters need: a SIEM or data lake capable of long-retention, high-volume search with flexible query syntax (Splunk, Elastic, Google SecOps, Microsoft Sentinel); visualization tools for graph analysis (Maltego, Neo4j, or built-in SIEM graph features); threat intelligence feeds to drive hypothesis generation; and a hunt tracking system to manage hypothesis backlogs, document findings, and track ATT&CK coverage.

Hunting frequency should be calibrated to threat intelligence. After a major threat actor advisory relevant to your sector, run a targeted hunt within 48 hours. Structured hypothesis-driven hunts should run monthly at minimum. Unstructured threat intelligence analysis and data exploration should be a continuous background activity for hunters in between structured hunts.

Measuring hunting program effectiveness uses the same metrics as detection engineering: MTTD for threats discovered by hunting versus automated detection; percentage of ATT&CK techniques with automated detection coverage versus hunting-only coverage; number of new detections created per hunt; and confirmed true positive rate per hunt (a hunting team that never finds confirmed malicious activity is either operating in an environment with no threats, or hunting against hypotheses that are not threat-intelligence-grounded).