What are the steps of the threat hunting process?
Threat hunting usually starts with a trigger, then investigation, then resolution. A hunt starts from something (a hypothesis, a piece of threat intel, an odd pattern), somebody digs into the data to prove or disprove it, and the hunt ends with an outcome. The fuller models just break those three phases into finer stages so a team can hand a hunt off between people without losing the thread. Here is how the three-step shape maps onto the longer versions most hunters run:
- Trigger: a hypothesis forms, usually from a SOC signal, a threat-intel report, or something a hunter noticed. This is the "what am I looking for and why" stage.
- Investigation: enumerate the log sources that can prove or disprove the hypothesis, establish what normal looks like in the environment, then run the queries and chase the anomalies. Most of the hunter's hours have historically gone here.
- Resolution: issue a verdict with evidence, map it to MITRE ATT&CK, hand confirmed threats to response, and capture anything reusable such as a new detection rule.
What is a threat hunting hypothesis, and how do you write one?
A threat hunting hypothesis is a testable statement about attacker activity you suspect is present in your environment, specific enough that the log data can prove or disprove it. A good one names the behavior, the technique, and the scope: "an attacker is using WMI for lateral movement in the finance VLAN over the last ninety days" is a hypothesis you can actually hunt. "Are we compromised?" is not, it's a feeling. The tighter the statement, the less of the environment the hunt has to search, so scoped hypotheses tend to cost less and finish faster.
Good hypotheses usually come from four places: SOC signals, threat intelligence such as a current campaign or a leaked-credential report, the MITRE ATT&CK framework, and plain environment knowledge.
What is a threat hunting framework?
A threat hunting framework is a repeatable structure for planning, running, and capturing hunts so the work doesn't depend on one person's memory. Without a framework, hunting tends to be ad hoc, a skilled person pokes around when they have a free afternoon, finds something interesting sometimes, and none of it is reproducible next quarter. A framework fixes that by defining how a hypothesis gets formed, how a hunt gets scoped and executed, how findings get recorded, and how what you learn feeds back into detection. The three most cited ones are PEAK (Prepare, Execute, Act with Knowledge, from Splunk's SURGe team), TaHiTI (Targeted Hunting integrating Threat Intelligence, developed by a group of Dutch banks), and the older Sqrrl hunting loop (from Sqrrl and David Bianco, around 2015), which most of the later frameworks build on. There is also the Hunting Maturity Model, or HMM, a zero-to-four scale for rating how developed a team's hunting practice is, which is less a process and more a yardstick. None of these frameworks is a product you buy. They are shared vocabulary and a checklist, and any of them is better than none.
What is the PEAK threat hunting framework?
PEAK stands for Prepare, Execute, and Act with Knowledge, a threat hunting framework published by Splunk's SURGe research team (David Bianco was the lead author). It's a three-phase loop meant to make hunts repeatable and to make sure the output of each hunt actually improves the security program instead of evaporating once the hunt is done. Prepare is where you form the hypothesis, scope the hunt, and figure out which data sources you'll need. Execute is the hunt itself, running the queries, analyzing the data, and confirming or refuting the hypothesis. Act with Knowledge is the part most teams skip: documenting findings, creating new detections from what you found, and feeding lessons back into the next hunt and into the SOC.
PEAK also names three hunt types, which is part of why it caught on. Hypothesis-driven hunts start from a specific suspected behavior. Baseline hunts, sometimes called exploratory data analysis or EDA, start by establishing what normal looks like and then hunting the outliers. Model-assisted hunts, which PEAK calls MABTH, use machine learning or statistical models to surface candidates for a human to investigate. Most mature programs run a mix of all three rather than committing to one.
PEAK vs TaHiTI vs Sqrrl — which framework should you use?
Pick the framework by your team's maturity and what you're hunting for, not by which one has the newest whitepaper. The three sit at different points on the age-and-detail curve. The Sqrrl loop is the ancestor, TaHiTI is the intel-heavy one, and PEAK is the modern general-purpose one that absorbed lessons from both. Here's the rough shape of each:
| Framework | Origin | Best when |
|---|---|---|
| Sqrrl hunting loop | Sqrrl / David Bianco, ~2015 | You want the simplest possible loop to get a nascent practice off the ground |
| TaHiTI | A group of Dutch banks | Your hunts are mostly driven by threat intelligence and you need tight handoff to incident response |
| PEAK | Splunk / SURGe (David Bianco) | You want a general framework with named hunt types and a strong "turn findings into detections" phase |
In practice most teams starting today land on PEAK because it's the most complete and it explicitly bakes in the detection-engineering feedback loop. TaHiTI is worth a look if your program lives and dies on external intel feeds. The Sqrrl loop is still perfectly usable and, honestly, most of PEAK is a refinement of it. Whatever you choose, the framework matters far less than actually running hunts on a cadence.
How do you start a threat hunting program?
Start with data coverage, not with hypotheses, because a hunt is only as good as the logs it can reach. Before anyone writes a hypothesis, confirm you're actually collecting and retaining the telemetry that matters, endpoint or EDR data, authentication logs, DNS, and network or proxy logs, with enough retention (ideally several months) that a low-and-slow attacker actually shows up in the window you can search. Data gaps kill hunts, so this step is load-bearing.
Once coverage is in place, the sequence is straightforward: create a hypothesis (borrow from SOC false positives, threat intel, or ATT&CK to start), run it as a short sprint of two weeks or less, capture what you learned, and repeat. Keep the first hunts small and scoped. A tight hypothesis on a single VLAN teaches you more about your own process than an "investigate everything" hunt that never finishes. Track a couple of simple metrics, such as hunts run per month and detections created per hunt, so you can show the program is compounding.
The hard constraint most teams hit is capacity: trained hunters are scarce, and hypothesis validation eats their hours. Simbian's AI Threat Hunt Agent is built to scale the capacity of a nascent practice rather than replace the practitioner, the hunter still directs the hunts and owns the verdicts, the agent takes the manual validation work off their desk so a small team can test far more hypotheses than headcount would otherwise allow.
What data sources and logs do you need for threat hunting?
Data gaps kill hunts, so this is the operational blocker most teams hit first: if the log a hypothesis needs isn't there, the hunt can't run no matter how good the idea was. The essentials are endpoint and EDR telemetry (Sysmon and Windows process-creation events, the 4688 logs, are the workhorses here), authentication logs from your identity provider, DNS query logs, network and proxy logs, and cloud audit logs such as CloudTrail or the Azure activity log if you run in the cloud. Each covers a different part of the kill chain, endpoint telemetry catches execution and lateral movement, auth logs catch credential abuse, DNS and proxy catch command-and-control and exfiltration, cloud audit logs catch identity and configuration abuse in the control plane.
Retention matters as much as coverage. Attackers using AI run low-and-slow campaigns designed to dwell quietly, and advanced threats sit in an environment for weeks or months on average before anyone notices, so a thirty-day window often isn't enough. Aim for several months of searchable history for the sources that matter most.
How do you turn a threat hunt into a detection rule?
This is the payoff loop, and it's the whole reason a mature hunting practice compounds instead of repeating itself. If a hunt finds a repeatable, kill-chain-shaped pattern, that pattern should become a detection so nobody ever has to hunt it by hand again. The point isn't just to catch today's instance, it's to make sure the next instance fires an alert automatically. The interesting part is that even a benign hunt can produce a Detection Opportunity: the activity turned out legitimate this time, but the pattern was real and no existing SOC rule covered it, so an attacker could replay it undetected. Every hunt hardens detection, even the ones that come back clean.
The shape of turning a hunt into a rule is consistent. Capture the query logic that surfaced the pattern, generalize it so it catches the behavior rather than the one specific instance, deploy it as a detection rule in your SIEM or EDR, then tune it against false positives so it doesn't drown the SOC in noise. Simbian recommends the specific missing rule (for example, add auto-isolate host on ransomware detection in CrowdStrike) and the customer decides whether to implement it. That recommendation closes the loop straight back into the AI SOC Agent, so a finding from the hunting layer becomes durable coverage in the alert queue.