N-able发布威胁狩猎框架科普博客

Threat hunting fills the gap automated alerts leave behind. Attackers can move laterally, disable backups, and stage data theft while standard detections stay quiet, so teams need a repeatable way to look for what controls miss.

The play here is structure . A threat hunting framework turns scattered investigation into a hypothesis-driven, repeatable process, one that finds what existing defenses missed across managed and in-house environments.

Three established frameworks shape most hunting programs today: Sqrrl, PEAK, and TaHiTI. A six-step process at the end shows how to put them into practice.

How hunting differs from automated detection

Threat hunting works alongside automated detection, adding a structured, hypothesis-driven layer for finding adversary activity that existing defenses have missed. Hunting is human-led and hypothesis-driven, distinct from a re-run of security information and event management ( SIEM ) alerts.

Automated detection catches known-bad patterns.

Hunting finds unknown-bad activity: behavior that slips past signatures, rules, and behavioral baselines because no one wrote a detection for it yet.

Here’s the thing: without a framework, hunts become inconsistent one-off efforts that depend entirely on who ran them.

Why a framework matters: Repeatability, maturity, and proof

Frameworks turn one-off hunts into a measurable program. They make hunts repeatable across analysts and environments, measure maturity through models like the Hunting Maturity Model (HMM), and produce documented proof that proactive strategies are happening. At scale, that documentation pays dividends the moment leadership, auditors, or prospects start asking hard questions.

Established threat hunting frameworks

Several frameworks deliver that promise, each solving the same challenge in different ways: how to make threat hunting repeatable, measurable, and easier to improve over time. The right fit depends on operational reality, including team maturity, intelligence capability, and the complexity of the environments being hunted.

The sections below show where each model fits operationally and what each one emphasizes most. Some prioritize a simple hunt-to-detection loop, while others lean harder on intelligence workflows or baseline analysis.

Sqrrl: The original four-stage hunting loop

Sqrrl is a foundational four-stage hunting loop and remains a practical starting point for structured threat hunting.

The core design is an iterative cycle:

Hypothesis creation (Stage 1),

Investigation via linked datasets (Stage 2),

Uncovering new behavioral patterns and tactics, techniques, and procedures (TTPs) (Stage 3),

Converting those patterns into automated detection rules (Stage 4).

Stage 4 is the critical handoff: every manual discovery becomes permanent automated coverage, which means each completed loop makes the next hunt more focused.

Sqrrl also introduced the Hunting Maturity Model (HMM), which ranges from HM0, relying entirely on automated alerts, to HM4, where automation stays top of mind when creating new hunting techniques. The HMM helps teams assess each environment individually and sequence investments accordingly.

Bottom line: Sqrrl is the right starting point for teams new to structured hunting who need a simple, proven loop to build from.

PEAK: Prepare, Execute, Act with Knowledge

PEAK builds on Sqrrl’s foundation by defining three distinct hunt types instead of one.

Hypothesis-driven hunts work like the classic Sqrrl approach.

Baseline hunts define what normal looks like in an environment, then flag deviations. They matter most when teams take on a new environment, post-acquisition, or post-migration.

Model-Assisted Threat Hunting (M-ATH) applies machine learning to detect patterns across large datasets that hypothesis-driven analysis alone would miss.

Whichever hunt type fits the situation, PEAK structures the work in three phases: Prepare, Execute, and Act. Knowledge runs continuously across all three, including threat intelligence, organizational expertise, and prior experience that inform every phase.

The Act phase specifies concrete deliverables for every hunt, including recreatable documentation, new or improved detections, documented gaps, and executive summaries.

What this looks like in practice: even a single administrator can start with hypothesis-driven hunts, then scale into baseline and M-ATH hunts as capability grows.

TaHiTI: Targeted Hunting with Threat Intelligence

Where PEAK organizes hunts by type, TaHiTI organizes them around intelligence: threat intelligence is both a primary trigger input and an output of hunting. Three phases, Initiate, Hunt, and Finalize, structure the workflow from trigger processing through real-time intelligence enrichment to documented outputs, and every hunt generates new intelligence that feeds back into future prioritization and detection engineering.

TaHiTI works well for teams with dedicated threat intelligence capability and for organizations in regulated industries where compliance-driven documentation is a requirement.

MITRE ATT&CK as a hunting reference

Sqrrl, PEAK, and TaHiTI all assume a shared language for describing adversary behavior. MITRE ATT&CK provides that language and serves as a widely used technique reference for cyber threat intelligence programs. The practical guidance is clear: do not attempt 100% ATT&CK coverage.

Map existing SIEM detections to ATT&CK techniques using ATT&CK Navigator, identify gaps, then overlay adversary group profiles relevant to the industries you support. Threat group techniques you can’t currently detect become your prioritized hunt backlog. Free tools from the Cybersecurity and Infrastructure Security Agency ( CISA ), such as Decider, simplify the mapping process using guided questions.

A six-step threat hunting framework

Framework choice matters, but execution is where threat hunting either compounds value or turns into sporadic investigation. Here’s why that matters: a repeatable process keeps hunts grounded in available telemetry, produces usable outputs, and makes the work easier to run across multiple environments.

Threat hunting only works when the telemetry foundation is already in place. Before any hunting begins, confirm three readiness markers:

Endpoint detection and response (EDR) is deployed and reporting on all managed endpoints, providing the visibility hunters need.

Windows Event Logs are centrally collected, including authentication events and PowerShell logging, since these surface the activity that matters most.

A documented baseline of normal activity exists for each environment, allowing deviation-based hunts to produce signal instead of noise.

Once that foundation is in place, the six steps below turn hunting from an ad hoc activity into a repeatable program.

Step 1: Form a hypothesis

A hypothesis is a written, testable statement about suspected adversary behavior, grounded in intelligence or observed anomaly. Three input sources drive hypothesis quality. ATT&CK-mapped threat intelligence identifies which threat groups target the sector and what techniques they use. Environmental anomalies show deviations from baseline that have not yet triggered alerts. Situational context covers elevated-risk periods like infrastructure changes or acquisitions.

Step 2: Identify and collect data sources

Map data availability to the hypothesis before executing. Required sources include EDR telemetry, Windows Event Logs, DNS logs, and firewall/proxy logs. Enhancing sources include Active Directory logs, cloud access logs, and NetFlow data. Document coverage gaps for each one. An environment without EDR and centralized logging cannot be effectively hunted, and that risk belongs in writing.

Step 3: Investigate using tools and techniques

With data sources mapped, four analytical techniques separate hunting from alert triage. Stack counting sorts events by frequency to surface outliers, while frequency analysi