CHAPTER 03 35 MIN READ INTERMEDIATE

Hunting Frameworks

Two analysts can hunt the same hypothesis and produce completely different results, not because one is more skilled, but because one has a repeatable process and the other is improvising. Frameworks solve that problem. They do not tell you what to hunt. They tell you how to hunt consistently so that knowledge accumulates, detection coverage grows, and any analyst can pick up where the last one left off.

PEAK TaHiTI lifecycle

Why Frameworks Matter

A hunt without a framework is a one-time event. An analyst investigates, finds something or does not, and moves on. No documentation. No detection rules created. No new hypotheses generated. No way for a junior analyst to learn from it. The knowledge lives in one person's head until they leave the team.

A hunt with a framework is a building block. Each completed hunt adds to a shared knowledge base. Detection rules are created from successful patterns. Gaps discovered during the hunt become the next sprint's hypotheses. Methodology is documented so another analyst can run the same hunt in six months and compare results. The program compounds over time.

Without a framework, the symptoms are consistent: ad hoc hunts with no repeatability, siloed knowledge, no documentation, cannot scale past the founding analyst, and no way to measure detection coverage improvement over time.

Note: A framework does not tell you what to hunt. It tells you how to hunt consistently so the next analyst can pick up where you left off. The methodology is the container. The hypothesis is the content.

The frameworks in this chapter evolved over nearly a decade. Sqrrl published the foundational hunting loop in 2015. TaHiTI formalized the intel-driven approach in 2018 for the Dutch financial sector. SANS published the PAM model around 2020. Splunk SURGe published PEAK in 2023. The Open Research Threat Research Foundation (OTRF) maintains the ThreatHunter-Playbook as a community resource. Each builds on the ones before it, adding documentation discipline, explicit feedback loops, and structured hypothesis management.

You do not need to choose one and ignore the rest. The most effective programs use elements from multiple frameworks. This chapter covers each one, including where it excels and where it has gaps, so you can build an informed hybrid approach.

The Sqrrl Hunting Loop

Sqrrl, a threat intelligence startup acquired by AWS in 2017, published the first formal model of threat hunting as an iterative discipline in 2015. Before Sqrrl, hunting was ad hoc. After Sqrrl, it had a language and a structure. Their hunting loop is the conceptual foundation every subsequent framework builds on.

The loop has four stages:

DIAGRAM

    Generate                   Investigate
    Hypothesis    ---------->  (Query data,
    (Intel, TTP,               pivot on findings,
    anomaly,                   correlate events)
    situational)                     |
         ^                           |
         |                           v
    Inform and               Uncover New Patterns
    Enrich          <----    (New TTPs, actor behavior,
    Analytics                data gaps, new hypotheses)

Each stage has a concrete output that feeds the next:

Stage	What You Do	Output
Generate Hypothesis	Form a testable belief about adversary behavior using intel, ATT&CK, anomalies, or situational context	A specific, ABLE-structured hypothesis ready to investigate
Investigate	Query data, pivot on findings, correlate across log sources, eliminate false positives	Confirmed threat (escalate to IR) or ruled-out hypothesis with documentation
Uncover New Patterns	During investigation, notice new behaviors, gaps in telemetry, or related techniques not in the original scope	New hypotheses, identified data gaps, new actor behavior patterns
Inform and Enrich Analytics	Create detection rules from confirmed patterns. Update threat intel. Add new hypotheses to backlog.	New Sigma/KQL/SPL rules, updated hunt backlog, enriched threat intel

The most important insight from the Sqrrl model is that hunting is a cycle, not a linear process. Every completed hunt generates the seeds of the next hunt. The "Uncover New Patterns" stage is where you collect those seeds: anomalies you noticed but did not have time to pursue, related techniques suggested by what you found, data gaps that became visible when you tried to query something and got no results.

The Sqrrl loop's limitations are also what motivated later frameworks. There is no explicit documentation phase. No team coordination mechanism. No feedback loop between the hunt and the broader SOC. And no distinction between different types of hunts. TaHiTI, PEAK, and SANS PAM each address one or more of these gaps.

Tip: Even if you adopt a more complex framework, keep the Sqrrl loop visible as a mental model. When you get lost in process details, ask yourself: which stage am I in? That grounding prevents the common mistake of executing without direction or over-documenting without investigating.

PEAK: Prepare, Execute, Act with Knowledge

PEAK was developed by the Splunk SURGe research team and published in 2023. It is available on GitHub under splunk/PEAK. The framework solves the Sqrrl loop's main gaps: it adds explicit preparation before the hunt, formalizes the documentation and detection-creation phase after the hunt, and introduces a taxonomy of three distinct hunt types.

Three Hunt Types

Type	What It Is	Best Used When
Hypothesis-Driven	Form a specific belief about adversary behavior. Test it with data. Confirm or rule out.	You have a threat report, a specific ATT&CK technique to test, or a situational trigger
Baseline	Establish what "normal" looks like in your environment. Find deviations from that baseline.	You lack a behavioral baseline. New environments. After major infrastructure changes.
Model-Assisted (M-ATH)	Use machine learning (clustering, classification, anomaly detection) to surface candidates for analyst review.	High data volumes where manual querying cannot cover the search space

PREPARE Phase

Everything that happens before touching data. Most hunters skip this and pay for it in wasted query time and unfocused investigation.

Select topic: Choose a hypothesis from your backlog using the priority scoring system from Chapter 2. Document why this hypothesis was selected now.
Research: Read the relevant ATT&CK technique page. Check if your CTI team has recent reporting on this technique or actor. Review prior hunt results in this area.
Scope: Define explicitly what systems, time window, and data sources are in scope. Write down what is explicitly excluded and why.
Document: Write a one-page hunt plan before starting. Forces clarity on what you expect to find and what would prove the hypothesis false.
Verify tooling: Confirm query access to the required data sources. Run a test query to verify data exists and fields are populated correctly.

EXECUTE Phase

The investigation itself. PEAK treats pivoting as an expected and normal part of execution, not as scope creep. When a query result suggests a related pattern, following that thread is correct behavior, as long as it is documented.

Data gathering: Pull relevant logs for the scoped time window. Apply initial filters to reduce volume without losing signal.
Analysis: Run your planned queries. Apply statistical techniques: frequency analysis (stack counts to find rare events), clustering (group similar behaviors), time-series analysis (beaconing patterns).
Iterate: Results from the first query inform the second. Each pivot is a new hypothesis derived from evidence. Document each pivot and its rationale.
Escalate if needed: If you find a confirmed threat during execution, hand off to IR immediately. Do not pause the hunt to do IR work. Continue documenting what you found and how.

ACT Phase

The phase most hunters skip. The Sqrrl loop calls it "Inform and Enrich Analytics" but does not prescribe what to do. PEAK is specific.

Preserve: Write up methodology. Another analyst should be able to re-run this hunt exactly from your documentation.
Detect: Convert every confirmed-malicious query pattern into a Sigma, KQL, or SPL detection rule. If the hunt found no threat but confirmed the pattern would be detectable, create the rule anyway for future monitoring.
Backlog: Every new hypothesis generated during the hunt (patterns noticed, data gaps found, related techniques to investigate) goes into the hunt backlog with a score.
Communicate: Brief your team lead and relevant stakeholders on findings. Even null findings inform coverage posture.

Note: PEAK's ACT phase is its primary differentiator. Most hunters execute then move to the next hypothesis. The ACT phase is what converts hunting from a point-in-time activity into a compound detection-building program. Every completed PEAK hunt should produce at least one detection rule or one documented data gap. If neither, the hunt was not closed properly.

A practical hunt plan template following PEAK's Prepare phase:

TEMPLATE

HUNT PLAN
Date: 2026-06-02
Analyst: [name]
Hypothesis: An adversary dumped LSASS memory using comsvcs.dll MiniDump
  to extract credentials for lateral movement (T1003.001)
ATT&CK: T1003.001 - OS Credential Dumping: LSASS Memory
Hunt Type: Hypothesis-Driven (PEAK)

Scope:
- Systems: All Windows servers in domain CORP, all Tier-0/Tier-1 workstations
- Time window: Last 30 days
- Data sources: Sysmon Event 10 (ProcessAccess), Sysmon Event 1 (ProcessCreate),
  Windows Security Event 4688, EDR process telemetry

Expected evidence if hypothesis TRUE:
- Sysmon 10: GrantedAccess 0x1FFFFF or 0x1010 targeting lsass.exe
  from a non-system process
- Sysmon 1 / Event 4688: rundll32.exe with CommandLine containing
  comsvcs + MiniDump + lsass
- Sysmon 11: .dmp file created in %TEMP% or unusual directory

Expected evidence if hypothesis FALSE:
- No Sysmon 10 events targeting lsass.exe from user-space processes
- No comsvcs.dll invocations outside of Windows Error Reporting

Planned queries:
1. Search Sysmon 10 for lsass.exe as TargetImage, non-system SourceImage
2. Search Event 4688 / Sysmon 1 for rundll32.exe with comsvcs + MiniDump
3. Search Sysmon 11 for .dmp file creation in suspicious paths
4. If positive: pivot to Sysmon 3 from same host to detect outbound transfer

TaHiTI: Targeted Hunting Integrating Threat Intelligence

TaHiTI was developed by the Dutch Financial Sector ISAC (FI-ISAC) in 2018. It was designed specifically for regulated enterprise environments where threat intelligence is mature and documentation requirements are formal. The name describes the method: every hunt phase is explicitly integrated with the organization's CTI function.

TaHiTI's core principle is that threat intelligence is not just a hypothesis seed. It is woven throughout the entire hunt: from the trigger that initiates the hunt, to the enrichment applied during investigation, to the output that feeds back into the intelligence cycle. A hunt that begins with a CTI trigger and produces no CTI output has broken the loop.

Phase	Description	Key Output
1. Initiation	An intel-driven trigger starts the hunt. A new threat report, a CISA advisory, a CTI product about an active campaign targeting your sector, or an organizational risk event (acquisition, executive travel to high-risk region).	Approved hunt trigger with documented rationale and business context
2. Preparation	Define scope, identify data sources, set up tooling, write the hunt plan, validate data availability. Very similar to PEAK's Prepare phase but with explicit CTI enrichment step: pull all available intel on the actor/technique before starting.	Hunt plan with CTI-enriched context, scoped time window, validated data access
3. Execution	Targeted investigation using intel-enriched queries. Analysts pivot based on findings. Each pivot is documented. CTI feeds are queried during execution when pivots produce new IOCs or actor-related artifacts.	Evidence trail, confirmed positives or ruled-out hypothesis, pivot log
4. Closure	Formal documentation of all findings: true positives (what was found), false positives (what looked suspicious but was legitimate), data gaps (what could not be tested). Formal sign-off on the hunt as closed.	Closure record documenting TPs, FPs, gaps, and final disposition
5. Follow-up	Create detection rules from confirmed patterns. Feed findings back to CTI for intel enrichment. Share relevant findings with trusted peer organizations through ISAC channels. Update the hunt backlog.	Detection rules, CTI update, peer sharing, backlog additions

MaGMa: Documentation Companion

TaHiTI's documentation methodology is formalized through MaGMa (Management and Growth of Mature Analytics). MaGMa provides structured use case cards that capture every element of a hunt in a consistent format: what the technique is, what telemetry is required, what the expected finding looks like, and what detection rules were created. This enables consistent knowledge capture across an entire team, not just the analyst who ran the hunt.

Pyramid of Pain Application

TaHiTI explicitly applies the Pyramid of Pain model developed by David Bianco in 2013. The pyramid ranks indicators by how costly they are for the adversary to change:

Hash values: trivial to change by recompiling
IP addresses: easy to rotate
Domain names: cheap to register new ones
Network and host artifacts: requires more effort
Tools: requires significant effort to rewrite
TTPs: expensive to change, baked into tradecraft

TaHiTI explicitly targets TTP-level hunting and deprioritizes pure IOC hunting. Hunting for a specific hash or IP address is not hunting in TaHiTI's definition. That is threat intel matching. Hunting means investigating the behavioral pattern that the actor uses, which survives across every infrastructure rotation and tool update.

Note: TaHiTI was built for the Dutch financial sector's specific regulatory and collaborative environment. That context matters. Its five-phase structure with formal closure and follow-up is more prescriptive than PEAK but it is not bureaucratic overhead: each phase produces a specific artifact that the ISAC uses for peer intelligence sharing. The formality serves the collaborative model.

When TaHiTI Fits Best

TaHiTI excels in: regulated industries (finance, healthcare, critical infrastructure) where documentation requirements are formal, environments with dedicated CTI functions that produce finished intelligence products, and organizations that participate in ISACs or peer intelligence sharing networks where standardized hunt output is valuable to the broader community.

Compared to PEAK: TaHiTI is more prescriptive and explicitly intel-anchored. PEAK is more flexible and covers all three hunt types (hypothesis, baseline, M-ATH). Use TaHiTI when CTI drives every trigger and documentation formality is required. Use PEAK when you need flexibility across hunt types and the team is smaller or less CTI-mature.

SANS PAM Model

The SANS Practical Analysis Model (PAM) was authored by Dan Gunter and published as a SANS whitepaper. Its six stages follow a linear flow with one structural innovation that distinguishes it from every other framework: a mandatory peer review step before execution begins.

Stage	What Happens	Key Question
1. Purpose	Document why this hunt exists. What business risk or threat intelligence triggered it? What is the expected outcome if the hypothesis is true?	Why are we spending hunt time on this now?
2. Scope	Define what is explicitly in scope: systems, time range, data sources. Define what is explicitly excluded and why. Written boundaries prevent scope creep during execution.	What is in, what is out, and why?
3. Equip	Verify data access before starting. Run test queries to confirm required log sources exist and contain expected fields. Confirm tool access (SIEM, EDR, threat intel platform).	Do we actually have what we need to run this hunt?
4. Plan Review	A senior analyst or peer reviews the complete hunt plan before any execution begins. The reviewer checks: is the hypothesis testable? Is the scope correct? Are the planned queries likely to surface the right evidence? Are there data gaps the analyst missed?	Has someone else stress-tested this plan?
5. Execute	Run the hunt. Document all queries, all pivots, all results including nulls. If a confirmed threat is found, escalate immediately while continuing to document.	What does the data actually show?
6. Feedback	Explicit retrospective after the hunt closes. What worked? What failed? What would you do differently? What new hypotheses were generated? This feeds back into the next hunt's Purpose stage.	What did we learn and how do we do better next time?

The Plan Review step is SANS PAM's unique contribution to the field. No other framework mandates peer review before execution. The practical value is significant: a five-minute review by a second analyst catches hypothesis flaws, scope errors, missing data sources, and poorly constructed queries before they waste the executing analyst's time.

What Plan Review Catches in Practice:

An analyst plans to hunt for LSASS credential dumping using Sysmon Event 10. The reviewer looks at the Equip stage documentation and notices the test query for Sysmon Event 10 returned zero results, even though Sysmon is deployed. The analyst had not noticed. The reviewer identifies that the Sysmon config does not have ProcessAccess rules enabled for lsass.exe. The hunt plan is updated: first step is to fix the Sysmon config, then schedule the hunt for after data is confirmed flowing. Without Plan Review, the analyst would have queried and gotten zero results, potentially concluded "no LSASS access found" when the real answer was "we cannot see LSASS access at all."

The Feedback stage is the other element most teams skip. A structured retrospective after every hunt builds team knowledge faster than individual experience alone. Even a 15-minute written retrospective (what worked, what failed, three lessons learned) compounds significantly over a quarter of regular hunting.

Where PAM Fits Best

PAM is best suited to structured teams that can invest the time in Plan Review and Feedback, compliance environments where documented process rigor is required, and training programs where the framework's structure teaches junior analysts the right habits. Its limitation is flexibility: for rapid intel-driven hunts where a threat report drops and a team needs to start within hours, the five-stage pre-hunt process adds friction that may be impractical.

Tip: Even if you do not adopt full PAM, steal the Plan Review step. Ask a colleague to read your hunt plan for 5 minutes before you start. It is the single highest-return process improvement in threat hunting that costs almost no time.

OTRF ThreatHunter-Playbook

The Open Threat Research Foundation (OTRF) maintains the ThreatHunter-Playbook as a community-driven, GitHub-hosted library of curated hunt playbooks. Each playbook covers a specific ATT&CK technique with pre-built queries, expected telemetry, and a documented hypothesis. The defining feature of the OTRF approach is the use of Jupyter notebooks as the hunt artifact.

The OTRF framework has three phases: Plan, Execute, Report. The simplicity is intentional. The complexity lives in the structured notebook format, not in the lifecycle model.

Phase	What It Contains	Artifact
Plan	Define the behavior being hunted. List assumptions (what must be true for this hunt to work). Map expected telemetry manifestation. Write the hunt rationale. Document prerequisites.	Notebook cells 1-N: hypothesis, assumptions, data requirements
Execute	Run queries directly in the notebook. Document pivot rationale inline. Annotate results. Each query cell contains the query, the output, and analyst commentary.	Executable notebook cells with queries + outputs + annotations
Report	Capture findings: true positives, false positives, data gaps, follow-on actions. The report IS the notebook. No separate document required.	Final notebook state = complete hunt record, re-runnable by any analyst

The Jupyter notebook as hunt artifact solves one of the field's oldest problems: documentation that gets written after the fact, from memory, and that cannot be verified or reproduced. A notebook captures every query, its exact result at that moment, the analyst's interpretation of the result, and the pivot decision. A new analyst can open the notebook, read the plan, observe the execution decisions, and re-run every query on current data to see what has changed.

The OTRF playbook library contains hundreds of pre-built hunts covering ATT&CK techniques. Each playbook is a starting point. The value is not running the playbook verbatim. It is adapting the pre-built queries to your specific data sources and environment baseline, then contributing improvements back to the community.

OTRF PLAN FORMAT

# Hunt: LSASS Memory Access via Process Injection
**Hypothesis:** An adversary accessed LSASS memory using a process with access
rights 0x1FFFFF (PROCESS_ALL_ACCESS) to extract credentials.

**ATT&CK Technique:** T1003.001 - OS Credential Dumping: LSASS Memory

**Expected Telemetry:**
- Source: Sysmon Event 10 (ProcessAccess)
- TargetImage: lsass.exe
- GrantedAccess: 0x1FFFFF, 0x1010, or 0x1410

**Assumptions:**
- Sysmon is deployed with ProcessAccess rules targeting lsass.exe
- lsass.exe is NOT running as Protected Process Light (PPL)
  Check: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL
- Log retention >= 30 days in SIEM

**Data Sources Required:**
- Sysmon Channel: Microsoft-Windows-Sysmon/Operational (Event 10)
- Retention: Minimum 30 days
- Field required: TargetImage, SourceImage, GrantedAccess, SourceUser

**What Would Disprove This:**
- No Sysmon 10 events targeting lsass.exe from non-system processes
  in the scoped time window on the scoped hosts

Tip: Even without Jupyter, you can adopt the OTRF documentation format in any tool. A SIEM dashboard with saved queries, query comments, and a linked text document capturing analyst observations produces the same knowledge artifact. The format matters less than the discipline of documenting every query and every result.

Choosing Your Framework

No framework fits every team. The right choice depends on team size, CTI maturity, documentation requirements, and whether speed or rigor is the primary constraint.

Framework	Team Size	Intel Integration	Docs Depth	Flexibility	Best For
Sqrrl Loop	Any	Low	None	Very High	Learning the concept. Mental model for any hunter.
PEAK	Any	Medium	Medium	Very High	General purpose. Solo hunters and small teams.
TaHiTI	Medium-Large	Very High	High	Medium	CTI-led teams. Regulated industries. ISAC participants.
SANS PAM	Small-Medium	Medium	High	Low-Medium	Compliance environments. Junior analyst training programs.
OTRF Playbook	Any	Low	High	High	Research teams. Community-contribution programs.

Decision Guide by Scenario

Scenario	Recommended Framework	Why
Solo hunter or team of 2-3 analysts	PEAK	Flexible, covers all hunt types, low overhead. ACT phase ensures detection rules are created without requiring formal process.
Enterprise with dedicated CTI function	TaHiTI	Intel drives every trigger. Documentation formality matches enterprise requirements. ISAC compatibility built in.
Compliance or regulated environment	SANS PAM	Plan Review and Feedback stages produce audit-ready documentation. Six-stage structure demonstrates process rigor to auditors.
Building a community-sharable hunt library	OTRF Playbook	Jupyter notebook format is reproducible and shareable. Community already uses this format. Contributions have an established intake path.
Learning threat hunting for the first time	Sqrrl Loop, then PEAK	Start with Sqrrl to understand the iterative concept. Graduate to PEAK once the loop is internalized. PEAK adds preparation and follow-through without overwhelming complexity.

The Hybrid Approach

These frameworks are not mutually exclusive. The most mature hunt programs borrow deliberately from multiple frameworks and build a hybrid that fits their team's specific context. A practical hybrid for most enterprise teams:

Use PEAK as the outer lifecycle wrapper: Prepare, Execute, Act applies to every hunt regardless of type.
Use ABLE (Chapter 2) for structuring every hypothesis in the Prepare phase.
Borrow the Plan Review step from SANS PAM before any significant hunt begins.
Use the OTRF notebook format for documentation if your tooling supports it. Adapt to a structured text document if not.
Apply TaHiTI phase logic specifically when a CTI product drives the hunt trigger, using the formal Initiation/Closure/Follow-up structure for those hunts.

Tip: The best framework is the one your team actually uses. An imperfect methodology followed consistently beats a perfect one followed sometimes. Pick something reasonable, start using it today, and refine it based on what breaks in practice. The Feedback stage (SANS PAM) or the ACT phase (PEAK) is where you capture those refinements.

Warning: Over-engineering your framework before you have completed ten hunts is a common trap. The process details that matter only become visible through practice. Start simple (PEAK or even just the Sqrrl loop). Add structure as you identify specific gaps. Complexity added before you understand what you need creates compliance theater, not better hunts.

Key Takeaways

A framework converts hunting from a one-time event into a compounding detection-building program. Without one, knowledge stays siloed and cannot scale.
The Sqrrl Loop (2015) established the foundational concept: hunting is iterative, not linear. Every hunt generates the seeds of the next.
PEAK (Prepare, Execute, Act) is the most general-purpose framework. Its ACT phase, which most hunters skip, is what builds lasting detection coverage from hunt findings.
TaHiTI was developed by the Dutch FI-ISAC for regulated environments. It explicitly targets TTP-level hunting over IOC hunting and requires CTI integration at every phase.
SANS PAM's unique contribution is the Plan Review stage: mandatory peer review before execution begins. This single step prevents the most common hunt failures.
The OTRF ThreatHunter-Playbook uses Jupyter notebooks as hunt artifacts, making every hunt reproducible and shareable. Any analyst can re-run the exact hunt on new data.
The best framework is the one your team actually uses consistently. Borrow elements from multiple frameworks and refine based on what breaks in practice.

Knowledge Check

Click an answer to reveal the explanation.

Q1. What are the three phases of the PEAK framework?

A. Plan, Execute, Report
B. Purpose, Execute, Analyze
C. Prepare, Execute, Act
D. Prioritize, Evaluate, Archive

Q2. TaHiTI was developed by which organization and for what environment?

A. Splunk SURGe, for general-purpose enterprise environments
B. SANS Institute, for compliance-driven organizations
C. Dutch Financial Sector ISAC (FI-ISAC), for regulated financial environments with mature CTI functions
D. MITRE, for government and critical infrastructure

Q3. How many stages does the Sqrrl Hunting Loop have?

A. 3
B. 4
C. 5
D. 6

Q4. What is the unique contribution of the SANS PAM model that no other framework includes?

A. Using Jupyter notebooks as hunt artifacts
B. Explicit CTI integration at every phase
C. A mandatory peer review (Plan Review) step before execution begins
D. Three distinct hunt types: hypothesis-driven, baseline, and model-assisted

Q5. What artifact does the OTRF ThreatHunter-Playbook use to capture each hunt, and why is this format valuable?

A. PDF reports, because they are easy to share and archive
B. Sigma rules, because they are platform-agnostic detection rules
C. Jupyter notebooks, because they capture queries, outputs, and analyst annotations in a single executable document that any analyst can re-run
D. STIX/TAXII feeds, because they are the standard threat intelligence sharing format