Threat Hunting Plan and Report Template (ATT&CK)

Threat Hunting Plan and Report: [Hunt title]

Plan and report for one threat hunt: the intelligence trigger and hypothesis, the MITRE ATT&CK techniques in scope, the data and its coverage gaps, the queries, the baseline and outlier method, the findings, escalations to incident response, the detections and other outputs the hunt created, and the hunt metrics. Supports three hunt types: hypothesis-driven, baseline (exploratory data analysis) and model-assisted. Technique references follow MITRE ATT&CK Enterprise v20 (October 2026). The hunt types and the Prepare, Execute, Act phases (with Knowledge) follow the PEAK threat hunting framework (Splunk SURGe, April 2023); they map to the TaHiTI methodology phases Initiate (Prepare), Hunt (Execute) and Finalize (Act), published for the Dutch financial sector in 2018. Both are cited by name only and the text here is original. Escalations follow NIST SP 800-61 Rev. 3 (April 2025) through the organisation's incident response plan. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company on AWS, hunting for misuse of long-term cloud access keys.

Document control

Approvals

Revision history

Contents

1. Hunt summary
2. Hunt type and method
3. Trigger and hypothesis
4. ATT&CK techniques in scope
5. Scope, data sources and coverage gaps
6. Queries
7. Baseline and outlier method
8. Execution log
9. Findings
10. Escalations
11. Outputs
12. Metrics
13. Team, rules of engagement and data handling
14. Glossary and references
15. Standard and licence note

1. Hunt summary

2. Hunt type and method

This hunt (Example): hypothesis-driven, with a baseline step (section 7) to set the outlier threshold.

Phases used in this template: the PEAK phases Prepare, Execute and Act, with Knowledge carried across all three:

Mapping to TaHiTI: Prepare corresponds to Initiate, Execute to Hunt and Act to Finalize. Check the TaHiTI publication for the activities inside each of its phases. Teams that run TaHiTI can keep their phase names; the sections of this template stay the same.

3. Trigger and hypothesis

3.1 Intelligence trigger

3.2 Hypothesis

Example: "At least one Corvid Commerce long-term IAM user access key has been used in the last 30 days from a network we do not operate to call many different read-only APIs in a short period, consistent with enumeration after credential theft."

Observable evidence that would support it:

• Read-only API calls signed with a long-term key from an address not in the known network register.
• A higher number of distinct API names per key in a short window than the key's own history.
• The key's first use from a new network owner (autonomous system).

Evidence that would refute it: every long-term key's calls come from registered networks, or unlisted use matches documented, authorised activity.

4. ATT&CK techniques in scope

ATT&CK v19 split Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112); v20 keeps that split. If a pivot finds log tampering, map it to T1685.002 Disable or Modify Tools: Disable or Modify Cloud Log under Defense Impairment.

5. Scope, data sources and coverage gaps

5.1 Scope

5.2 Data sources

5.3 Coverage gaps

Record each gap against the Security Logging Standard (security/security-logging-standard) so it is tracked to closure outside the hunt.

6. Queries

-- Q1 data completeness per account and day (Example)
SELECT recipient_account_id,
       DATE(event_time) AS day,
       COUNT(*) AS events,
       AVG(CASE WHEN access_key_id IS NULL THEN 1.0 ELSE 0.0 END) AS null_key_ratio
FROM cloudtrail
WHERE event_time >= TIMESTAMP '2026-08-15 00:00:00'
GROUP BY recipient_account_id, DATE(event_time)
ORDER BY recipient_account_id, day;

-- Q2 long-term keys with read-only calls from unlisted networks (Example)
SELECT access_key_id, user_arn,
       COUNT(*) AS events,
       COUNT(DISTINCT source_ip) AS source_ips
FROM cloudtrail c
WHERE identity_type = 'IAMUser'
  AND access_key_id LIKE 'AKIA%'
  AND (event_name LIKE 'List%' OR event_name LIKE 'Describe%' OR event_name LIKE 'Get%')
  AND NOT EXISTS (SELECT 1 FROM known_networks n WHERE cidr_contains(n.cidr, c.source_ip))
  AND source_ip NOT LIKE '%.amazonaws.com'
GROUP BY access_key_id, user_arn;

-- Q3 highest distinct API names per key in 10-minute buckets (Example)
SELECT access_key_id, MAX(distinct_apis) AS max_distinct_10m
FROM (
  SELECT access_key_id,
         time_bucket(event_time, INTERVAL '10' MINUTE) AS bucket,
         COUNT(DISTINCT event_name) AS distinct_apis
  FROM q2_events
  GROUP BY access_key_id, time_bucket(event_time, INTERVAL '10' MINUTE)
) t
GROUP BY access_key_id;

-- Q4 daily distinct API names per key, all networks (Example)
SELECT access_key_id, DATE(event_time) AS day,
       COUNT(DISTINCT event_name) AS distinct_apis
FROM cloudtrail
WHERE identity_type = 'IAMUser' AND access_key_id LIKE 'AKIA%'
GROUP BY access_key_id, DATE(event_time);

-- Q5 pivot on one key: non-read-only activity (Example)
SELECT event_time, event_source, event_name, source_ip, error_code
FROM cloudtrail
WHERE access_key_id = 'AKIAEXAMPLE000000007'
  AND NOT (event_name LIKE 'List%' OR event_name LIKE 'Describe%' OR event_name LIKE 'Get%')
ORDER BY event_time;

cidr_contains and time_bucket stand for your platform's functions; q2_events is the row set selected by Q2 before grouping.

Fixed 10-minute buckets in Q3 can split a burst across two buckets, so they may understate the maximum. Detection DET-CLD-007 uses a sliding 10-minute window. Before turning a Q3 result into a detection threshold, confirm the maximum with a sliding window, or with 5-minute buckets summed in adjacent pairs.

7. Baseline and outlier method

Method (Example):

1. For each key, compute the daily distinct API count over the window (Q4), excluding the day being scored.
2. Compute the key's median and the median absolute deviation (MAD). If MAD is 0, use 1 to avoid division by zero.
3. Score each day with a robust z-score: robust_z = 0.6745 * (x - median) / MAD.
4. Flag days with robust_z of 5 or more (Example: 3.5 is a common starting point in the statistics literature; it is raised here to cut review load on keys with very stable usage), and any day where the key was used from a network owner not seen for that key in the previous 30 days (novelty).
5. Review every flagged day manually (section 9). Record benign causes so the next hunt and the detection can use them.

Worked calculation (Example): key AKIAEXAMPLE000000007 (user svc-reporting) has a median of 6 distinct APIs per day and a MAD of 1. On 2026-09-14 it called 18 distinct APIs. Its score is 0.6745 multiplied by (18 minus 6) divided by 1, which is 0.6745 multiplied by 12, or 8.09. That is above the threshold of 5, and the source network owner (a hosting provider) was new for this key, so the day is flagged on both criteria.

Population results (Example):

For a model-assisted hunt, replace this section with the model description, features, training window, validation method, false positive estimate and the version of the model artefact.

8. Execution log

9. Findings

10. Escalations

Escalation rules:

1. Escalate when activity is likely malicious, even if unconfirmed. Triage belongs to the SOC, under the Incident Response Plan (compliance/incident-response-plan) and the severity levels in the Incident Severity Matrix (ops/incident-severity-matrix).
2. Do not take containment actions yourself, do not contact the suspected actor and do not test the credential.
3. Hand over the evidence: query text, result exports with hashes and the timeline you built.
4. Pause the hunt on that thread; continue other threads only if the incident commander agrees.

11. Outputs

12. Metrics

13. Team, rules of engagement and data handling

Rules of engagement (Example):

• Read-only access to logs and inventories; no changes to production.
• Queries that touch personal data (user names, addresses) are limited to what the hypothesis needs; results are stored in the case system, not on laptops or in chat.
• Monitoring of identifiable employee behaviour follows the privacy notice and legal approval [reference]; this is a documentation format, not legal advice.
• Hunt evidence is retained according to the Incident Response Plan if escalated, otherwise for [Example: 12 months].

14. Glossary and references

Standard and licence note

Structure aligned with common threat hunting practice. The hunt types and the Prepare, Execute, Act phases follow the PEAK threat hunting framework published by Splunk SURGe (April 2023), and section 2 maps them to the Initiate, Hunt and Finalize phases of the TaHiTI methodology published for the Dutch financial sector (2018); both are cited by name only, and no text, figures or templates from them are reproduced. Escalation follows NIST SP 800-61 Rev. 3 (April 2025), a work of the United States Government not subject to copyright in the United States. MITRE ATT&CK technique and tactic names and IDs are used under the ATT&CK terms of use: The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation." MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Splunk, AWS and other product names are trademarks of their owners; this template is not affiliated with or endorsed by them. Check the current official versions at attack.mitre.org and nist.gov before use. Original text written for this collection. Template licence: MIT.