CHAPTER 07 30 MIN READ ADVANCED

Hunt Lifecycle and Documentation

Two analysts on the same team ran hunts for the same TTP six months apart, used different queries, found different things, and documented them in different formats in different locations. Neither could build on the other's work. The hunt program made no measurable progress despite 200 hours of analyst effort. Structured lifecycle management is what separates a hunt program that compounds knowledge from one that resets every time a hunt session ends.

PEAK reporting KPIs

The Full Hunt Lifecycle

PEAK, introduced in Chapter 3, provides the operational backbone for every hunt. This chapter covers PEAK in practice, with the specific activities, deliverables, and quality checks that make each phase effective rather than ceremonial.

The Three Phases, By Time Allocation

Phase	Share of Hunt Time	Common Failure Mode
PREPARE	20-30%	Most hunters rush this phase. The ones who invest in it find more and waste less time during execution.
EXECUTE	50-60%	The actual query work, analysis, and iteration.
ACT	20-30%	Most hunters skip or compress this. The ones who do not skip it build better programs over time.

Structure Scales, Depth Changes

The lifecycle applies to every hunt regardless of scale. A 2-hour hunt has a lighter version of the same structure. A 2-week campaign hunt has a full version. The structure does not change; only the depth of each phase changes with scope.

What distinguishes a structured hunt from an ad hoc investigation: the written plan, the execution log, and the ACT phase output. Without all three, you are investigating, not hunting. The distinction matters for program maturity measurement, institutional knowledge retention, and the ability to build detections from hunt findings.

Note: CrowdStrike OverWatch's SEARCH methodology (Sense, Enrich, Analyze, Reconstruct, Communicate, Hone) maps directly to PEAK. Their "Hone" phase is the equivalent of PEAK's ACT phase. CrowdStrike invests heavily in Hone because that is where program improvement lives. Every iteration of Hone makes the next hunt cycle faster and more accurate.

PREPARE Phase in Detail

The Five Steps

PREPARE is where most hunt value is won or lost before a single query runs.

Select Hypothesis

Score against threat relevance, data availability, business risk, and hunt coverage recency (Chapter 2 framework)

→

Intelligence Research

Check ATT&CK procedure examples, threat reports, and HYPOS for structured hypothesis variants

→

Scope Definition

Write down hypothesis, target systems, time window, data sources, and exclusions

→

Query Planning

Draft queries, tables, filters, and aggregation logic before opening the SIEM

→

Plan Review

A second analyst reviews the plan before execution starts

Step 2, intelligence research: HYPOS at h3ad-sec.github.io/HYPOS/ provides structured hypothesis variants. Time spent here directly reduces false positive investigation time during execution.

Step 3, scope definition requires five fields:

Hypothesis in ABLE format
Target systems: all endpoints, specific segments, cloud, identity, or a defined subset
Time window with justification for the choice
Data sources with explicit confirmation each is available and quality-checked
Out of scope: explicit exclusions documented (dev environment, known test systems, specific known-good processes)

Step 5, plan review: the SANS PAM (Plan, Action, Measure) approach formalizes this. Peer review catches scope gaps, wrong data source assumptions, and missing exclusion filters before they waste execution time.

Worked Example

Example: Full hunt scoping document for an APT29-style lateral movement hunt.

Hypothesis: APT29 used Windows Remote Management (WinRM, T1021.006) for lateral movement from compromised workstations to domain controllers, leaving Windows Remote Management service connection events (Event 6 in the Microsoft-Windows-WinRM/Operational channel) and PowerShell remoting logs (Event 400 and 800 in PowerShell Operational) on target hosts.

Target systems: All Windows endpoints, priority on domain controllers and file servers. Standard workstations included as source hosts.

Time window: Last 30 days. Justification: APT29's known operational tempo in recent campaigns suggests activity within 30-day windows after initial compromise.

Data sources: Sysmon Event 3 (network connections to port 5985/5986, all endpoints, confirmed present and quality-checked 2026-06-01), Windows Security Event 4624 Type 3 (network logons, confirmed), WinRM Operational log (confirmed on DCs only; gap on standard workstations, documented).

Out of scope: Linux and macOS hosts, cloud infrastructure, known IT admin machines using WinRM for authorized management (documented list from IT ops team).

Success criteria: Hunt confirms if: WinRM connections are observed between non-server hosts, or between workstations and DCs outside of documented admin activity. Hunt is complete when all anomalous WinRM connections are triaged or when confirmed coverage gap prevents answering the hypothesis.

EXECUTE Phase in Detail

Three Sub-Phases

EXECUTE has three sub-phases, each with a specific quality check before moving to the next.

Gather

Pull data, run initial queries, verify record types and event counts are plausible before analyzing

→

Analyze

Apply Chapter 5's statistical methods and the Diamond Model, score evidence with Admiralty ratings as you go

→

Iterate

Investigate and classify each anomaly: false positive, true positive, or coverage gap

Gather: if data quality is bad, stop. Document the gap and its likely cause. This is a control deficiency finding, not a hunt result. Do not spend analysis time on bad data.

Iterate: if false positive, document and add to the filter list. If true positive, pivot and escalate. If coverage gap, document for the data source team. Generate new hypotheses from unexpected tangential findings and add them to the backlog, not the active hunt scope.

Execution Log Discipline

Execution log discipline is what separates a documented hunt from a forgotten session. Keep a running log as you work. Include: timestamp, query run in copy-paste format, result count, action taken, and reasoning for each action. This log becomes the body of your after-action report and proves your methodology to any reviewer.

MARKDOWN

## Hunt Execution Log
**Hypothesis:** APT29 WinRM lateral movement (T1021.006)
**Analyst:** [name] | **Date:** 2026-06-02

### 09:15 · Initial scope query
Query: DeviceNetworkEvents
| where RemotePort in (5985, 5986)
| summarize count() by DeviceName, RemoteIP
Result: 847 connection events across 23 hosts
Action: Filtering to connections between non-server hosts (workstation-to-workstation)

### 09:32 · Refined: workstation-to-workstation WinRM
Query: [refined with asset type filter using device classification]
Result: 12 events across 3 host pairs
Action: Reviewing host pairs individually
  - Pair 1: IT-ADMIN-01 to FILESERVER-03, known admin activity, documented. FP.
  - Pair 2: LAPTOP-128 to WORKSTATION-44, unusual. No admin activity documented.
  - Pair 3: LAPTOP-128 to FILESERVER-03, same source host as pair 2.

### 09:55 · Suspicious finding: LAPTOP-128 lateral movement
Both connections originated from LAPTOP-128 at 02:17 on 2026-05-28.
Connection to WORKSTATION-44 (standard endpoint) and FILESERVER-03 (file server).
Time is outside business hours. User account associated is a standard user.
Action: Pivot to Sysmon Event 1 on target hosts for timestamp. Check what process spawned.

### 10:12 · EDR process tree pivot on FILESERVER-03
FILESERVER-03 shows wsmprovhost.exe spawning cmd.exe at 02:18.
cmd.exe executes: net user /domain and net localgroup administrators.
Enumeration commands. This is post-exploitation behavior.
Confidence: 85 (A1 from EDR). Severity: HIGH (file server with domain credentials).
Action: Escalate to IR team. Ticket #IR-2026-0547.
New hypothesis for backlog: Hunt for other WinRM sessions from LAPTOP-128 in last 60 days.

ACT Phase in Detail

Three Components

ACT is where hunt value becomes permanent. All three components are required. Skipping any one converts a completed hunt into a dead-end session.

Preserve

Document the full hunt so future analysts can reproduce it without asking questions

→

Detect

Turn confirmed TPs into Sigma rules, and coverage gaps into data source improvement requests

→

Communicate

Deliver the right information to the right audience at the right level of detail

Preserve: without documentation, the hunt exists only in one analyst's head and disappears when they take PTO or change roles.

Detect: Finding to Detection Rule

The path from hunt finding to detection rule: confirmed TP, write a Sigma rule that captures the behavior, test against known-good and known-bad data, submit to TRACERULES at h3ad-sec.github.io/TRACERULES/, monitor alert volume in SIEM for the first 30 days to tune false positives. Hunts that do not produce detections are not being fully operationalized.

Communicate: Who Needs What

Audience	What to Share
IR team	If there is an active threat: the full pivot trail, evidence chain, and confidence rating
Management	If the finding is significant: a one-page summary with business impact language, not technical query details
Data source team	If coverage gaps were found: a specific, actionable improvement request with the ATT&CK technique gap documented
Threat intel team	If you observed TTPs not yet in your intel profiles, or if actor attribution was clarified by the finding

Tip: If a hunt finds nothing, the ACT phase still matters. Document the null finding with the data quality confirmation. Six months from now, when a peer asks whether WinRM lateral movement has been hunted, you have a specific dated answer. "We hunted this on 2026-06-02 across 30 days of data, good quality, no evidence found" is a valuable organizational statement.

Classifying Hunt Outcomes

The Four Standard Outcomes

Red Canary, OTRF, and mature hunt teams use a consistent classification across all hunts, which enables program-level metrics that are otherwise impossible to compute.

Outcome	Definition	Action	Who Is Notified
True Positive (TP)	Confirmed malicious or suspicious activity after false positives are ruled out	Escalate to IR. Create detection rule. Document full evidence chain.	IR team, management (if high severity), threat intel team
False Positive (FP)	Investigation confirmed the activity is legitimate	Document the FP pattern. Update query exclusion filters. Update team knowledge base.	Hunt team internal. Asset owner notified if they provided context.
Coverage Gap	The data needed to test the hypothesis does not exist or is of insufficient quality	Document the gap specifically (missing log source, missing field, retention too short). Submit as control deficiency to data source team.	Data source / security engineering team. Management if gap is high-impact.
No-Find	Hypothesis tested against confirmed good-quality data, no evidence found	Document as No-Find with explicit data quality confirmation. This is a positive result: coverage is working.	Hunt team internal. Management summary if the technique is high-priority.

A Fifth Outcome

A fifth outcome gets missed by most teams: New Hypothesis Generated. During execution you found something tangentially suspicious that was not your original target. Add it to the backlog immediately with the context that generated it. Do not chase it mid-hunt. It is a separate scoped hunt. The backlog entry with context is more valuable than an undocumented detour that disrupts the current hunt scope.

Warning: Do not collapse Coverage Gap and No-Find. They look identical in output (no evidence found) but mean opposite things. No-Find with good data means your coverage is working. Coverage Gap means you cannot draw any conclusion at all. Distinguish them explicitly in every hunt record. Reporting a Coverage Gap as a No-Find gives management false confidence that a technique has been hunted when it has not.

After-Action Report Template

Why It Exists

The after-action report is the formal output of a completed hunt. It replaces tribal knowledge with documented process. Any analyst on the team should be able to read the after-action report and reproduce the hunt, understand why decisions were made, and build on the findings without asking questions.

The Template

TEMPLATE

HUNT AFTER-ACTION REPORT
─────────────────────────────────────────────

Hypothesis: [ABLE format: Actor, Behavior, Location, Evidence]
Hunt Dates: [start date] to [end date]
Analyst: [name]
ATT&CK Technique: [e.g., T1021.006, Remote Services: Windows Remote Management]

─── SCOPE ───────────────────────────────────
Target Systems: [all endpoints / specific segments / cloud / identity]
Time Window: [start] to [end]: [justification for window length]
Data Sources:
  - [source 1]: [available / quality confirmed / gap noted]
  - [source 2]: [available / quality confirmed / gap noted]
Out of Scope: [explicit exclusions with rationale]

─── EXECUTION SUMMARY ───────────────────────
Queries Run: [count]
Records Analyzed: [approximate count]
Data Quality Issues: [none / specific issue and impact on hunt coverage]

─── FINDINGS ────────────────────────────────
Result Classification: [TP / FP / Coverage Gap / No-Find]
Finding Summary: [2-3 sentences describing what was found or confirmed absent]
Evidence Quality: [Admiralty rating, e.g., A2, own EDR, probably true]
Confidence Score: [0-100 with brief rationale]
Severity: [Critical / High / Medium / Low with rationale]

─── ACTIONS TAKEN ───────────────────────────
Escalated to IR: [Yes, Ticket #IR-XXXX-XXXX / No]
Detection Rules Created: [Yes, TRACERULES link / No]
Data Source Improvement Requests: [Yes, description / No]
New Hypotheses Added to Backlog: [list with brief context for each]

─── LESSONS LEARNED ─────────────────────────
What worked: [specific tactics or queries that were efficient]
What to improve: [scope too broad, missing data, query logic issues, etc.]

Worked Example

Example: Completed after-action report for the APT29 WinRM hunt from Sections 2 and 3.

Hypothesis: APT29 used WinRM (T1021.006) for lateral movement from compromised workstations to domain controllers. Actor: APT29. Behavior: WinRM lateral movement (T1021.006). Location: Windows endpoints, production environment. Evidence: WinRM connection events (port 5985/5986), PowerShell remoting logs (Events 400/800), network logon events (Event 4624 Type 3).

Hunt Dates: 2026-06-02 to 2026-06-02 (same-day hunt, 30-day data window).

Result Classification: True Positive.

Finding Summary: LAPTOP-128 made WinRM connections to WORKSTATION-44 and FILESERVER-03 at 02:17 on 2026-05-28, outside business hours using a standard user account. EDR process tree on FILESERVER-03 confirmed wsmprovhost.exe spawning cmd.exe executing domain enumeration commands. Escalated to IR as ticket #IR-2026-0547.

Evidence Quality: A1, own EDR telemetry, confirmed in environment. Confidence: 85. Severity: HIGH (file server with domain credentials).

Actions Taken: Escalated to IR. Detection rule created for WinRM connections from non-admin workstations to servers outside business hours (TRACERULES entry #TR-20260602-001). New hypothesis added: "Hunt WinRM activity from LAPTOP-128 in prior 60 days for earlier lateral movement."

Lessons Learned: Asset classification (server vs. workstation) was not available in DeviceNetworkEvents. Required a join to device inventory table. Future WinRM hunts should include asset classification join in the query template.

Hunt KPIs and Metrics

How do you measure a hunt program? Most security metrics are activity metrics that measure inputs, not outcomes. These are outcome metrics that tell you whether the program is actually working.

Core KPIs

Six outcome metrics, what each measures, and the targets that separate a mature program from a struggling one:

KPI	What It Measures	Target (Mature Program)	Low Signal	Action if Below Target
Hunt Yield Rate	Confirmed TPs divided by total hunts conducted	>15%	<5% (too broad or poor data quality); >30% may mean hunts are too narrow, missing novel activity	Improve hypothesis intel input or data quality
Mean Time to Confirm (MTTC)	Time from hunt start to result classification (TP, FP, Gap, or No-Find)	Trend decreasing quarter-over-quarter	Increasing trend	Improve query templates, FP suppression, asset context
Detection Rule Creation Rate	New detection rules created from hunt findings divided by total hunts completed	>50%, roughly one rule every two hunts	<20% (zero detections from ten hunts means findings aren't being operationalized)	Build explicit Sigma conversion step into ACT phase workflow
ATT&CK Coverage (90-day)	Percentage of relevant ATT&CK techniques (per your actor profiles and sector) covered by at least one hunt in the prior 90 days	Growing % toward sector-relevant techniques	Flat for two or more quarters	Diversify hypothesis backlog across ATT&CK tactic categories
Data Gap Discovery Rate	Number of confirmed coverage gaps identified per quarter	1-3 actionable gaps per quarter	0 for two consecutive quarters (either exceptionally covered, or not hunting broadly enough)	Expand hypothesis coverage to less-hunted log sources
Dwell Time Reduction	Gap between initial compromise timestamp and hunt discovery timestamp, compared to pre-program average	Decreasing trend year-over-year	No change or increasing	Increase hunt frequency on high-dwell-time techniques

Tip: Hunt Yield Rate below 5% is a signal, not a failure. It means hypotheses need better intel input or data quality needs improvement. Both are fixable. Neither is catastrophic. Track it quarterly and act on the trend, not individual hunt results.

Warning: Alert count, query count, and hours hunted are not KPIs. They measure activity, not effectiveness. A team running 100 queries per week that produces zero detections and zero TPs is spending 100% of its capacity on activity with no measurable security outcome. A team running 20 queries per week that produces 5 detections and 3 TPs is delivering more value with 20% of the query volume.

Key Takeaways

PEAK's three phases have distinct time allocations: PREPARE (20-30%), EXECUTE (50-60%), ACT (20-30%). Most analysts invest too little in PREPARE and ACT.
A structured hunt differs from an ad hoc investigation by three things: a written plan, an execution log, and an ACT phase output. All three are required.
ACT phase has three components: preserve (documentation), detect (Sigma rule creation and data gap requests), and communicate (right information to the right people at the right level of detail).
Coverage Gap and No-Find are distinct outcomes. No-Find with good data confirms coverage is working. Coverage Gap means you cannot draw any conclusion. Never report them as the same outcome.
The after-action report is the institutional memory of a completed hunt. Any analyst should be able to reproduce the hunt from the report without asking questions.
Hunt Yield Rate above 15% is the target for a mature program. Detection Rule Creation Rate above 50% means hunt findings are being operationalized into durable detection.
Activity metrics (query count, hours hunted) are not KPIs. Outcome metrics (yield rate, dwell time reduction, ATT&CK coverage) measure whether the program is working.

Knowledge Check

Click an answer to reveal the explanation.

What are the three components of the PEAK ACT phase?

The ACT phase has three components: Preserve (document the hunt for institutional memory), Detect (convert confirmed findings into Sigma rules submitted to TRACERULES and convert gaps into data source improvement requests), and Communicate (deliver the right findings to the right people at the appropriate level of detail). Skipping any one of the three means the hunt does not fully deliver its potential value.

A hunter tests a hypothesis and finds no evidence. The data quality was confirmed good. Which outcome classification applies?

No-Find applies when the hypothesis was tested against confirmed good-quality data and no evidence was found. This is a positive result: it means either the adversary has not used the technique in your environment, or your detection coverage for this technique is working. Coverage Gap applies only when the data needed to test the hypothesis does not exist or is insufficient quality.

What is the Hunt Yield Rate target for a mature hunt program?

The target Hunt Yield Rate for a mature program is above 15%. Below 5% signals that hypotheses need better intel input or data quality needs improvement. Above 30% may indicate hunts are too narrow and focused only on already-known patterns, missing novel activity. A yield rate of 15-25% reflects a healthy balance of confirmed findings and exploratory coverage.

Which fields are required in a hunt after-action report?

A complete after-action report requires: hypothesis (ABLE format), scope (target systems, time window, data sources, out-of-scope), execution summary (queries run, records analyzed, data quality issues), findings (result classification, finding summary, evidence quality with Admiralty rating, confidence and severity), actions taken (IR escalation, detection rules, data gap requests, new hypotheses), and lessons learned. A partial report cannot be reproduced by another analyst without asking questions.

What is the difference between a Coverage Gap and a No-Find result?

These outcomes are operationally distinct. A Coverage Gap means you cannot draw any conclusion about the hypothesis because the required data does not exist or is poor quality. A No-Find means the data was present, quality was confirmed, and no evidence matching the hypothesis was found. Reporting a Coverage Gap as a No-Find gives management false confidence that a technique has been hunted when it actually has not been testable.