Hunt Lifecycle and Documentation

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 are not equally weighted in time or importance:

• PREPARE: 20 to 30% of total hunt time. Most hunters rush this phase. The ones who invest in it find more and waste less time during execution.
• EXECUTE: 50 to 60% of total hunt time. The actual query work, analysis, and iteration.
• ACT: 20 to 30% of total hunt time. Most hunters skip or compress this. The ones who do not skip it build better programs over time.

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.

PREPARE Phase in Detail

PREPARE is where most hunt value is won or lost before a single query runs. The five steps of the PREPARE phase:

Step 1: Select hypothesis from backlog. Use the priority score framework from Chapter 2: threat relevance (is this actor or technique active against your industry?), data availability (do you have the logs to test it?), business risk (what is the impact if the technique is present?), and hunt coverage recency (when was this TTP last hunted?).

Step 2: Intelligence research. What do you know about this TTP? Who uses it, what variations exist, what artifacts it leaves? Check MITRE ATT&CK procedure examples, recent threat reports from your intel feeds, and HYPOS at h3ad-sec.github.io/HYPOS/ for structured hypothesis variants. Time spent here directly reduces false positive investigation time during execution.

Step 3: Scope definition. Write it down. Required 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 4: Query planning. Draft queries before opening the SIEM. What tables? What filters? What aggregation logic? Drafting first prevents the common failure of opening the SIEM and writing whatever comes to mind, which typically produces queries that are either too broad (massive result sets) or too narrow (zero results that look like no findings).

Step 5: Plan review. One other analyst reviews the plan before execution starts. 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.

EXECUTE Phase in Detail

EXECUTE has three sub-phases: gather, analyze, and iterate. Each has a specific quality check before moving to the next.

Gather: Pull the relevant data. Run initial queries. Before analyzing results, verify data quality: are the expected record types present? Are event counts plausible for the environment size and time window? 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.

Analyze: Apply the statistical methods from Chapter 5. Frequency analysis, long-tail sorting, baseline deviation comparison. Look for anomalies. Apply the Diamond Model for pivot structure: for each anomaly, which other vertices can you pivot toward? Score evidence with Admiralty ratings as you go, not after the fact.

Iterate: For each anomaly, investigate and classify. 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 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.

## 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

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

Preserve: Document the full hunt in a standard format. Future analysts and future-you need to reproduce this hunt without asking questions. The documentation is the institutional memory. Without it, the hunt exists only in one analyst's head and disappears when they take PTO or change roles.

Detect: Every confirmed true positive should produce a detection rule. Every confirmed coverage gap should produce a data source improvement request submitted to the engineering team. 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 to know what, and at what level of detail?

• IR team: if there is an active threat, give them 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.

Classifying Hunt Outcomes

Four standard outcome classifications are used by Red Canary, OTRF, and mature hunt teams. Using a consistent classification across all hunts enables program-level metrics that are otherwise impossible to compute.

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.

After-Action Report Template

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.

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 — OR — 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.]

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

Hunt Yield Rate: confirmed TPs divided by total hunts conducted. Target: above 15% for mature programs. Below 5% signals that hypotheses are too broad, data quality is insufficient, or false positive management is poor. Above 30% may indicate hunts are too narrow and are missing novel activity.

Mean Time to Confirm (MTTC): time from hunt start to result classification (TP, FP, Gap, or No-Find). Track the trend over time. Decreasing MTTC means improving efficiency from better query design, better false positive suppression, and accumulated environment knowledge.

Detection Rule Creation Rate: new detection rules created from hunt findings divided by total hunts completed. Target: above 50%. Every two hunts should produce at least one new detection rule. Zero detections from ten hunts means hunt findings are not being operationalized into durable detection capability.

ATT&CK Coverage: percentage of relevant ATT&CK techniques covered by at least one hunt in the prior 90 days. "Relevant" is defined by your actor profiles and industry sector. Track this quarterly. Growing percentage means improving program maturity.

Data Gap Discovery Rate: number of confirmed coverage gaps identified per quarter. A team identifying zero gaps is either exceptionally covered (unlikely) or not hunting broadly enough to encounter gaps. Gaps are expected. Discovering them is a program health indicator.

Dwell Time Reduction: when a hunt finds an active threat, measure the gap between the initial compromise timestamp and the hunt discovery timestamp. Compare this to your pre-program dwell time average. Decreasing dwell time is the clearest evidence that the hunt program is delivering security value.