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

<!--
Guidance: How to use this template
- Use one document per hunt. Fill sections 1 to 7 before touching data
  (the plan), then sections 8 to 12 as you execute and close (the
  report). Keep both halves in one file so reviewers can compare what
  you planned with what you did.
- A hunt assumes the attacker is already present and undetected. Its
  value is in what it proves or rules out and in what it leaves behind:
  new detections, closed data gaps, better baselines.
- Timebox every hunt. An open-ended hunt rarely ends with a decision.
- Escalate the moment you find likely malicious activity. Hunting stops
  and incident response starts (section 10).
- Do not copy queries from vendor blogs or community repositories
  without checking their licence; write and test your own.
-->

## Document control

<!-- Guidance: The hunt ID links the plan, the queries in version control, any incident it opened and any detection it created. -->

| Field | Value |
|---|---|
| Document ID | [HUNT-2026-014] |
| Hunt title | [*Example:* Enumeration with leaked long-term cloud access keys] |
| Version | [1.0] |
| Status | [Planned / In progress / Closed / Cancelled] |
| Hunt type | [Hypothesis-driven / Baseline / Model-assisted] (section 2) |
| Owner (lead hunter) | [@threat-hunter] |
| Approvers / reviewers | [@soc-lead], [@threat-intel-lead], [@data-owner] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential (may contain indicators and findings) |
| Timebox | [*Example:* 2026-09-08 to 2026-09-19, 6 analyst-days] |
| Data window | [*Example:* 2026-08-15 to 2026-09-15 (30 days plus overlap)] |
| ATT&CK version mapped | Enterprise [v20] |
| Related records | [*Example:* INC-2026-0412, DET-CLD-007, PB-CLD-002] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| SOC lead (plan approval) | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Data owner (access to logs) | [@name] | [Decision] | YYYY-MM-DD |
| SOC lead (report acceptance) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Plan drafted from intelligence item CTI-2026-088 |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Plan approved; data check Q1 complete |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Report completed; hunt closed with one escalation and one new detection |

## Contents

1. [Hunt summary](#1-hunt-summary)
2. [Hunt type and method](#2-hunt-type-and-method)
3. [Trigger and hypothesis](#3-trigger-and-hypothesis)
4. [ATT&CK techniques in scope](#4-attck-techniques-in-scope)
5. [Scope, data sources and coverage gaps](#5-scope-data-sources-and-coverage-gaps)
6. [Queries](#6-queries)
7. [Baseline and outlier method](#7-baseline-and-outlier-method)
8. [Execution log](#8-execution-log)
9. [Findings](#9-findings)
10. [Escalations](#10-escalations)
11. [Outputs](#11-outputs)
12. [Metrics](#12-metrics)
13. [Team, rules of engagement and data handling](#13-team-rules-of-engagement-and-data-handling)
14. [Glossary and references](#14-glossary-and-references)
15. [Standard and licence note](#standard-and-licence-note)

## 1. Hunt summary

<!-- Guidance: Write this last. A reader should learn the question, the answer and what changed in under a minute. -->

| Item | Value |
|---|---|
| Question | *Example:* Is anyone using a Corvid Commerce long-term access key from outside our networks to enumerate our AWS accounts? |
| Answer | *Example:* Yes, once. One reporting service key was used from a hosting provider address on 2026-09-14; escalated as INC-2026-0412. No other misuse found in 30 days of data for 38 of 40 accounts. |
| Hypothesis outcome | [Supported / Not supported / Inconclusive] *Example:* Supported |
| Confidence | [High / Medium / Low] *Example:* Medium, because two accounts had incomplete data (GAP-01) |
| Key outputs | *Example:* 1 incident, 1 new detection (DET-CLD-007), 2 data gaps raised, 1 baseline published, 3 keys removed |
| Effort | *Example:* 5.5 analyst-days of the 6 planned |

## 2. Hunt type and method

<!-- Guidance: Pick the type that matches what you know. Questions: do you have a specific adversary behaviour to test, or are you learning what normal looks like, or do you have a model to apply? Pitfall: calling an alert review a hunt. -->

| Hunt type | Use when | Starting point | Typical output |
|---|---|---|---|
| Hypothesis-driven | You can state a specific, testable adversary behaviour in your environment | Intelligence, red team result, incident lesson, threat model | Proof or disproof of the hypothesis, detections |
| Baseline (exploratory data analysis) | You do not yet know what normal looks like for a data source or population | A data source and a population (keys, hosts, users) | A documented baseline, outliers to review, hypotheses for later hunts |
| Model-assisted | Behaviour is too varied for rules, and you can train or apply a statistical or machine learning model | Labelled or unlabelled data, a model and its validation method | Scored outliers, a reusable model, detections that call the model |

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:

```mermaid
flowchart LR
  P["Prepare: trigger, hypothesis, data check, plan approval"] --> E["Execute: queries, baseline, analysis, findings"]
  E --> X{"Likely malicious activity?"}
  X -- "Yes" --> IR["Escalate to incident response (section 10)"]
  X -- "No" --> A["Act: detections, data gaps, baselines, report"]
  IR --> A
  A --> K["Knowledge: hunt library, metrics, next hypotheses"]
```

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

<!-- Guidance: Record why this hunt now, and write the hypothesis so that data can support or refute it. A good hypothesis names the actor behaviour, the asset, the observable and the time frame. -->

### 3.1 Intelligence trigger

| Trigger ID | Source | Summary | Relevance to us |
|---|---|---|---|
| CTI-2026-088 *(Example)* | Public threat reports and provider security bulletins | Automated campaigns harvest cloud keys from public code and use them within hours to enumerate and launch compute | We have 120 long-term keys and use public repositories for open source work |
| INT-2026-031 *(Example)* | Internal secret scanning | Two historical commits with key patterns found in an old public repository | Keys may have been exposed for months |
| TM-2026-007 *(Example)* | Threat Model (`security/threat-model`) | Threat "stolen workload credential used from outside" rated high, no detection mapped | Detection gap confirmed |

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

<!-- Guidance: List only techniques the hunt can observe with the data in section 5. Verify IDs and names at attack.mitre.org for the version in Document control. -->

| Tactic | Technique (ATT&CK Enterprise v20) | Observable in this hunt |
|---|---|---|
| Initial Access, Persistence, Privilege Escalation, Stealth | T1078.004 Valid Accounts: Cloud Accounts | Key used from unexpected networks |
| Credential Access | T1552.001 Unsecured Credentials: Credentials In Files | Exposure source (secret scanning history) |
| Discovery | T1087.004 Account Discovery: Cloud Account | Identity listing calls |
| Discovery | T1580 Cloud Infrastructure Discovery | Compute, network and snapshot description calls |
| Discovery | T1619 Cloud Storage Object Discovery | Bucket and object listing calls |
| Discovery | T1526 Cloud Service Discovery | Calls across many services |
| Persistence, Privilege Escalation | T1098.001 Account Manipulation: Additional Cloud Credentials | Follow-on key creation (pivot query Q5) |

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

<!-- Guidance: Check the data before you hunt. A hunt over incomplete data must say so in its confidence rating. Pitfall: concluding "no evidence of compromise" when the relevant log was not collected. -->

### 5.1 Scope

| In scope *(Example)* | Out of scope *(Example)* |
|---|---|
| 40 AWS accounts in the Corvid Commerce organisation | Azure and Google Cloud estates (separate hunt HUNT-2026-015) |
| Long-term IAM user access keys | Temporary role sessions (covered by a later hunt) |
| Management events, all regions | Data events except for 6 sensitive buckets |

### 5.2 Data sources

| Source | Fields needed | Window available | Quality check (Q1) |
|---|---|---|---|
| CloudTrail organisation trail in the SIEM | Event time, event name, event source, identity type, access key ID, source address, user agent, account | 13 months | *Example:* Complete for 38 of 40 accounts |
| IAM credential inventory | Key ID, user, created date, last used | Current snapshot plus daily history | Complete |
| Known network register | Owned and partner ranges | Current version | Updated 2026-09-01 |
| Network owner enrichment (IP to autonomous system) | Owner name, type (hosting, residential, corporate) | Lookup at query time | Enrichment for 99% of addresses |
| Secret scanning history | Repository, commit, detection date | Since enablement | Complete |

### 5.3 Coverage gaps

| Gap ID | Gap | Effect on the hunt | Action | Owner |
|---|---|---|---|---|
| GAP-01 *(Example)* | Account `corvid-legacy-analytics` delivers CloudTrail to the SIEM with up to 6 hours delay and missed 3 days in August | Hunt confidence lowered to Medium | Move the account into the organisation trail; also listed in the Cloud Security Posture Review (`security/cloud-security-posture-review`) | [@cloud-platform-lead] |
| GAP-02 *(Example)* | Sandbox account has no trail in two unused regions | Activity there is invisible | Enable organisation trail for all regions; deny unused regions by policy | [@cloud-platform-lead] |

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

## 6. Queries

<!-- Guidance: Keep every query in version control under the hunt ID and paste the final version here. Write them in your SIEM language; the examples use generic SQL over a table named cloudtrail. State what each query answers. -->

| Query ID | Question it answers |
|---|---|
| Q1 | Is the data complete per account and day, and is the key ID populated? |
| Q2 | Which long-term keys made read-only calls from unlisted networks? |
| Q3 | For those keys, what is the highest number of distinct API names in any 10-minute window? |
| Q4 | What is each key's normal daily number of distinct API names (baseline)? |
| Q5 | Pivot: what else did a suspicious key do (writes, key creation, logging changes)? |

```sql
-- 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

<!-- Guidance: Describe how you decide what is unusual, and make the method repeatable. Prefer robust statistics (median and median absolute deviation) over mean and standard deviation, because attack activity itself distorts the mean. State the threshold and why. -->

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)*:

| Measure | Value |
|---|---|
| Long-term keys in inventory | 120 |
| Keys with at least one call in the window | 87 |
| Keys with read-only calls from unlisted networks (Q2) | 23 |
| Highest distinct API count in any 10-minute window from unlisted networks, keys with no finding (21 of 23) (Q3) | 9 |
| Same measure for the two keys with findings (Q3) | 18 (F-01), 12 (F-02) |
| Key-days flagged by robust z-score or novelty | 7 |
| Flagged key-days reviewed | 7 |

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

<!-- Guidance: A short dated log of what you ran and decided. It lets a reviewer reproduce the hunt and shows where time went. -->

| Date | Activity | Result | Hunter |
|---|---|---|---|
| 2026-09-08 *(Example)* | Plan approved; Q1 data check | GAP-01 and GAP-02 found; confidence capped at Medium | [@threat-hunter] |
| 2026-09-09 *(Example)* | Q2 and Q3 over 30 days | 23 keys; distribution published | [@threat-hunter] |
| 2026-09-10 *(Example)* | Q4 baseline and scoring | 6 key-days flagged | [@threat-hunter] |
| 2026-09-11 *(Example)* | Review of the 6 flagged key-days | All benign: 4 from the backup tool egress change (F-02), 2 from the data team job (F-03) | [@threat-hunter] |
| 2026-09-15 *(Example)* | Scheduled re-run with new data; F-01 flagged on 2026-09-14 data (7th flagged key-day); Q5 pivot | Escalated to SOC at 10:42 | [@threat-hunter] |
| 2026-09-16 to 2026-09-19 *(Example)* | Detection drafted and tested; report written | DET-CLD-007 in Test | [@detection-engineer] |

## 9. Findings

<!-- Guidance: One row per finding, including benign ones. Benign findings are valuable: they become filters, baselines and documentation. Classify each finding and state the evidence. -->

| Finding ID | Summary | Classification | Evidence | Action |
|---|---|---|---|---|
| F-01 *(Example)* | Key of `svc-reporting` called 18 distinct read-only APIs in 6 minutes from `192.0.2.44` (hosting provider) on 2026-09-14; Q5 showed no write calls | Likely malicious | Q3, Q4 score 8.09, Q5 output, novelty of network owner | Escalated (ESC-01) |
| F-02 *(Example)* | Backup tool key reached 12 distinct APIs in 10 minutes from a new egress range after a vendor change | Benign, authorised | Change ticket for the backup tool | Range added to the network register; migration to workload identity requested |
| F-03 *(Example)* | Data team scheduled job started using a long-term key from a contractor network | Benign but policy violation | Team confirmation | Exception recorded; key replaced by role access within 30 days |
| F-04 *(Example)* | 3 long-term keys unused for more than 180 days | Hygiene | IAM inventory | Keys deactivated, then deleted after 30 days |
| F-05 *(Example)* | Key patterns found in an old public repository belonged to keys already deleted in 2024 | Benign (no live credential) | Secret scanning history and IAM history | Repository archived; no further action |

## 10. Escalations

<!-- Guidance: Stop hunting the moment activity looks malicious and hand over to the SOC using the playbook. Record the hand-off time; the incident response plan's clocks may start from it. -->

| Escalation ID | Finding | Escalated to | Time | Playbook | Incident | Outcome |
|---|---|---|---|---|---|---|
| ESC-01 *(Example)* | F-01 | SOC shift lead | 2026-09-15 10:42 | PB-CLD-002, SOC Playbook (`security/soc-playbook`) | INC-2026-0412 | *Example:* SEV2 (unknown party, no privileged or data access); DP-1 applied, key deactivated 54 minutes after escalation and sessions issued before containment blocked; no data access found; exposure traced to a build log |

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

<!-- Guidance: The lasting value of a hunt is what it leaves behind. List every output with an owner and a link, and check that each one actually ships. -->

| Output ID | Type | Description | Owner | Status |
|---|---|---|---|---|
| OUT-01 *(Example)* | Detection | DET-CLD-007, discovery burst by long-term key from unlisted network, specified in Detection Rule Specification (`security/detection-rule-spec`) | [@detection-engineer] | In Test since 2026-09-20 |
| OUT-02 *(Example)* | Data gap | GAP-01 and GAP-02 raised against the logging standard | [@cloud-platform-lead] | Open |
| OUT-03 *(Example)* | Baseline | Daily distinct API baseline per key, refreshed monthly | [@threat-hunter] | Published |
| OUT-04 *(Example)* | Hygiene | 3 stale keys removed (F-04) | [@iam-lead] | Done |
| OUT-05 *(Example)* | Intelligence | Indicator `192.0.2.44` and behaviour summary shared with the threat intelligence team (TLP:AMBER) | [@threat-intel-lead] | Done |
| OUT-06 *(Example)* | Next hypothesis | Same behaviour with temporary role sessions (HUNT-2026-016) | [@threat-hunter] | Planned |
| OUT-07 *(Example)* | Playbook change | Hunt escalation path added to PB-CLD-002 triggers (TRG-07) | [@soc-lead] | Done |

## 12. Metrics

<!-- Guidance: Measure the hunting programme, not individual hunters. A hunt that finds nothing but closes two data gaps and ships a detection is a successful hunt. Example targets are not normative. -->

| Metric | Formula | This hunt *(Example)* | Programme target *(Example)* |
|---|---|---|---|
| Hunts completed per quarter | Hunts closed in the quarter | 1 of 4 in Q3 | 4 |
| Detections created | Detections reaching Test from hunts | 1 | At least 1 per 2 hunts |
| Escalation rate | Hunts with at least one escalation divided by hunts closed | 1 of 1 | No target (informational) |
| Data gaps found and closed | Gaps closed within 90 days divided by gaps found | 0 of 2 so far | 80% |
| Technique coverage added | ATT&CK techniques with a new Stable detection after the hunt | 4 (T1087.004, T1580, T1619, T1526) once DET-CLD-007 is Stable | Tracked in the coverage map |
| Effort accuracy | Actual analyst-days divided by planned analyst-days | 5.5 / 6 = 0.92 | 0.8 to 1.2 |
| Hunt dwell-time contribution | Escalation time minus earliest malicious event time | 2026-09-15 10:42 minus 2026-09-14 02:11, about 32.5 hours | Trend down |

## 13. Team, rules of engagement and data handling

<!-- Guidance: Agree these before the hunt starts, especially when hunting touches personal data or employee activity. Pitfall: hunting through employee communications without legal approval. -->

| Role | Name | Responsibility |
|---|---|---|
| Lead hunter | [@threat-hunter] | Plan, execution, report |
| Threat intelligence analyst | [@threat-intel-analyst] | Trigger, context, sharing of outputs |
| Data owner | [@cloud-platform-lead] | Log access, explanation of normal behaviour |
| Detection engineer | [@detection-engineer] | Turning findings into detections |
| SOC lead | [@soc-lead] | Approves the plan, receives escalations, accepts the report |

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

<!-- Guidance: Define terms for readers outside the hunting team. -->

| Term | Meaning |
|---|---|
| Threat hunt | A proactive, human-led search for adversary activity that existing detections missed |
| Hypothesis | A testable statement about adversary behaviour in this environment |
| Baseline | A documented description of normal behaviour for a population and data source |
| Robust z-score | Distance from the median measured in median absolute deviations, scaled by 0.6745 |
| Median absolute deviation (MAD) | The median of the absolute differences between each value and the median |
| Coverage gap | Missing or unreliable data that prevents a technique from being observed |
| Escalation | Hand-off of a likely malicious finding to the SOC for incident response |

| Reference | Use |
|---|---|
| MITRE ATT&CK Enterprise v20, 13 October 2026, attack.mitre.org | Techniques (section 4) |
| D. Bianco, *Introducing the PEAK Threat Hunting Framework*, Splunk SURGe blog, 18 April 2023, splunk.com | Hunt types (hypothesis-driven, baseline, model-assisted) and phases Prepare, Execute, Act with Knowledge; cited only |
| *TaHiTI: Threat Hunting Methodology*, Dutch Payments Association (Betaalvereniging Nederland) and Dutch financial sector, 2018, betaalvereniging.nl | Phases Initiate, Hunt and Finalize, mapped in section 2; cited only |
| NIST SP 800-61 Rev. 3, April 2025, csrc.nist.gov/pubs/sp/800/61/r3/final | Escalation into incident response |
| SOC Playbook (`security/soc-playbook`) | Response to escalated findings |
| Detection Rule Specification (`security/detection-rule-spec`) | Detections created from hunts |
| Security Logging Standard (`security/security-logging-standard`) | Data sources and gap tracking |
| Threat Model (`security/threat-model`) and Attack Tree (`security/attack-tree`) | Sources of hypotheses |
| Cloud Security Posture Review (`security/cloud-security-posture-review`) | Account onboarding gaps |
| Incident Response Plan (`compliance/incident-response-plan`) | Escalation authority and evidence retention |

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