Threat Hunt Hypothesis and Report Template: plan, record and close every hunt

A threat hunt without a written hypothesis and a recorded outcome cannot be measured, repeated or turned into lasting detection. Many teams hunt well and then lose the value: the query lives in one analyst's notebook, the "nothing found" result is never written down, and the same ground is covered again six months later. This template gives each hunt a single record from hypothesis to closure, structured around the PEAK framework's Prepare, Execute and Act phases and the ABLE method for scoping hypotheses. It is for threat hunters, SOC leads and detection engineers who want hunts to feed the detection backlog and the incident process in a controlled way. For the discipline itself see the Threat Hunting Guide.

How to use this template

Open one record per hypothesis before any data is queried, and close it with an outcome even when nothing is found. A negative result is a result: it tells you which behaviour was checked, over which data and period, and what visibility gaps limited the answer.

• Hunt types: PEAK, published by SURGe by Splunk, describes three: hypothesis-driven, baseline (exploratory data analysis of what normal looks like) and model-assisted threat hunting (M-ATH), which uses machine learning models. Record which type you are running; the template works for all three, with section 1 stating a baseline question instead of a hypothesis where needed.
• Phases: sections 1 and 2 cover Prepare, section 3 covers Execute, sections 4 to 8 cover Act and the hand-offs to incident response.
• Storage: keep records in a searchable repository with the queries committed alongside, so the next hunter can rerun them.
• Time box: set an end date. PEAK allows hunters to refine the hypothesis during execution, but open-ended hunts drift.

1. Scope and triggers

• Hunt ID: [HUNT-YYYY-NNN] Hunt type: [hypothesis-driven | baseline | model-assisted] Dates: [start] to [planned end]
• Trigger: [What prompted the hunt: new threat intelligence report, incident at a peer, red team finding, ATT&CK coverage gap, new log source, regulatory concern, scheduled rotation through the backlog.]
• Topic: [General area, for example persistence in the cloud identity tenant.]
• Hypothesis: [One testable sentence that can be proved or disproved.] Example: "An attacker with access to our Entra ID tenant has added credentials to existing application registrations to keep access after password resets (ATT&CK T1098.001 Additional Cloud Credentials)."
• ABLE breakdown:
  • Actor: [Optional: named group or actor type, for example financially motivated intrusion set targeting SaaS.]
  • Behaviour: [One or two specific behaviours, not a full kill chain, with ATT&CK IDs.]
  • Location: [Where the behaviour would appear: tenant, subscription, segment, host group.]
  • Evidence: [Data sources and what the behaviour looks like in them, for example audit log operations that add a secret or certificate to an application, and sign-ins by that application from new IP ranges.]
• Baseline variant: [For a baseline hunt, replace the hypothesis with a question about normal, for example "Which service accounts authenticate interactively, from where, and how often?" and record the baseline period used.]
• Scope: [Systems, accounts and time window in scope; explicit exclusions; data retention limit that bounds the look-back.]
• Out of scope and assumptions: [For example, no visibility into third-party tenants; assumes audit logging enabled since [date].]

Use this table to test a draft hypothesis before approval. PEAK's guidance is to start from a topic, make it testable, then narrow it further for large environments.

2. Roles and contacts

• Plan: [Data access needed, tools, expected queries, effort estimate in hunter days, any change approvals for data collection.]
• Handling rules: [Privacy and legal constraints: personal data in mailbox or browsing logs, works council or monitoring policy approval, who may see raw results.]

3. Detection and triage

• Data gathered: [For each source: name, time range actually available, volume, fields used, gaps found. Note if retention cut the look-back short.]
• Pre-processing: [Normalisation, joins, enrichment with asset and identity inventories, stacking or frequency analysis applied.]
• Queries and analysis: [Link each query in the repository with commit hash. Describe the analysis method: stacking least frequent values, time series, graph of relationships, model output.]
• Look-back achieved: [Planned window versus the window actually searched for each source. A 90 day hypothesis tested against 30 days of logs is a partial answer and the outcome must say so.]
• Hypothesis refinements: [Each change to the hypothesis during the hunt, with the reason.]
• Findings log:

Classify every finding. "Benign but risky" findings, such as an application registration holding a credential that never expires, are often the most valuable output of a hunt even when no attacker is found.

4. Containment

Hunters do not contain. A malicious or high-confidence suspicious finding is escalated to incident response immediately (PEAK's Escalate Critical Findings step), and this section records the hand-off.

• Escalation criteria: [Any evidence of active attacker access, data theft or tampering with security tooling; any finding meeting [Organisation]'s incident criteria.]
• Escalated to: [Name, time UTC, incident or case ID.]
• Evidence handed over: [Queries, exported events, hash list, timeline. Preserve integrity: store exports read-only with hashes.]
• Hunt status after escalation: [Paused | continued in parallel under IR direction | closed and merged into the incident.] Continuing to query can be useful but must not alert an active attacker; let the incident commander decide. See the Incident Scoping and Containment Strategy Guide.

5. Eradication

Eradication of an attacker belongs to the incident record. In the hunt record, track the remediation of hygiene findings that were not incidents.

Credential and secret findings are common in identity-focused hunts. Route them to the owners of those non-human identities. See the Honeytokens and Canary Credentials Guide for a complementary way to catch their misuse.

6. Recovery

• Visibility gaps fixed: [Log sources enabled, retention extended, fields added, parsing fixed as a result of the hunt. Owner and date.]
• Hunt preserved: [Location of archived queries, notebooks, data extracts and tool versions so a future hunter can repeat it. PEAK's Preserve Hunt step.]
• Rerun plan: [Whether and when to repeat the hunt, for example quarterly until a detection replaces it.]

7. Communication and notification

• Audience: [SOC, detection engineering, IAM and platform owners, CISO, risk committee for significant results.]
• Executive summary: [Three sentences: hypothesis, outcome (validated, refuted, inconclusive), what changes as a result.]
• Distribution and classification: [Internal only; redact personal data; incident details stay in the incident record.]
• Owner notifications: [Each hygiene finding owner told directly with the ticket reference, the risk in one sentence and the due date, rather than learning about it from a programme report.]
• Visibility report: [Data gaps found, sent to the logging or platform owner with the hunt ID so the request can be prioritised against other hunts that hit the same gap.]
• Intelligence sharing: [Whether indicators or behaviours will be shared with an ISAC or sector group, and approval obtained.]

8. Post-incident review

• Outcome: [Validated | refuted | inconclusive due to data gaps.] State the confidence and why.
• Detection candidates: [For each: behaviour, logic summary, expected false positive rate, and link to a new detection record.] Use the Detection Rule Documentation Template so the hunt's context becomes the rule's goal, blind spots and validation.
• Backlog additions: [New leads and topics found during the hunt, added back to the hunt backlog with priority.]
• Effort: [Hunter days spent; data access delays.]
• Lessons: [What would have made the hunt faster or more conclusive.]
• Sign-off: [Approver, date.]

Implementation guidance

1. Build the backlog first. Seed it from ATT&CK techniques with no detection coverage, recent intelligence and incident lessons. Rank by likely impact and data availability.
2. Pilot on three hunts. Run them with the full template, then cut fields nobody filled in meaningfully. Keep hypothesis, ABLE, data gaps, findings and outcome as non-negotiable.
3. Link to the incident process. Agree in advance with the IR lead what counts as a critical finding and how quickly it must be escalated, and test that route in a tabletop exercise.
4. Feed detection engineering. Track how many detection candidates become production rules, and how long it takes.
5. Review the programme quarterly. Look across records for repeated data gaps; they are the strongest case for logging investment.

Metrics to track: hunts closed per quarter with a recorded outcome; percentage producing a detection candidate; candidates promoted to production; hygiene findings remediated within their due date; data gaps closed; ATT&CK techniques hunted in the last 12 months.

Common failure patterns: hypotheses too broad to disprove ("look for APT activity"); no record of the look-back actually achieved, so a clean result is overstated; findings escalated by chat with no case ID; detection candidates never picked up; repeated hunts that ignore what the last record found.

Standards and references: Splunk SURGe: Introducing the PEAK Threat Hunting Framework · Splunk SURGe: Hypothesis-Driven Hunting with the PEAK Framework · NIST: SP 800-53 Rev. 5 (RA-10 Threat Hunting) · NIST: SP 800-61 Rev. 3 Incident Response Recommendations · MITRE ATT&CK: Additional Cloud Credentials · Palantir: Alerting and Detection Strategy Framework

Related NHI Mgmt Group resources: Threat Hunting Guide · KQL for Threat Hunting Guide · Detection Engineering Guide · Incident Response Guide