PEAK Threat Hunting Framework: How to Turn Hunt Findings Into Detections That Compound Over Time

A threat hunter spends 2 days digging through connection logs and finds it: a router's management interface has quietly opened an SSH session to an unfamiliar external address on a nonstandard port. She confirms the authentication succeeded, traces the session, and writes a clean summary of what happened and how she found it. The document goes into a shared wiki.

Four months later, a different hunter, working a different hypothesis, finds the same pattern on a different device. He has no idea it happened before. Nothing alerted. This is the persistence method described in CISA's joint advisory on Chinese state-sponsored actors compromising networks worldwide, which found that attackers often modify routers to maintain persistent, long-term access to networks. The finding was accurate and well documented, but it never became a detection. That gap is what the PEAK Threat Hunting Framework was built to close.

What Is the PEAK Threat Hunting Framework?

PEAK Threat Hunting Framework is a structured, vendor-agnostic methodology for planning, running, and operationalizing threat hunts, built around 3 phases: Prepare, Execute, and Act With Knowledge. It was introduced by SURGe by Splunk in 2023 as a modernization of earlier hunting models, incorporating lessons learned since those approaches first appeared. The 3 phases give a hunt program the structure the opening scenario was missing: a defined path from hypothesis to documented, repeatable defense.

PEAK vs. Other Threat Hunting Frameworks

PEAK did not emerge in a vacuum. Two earlier models shaped the hunting practices many teams still follow, and understanding what PEAK changed makes clear why it has become the reference point for newer programs.

‍

Neither predecessor was built for cloud infrastructure, SaaS sprawl, or living-off-the-land techniques, which is the gap PEAK's baseline and model-assisted hunt types were designed to close.

What's at Stake When Threat Hunting Has No Framework Behind It

Without a framework, threat hunting depends on who happens to be doing it and what they remember to document. The gaps below show why that dependency erodes a hunting program over time, and why closing the loop into detection is what separates a real program from a series of one-off investigations.

• Unstructured Hunting Produces Inconsistent Results That Do Not Improve Over Time: Without a documented process, hunt quality depends on whichever analyst happens to be running it that day, so outcomes vary hunt to hunt instead of building on each other.
  
• Alert-Driven SOCs Miss Threats That Never Trigger a Detection Rule: Waiting on alerts only surfaces threats a detection rule was already written to catch, leaving anything outside that rule set invisible until a hunter goes looking for it.
  
• Frameworks Turn One-Off Hunts Into Repeatable, Measurable Programs: A documented process means hunts can be replicated, compared, and improved on over time, instead of starting from scratch and losing continuity when the analyst who ran them leaves.
  
• PEAK Connects Hunt Findings Directly to Detection Improvement and Security Maturation: Every PEAK hunt closes with an Act phase built to turn validated findings into detections and playbooks, so program maturity climbs with each cycle instead of resetting.

The Three Types of PEAK Threat Hunts

PEAK does not prescribe a single way to hunt. It defines 3 hunt types that share the same Prepare, Execute, Act With Knowledge structure but differ in how the investigation starts.

• Hypothesis-Driven Hunting: The hunter forms a specific, testable statement about adversary behavior, often structured using PEAK's ABLE method (Actor, Behavior, Location, Evidence), then searches the data to confirm or disprove it.
  
• Baseline Hunting: The hunter establishes what normal activity looks like for a given system or behavior over a defined period, then investigates anything that deviates from that baseline as a potential lead.
  
• Model-Assisted Threat Hunting: Machine learning or UEBA models surface the highest-risk entities or anomalies at scale, and a human analyst validates whether the flagged activity actually matches known adversary techniques.

The Three Phases of the PEAK Threat Hunting Framework

Every PEAK hunt, regardless of type, moves through the same 3 phases. What separates a hunt that produces lasting value from one that does not is how deliberately each phase gets executed.

1. Prepare: Define the Hypothesis, Scope, and Data Sources Before the Hunt Begins

Prepare turns a real threat, a CISA advisory, an incident, a red-team finding, into a testable hypothesis. PEAK's ABLE structure (Actor, Behavior, Location, Evidence) forces the specifics: who, what exact technique, where in the environment, and which logs would show it. Scope comes next: timeframe, systems in play, and constraints like query cost. Skipping Prepare is the most common reason hunts turn into unfocused log browsing. The phase should output a short plan, the access it requires, and, where possible, pre-built queries.

2. Execute: Conduct the Hunt, Analyze Data, and Iterate Based on Findings

Execute starts broad, establishing what normal looks like, before narrowing to deviations. Without that baseline pass, a hunter cannot separate a genuine anomaly from noise. From there, the work is iterative: one finding pivots to the next log, one identifier to the next data point, confirming the hypothesis or redirecting it. Hunters label each event benign, suspicious, or confirmed malicious as they go, so the reasoning is visible later. Execute closes with a hypothesis confirmed or disproved and an evidence package ready for Act. A disproved hypothesis still confirms a control is working; that is not a failed hunt.

3. Act With Knowledge: Turn Hunt Findings Into Detections, SOPs, and Program Improvements

Act With Knowledge converts findings into something that outlasts the hunt: a detection rule, an updated playbook, a hardening change, or a place in PEAK's Hierarchy of Detection Outputs, with Signature sitting at the top as the most durable output, one that catches the underlying technique rather than a single instance of it. Documentation carries equal weight, capturing objective, scope, hypothesis, sources, queries, results, and lessons learned, then sharing it with SOC, IR, and system owners. Its output feeds directly back into the next Prepare phase, which is what compounds a program instead of resetting it.

How to Operationalize the PEAK Framework

Understanding PEAK's phases is one thing; running it as a program is another. The practices below are what turn the 3-phase structure into something a team actually executes hunt after hunt.

How PEAK Maps to CD/CR: The Closed-Loop Architecture That Makes Hunting Compound

PEAK's Act With Knowledge phase and Continuous Detection / Continuous Response (CD/CR) are built on the same principle: a finding only has lasting value once it becomes a detection. The 3 subsections below walk through where that logic overlaps and what breaks when it doesn't.

How PEAK's "Act With Knowledge" Phase Mirrors CD/CR's Detection Compression

Act With Knowledge takes a validated hunt finding and turns it into a Signature, playbook update, or hardening change, closing the distance between "we found something" and "we're now automatically protected against it." CD/CR runs on the same logic in reverse direction: investigations compress into detections, and those detections feed the next investigation, so the loop tightens instead of resetting each time. The two frameworks describe the same closed loop from different starting points, one built for structured hunting, the other for continuous operations.

Why Hunts That Do Not Feed Detections Leave the Program Flat

A hunt that ends at documentation, without a path into detection engineering, leaves the organization at the same protection level it had before the hunt started. The finding exists, but the next hunter has no way to benefit from it unless they happen to search the same wiki page. This is the exact failure mode the opening scenario showed: an accurate, well-documented finding that never became a detection, rediscovered blind 4 months later.

How the Loop Gets Tighter With Every Completed Hunt

Each hunt that feeds a detection changes what the next hunt needs to cover. Confirmed techniques get automated coverage, freeing the next hunt to chase what's still unknown instead of re-validating ground already closed. Organizations grounding investigations in accumulated context, rather than rebuilding it from scratch each time, keep that loop compounding instead of flattening with every analyst turnover.

The Gaps That Prevent PEAK From Working in Practice

PEAK's structure is sound, but structure alone doesn't guarantee a program runs the way it's designed to. The 4 gaps below are where real hunting programs tend to break down, even with a framework in place.

What Separates Threat Hunting Programs That Compound From Ones That Reset

The gaps above are common, but they are not inevitable. The 3 practices below are what programs that stay ahead of their own knowledge loss actually do differently.

1. Version Your Security Context Alongside Your Hunt Outputs: Architecture changes, SOPs get rewritten, and ownership shifts, so a hunt finding validated against last year's environment can be stale or misleading against this year's. Treating organizational context as something that gets versioned and dated, the same way code does, lets a hunter check whether a past finding still applies before building on it, instead of assuming it does.
   
2. Treat Every Hunt as an Input to Detection Engineering, Not a Standalone Activity: Programs that compound design the handoff into detection engineering before the first hunt runs, not after a finding is already written up. That means detection engineers reviewing hunt output on a set cadence, not waiting for a hunter to escalate manually, so the conversion from finding to production rule is a built-in step rather than a hope.
   
3. Measure Hunt Program Maturity With Repeatable Metrics Tied to Detection Improvement: "Did we find anything?" is not a maturity metric. Tracking detections created per hunt, time from finding to production rule, and misconfigurations remediated gives leadership a way to see the program improving cycle over cycle, rather than judging it hunt by hunt on whether something dramatic turned up.

How Mate Enables Context-Driven Threat Hunting Aligned With the PEAK Framework

Everything above describes what a mature PEAK program needs: durable context, a direct line from finding to detection, and knowledge that survives analyst turnover. The 5 items below show how Mate is built around exactly that.

• Security Context Graph Built From Architecture, SOPs, and Investigation History Within 24 Hours: Mate's Security Context Graph becomes the organizational "brain" a hunter would otherwise have to rebuild by hand at the start of every hunt, compiled from architecture, ownerships, and past investigation history rather than reconstructed hunt by hunt.
  
• Covers 100% of the Alert Queue, Including Informational Events Where Advanced Threats Hide: Full coverage of the alert queue, including the informational events that usually go unreviewed, closes the exact gap this article raised earlier: threats that hide in low-priority telemetry because analyst time never reaches it.
  
• Converts Completed Investigations Into Production-Ready Detections Through CD/CR: This is where Continuous Detection / Continuous Response does the same work as PEAK's Act With Knowledge phase, compressing a closed investigation into a production-ready detection instead of leaving it as a writeup on a wiki page.
  
• Gamebooks Capture Hunt Reasoning as Reusable SOPs, Not One-Off Documentation: Gamebooks turn a hunter's reasoning into an adaptive SOP the next investigation can reuse, rather than a static document that only helps if someone happens to find it.
  
• Retains Organizational Context So Programs Compound Instead of Resetting With Analyst Turnover: When an experienced hunter leaves, the context they built stays behind, because it lives in the graph rather than in that one person's head, so the program keeps compounding instead of resetting with every departure.

Conclusion

A hunting program is judged by what happens after the hunt ends, not during it. PEAK gives that ending structure: a hypothesis worth testing, an investigation built to hold up, and an Act phase designed to turn findings into detections rather than documentation. That structure is what makes a program compound instead of reset. Teams adopting PEAK should treat the hunt-to-detection handoff and organizational context as infrastructure to maintain, not an afterthought to hope for. Do that well, and every hunt sharpens the next one, turning a series of investigations into a security posture that keeps improving on its own.