Threat Hunting Guide

Automated detection only finds what someone has already written a rule for, so attackers who use valid accounts, stolen tokens and built-in tools can sit inside an environment for weeks without raising an alert. Threat hunting is the structured, human-led search for that activity. This guide covers the main hunt types, the PEAK and TaHiTI processes, the data a hunt needs, how to hunt with MITRE ATT&CK v20, baselining and stack counting, hunting for identity abuse, turning hunts into detections, maturity, team models and metrics. It is written for SOC leads, detection engineers and security managers building or improving a hunting programme. It does not repeat the basics of SIEM operations or rule writing; those are linked where they matter.

Key takeaways

• Hunting is a process, not a tool. PEAK (Prepare, Execute, Act with Knowledge) and TaHiTI (Initiate, Hunt, Finalize) both give a repeatable loop with a backlog, documentation and handover.
• Every hunt needs a testable question. A hypothesis names the behaviour, the data that would show it and what "proven", "disproven" or "inconclusive" looks like.
• Data readiness decides what you can hunt. Identity provider sign-ins (including non-interactive and service principal sign-ins), endpoint process telemetry, DNS and proxy logs and cloud control plane logs cover most hunts, with 30 to 90 days of history.
• A hunt that finds nothing can still succeed. If you proved you would have seen the activity, the output is a new detection, a documented baseline or a closed data gap.
• Identity abuse is the richest hunting ground. Service accounts logging on interactively, OAuth apps with mail or file scopes and tokens replayed from new infrastructure rarely trip signature-based rules.

What threat hunting is, and what it is not

SURGe by Splunk, in the PEAK framework, defines hunting as "any manual or machine-assisted process intended to find security incidents" that automated detection has missed. The TaHiTI methodology from the Dutch financial sector calls it "the proactive effort of searching for signs of malicious activity in the IT infrastructure". NIST SP 800-53 Rev. 5 makes it a control: RA-10 Threat Hunting requires a capability to search for indicators of compromise and to "detect, track, and disrupt threats that evade existing controls", run at an organisation-defined frequency.

• Not alert triage: a hunt starts from a question, report or baseline, and assumes the alert never fired.
• Not incident response: likely malicious findings are escalated to incident response. See the Incident Response Guide.
• Not an IOC sweep alone: searching history for hashes and IPs from a report is the entry level (HMM1). Mature hunting targets behaviours, which attackers change less easily.
• Not detection engineering: hunting explores; detection engineering productionises what hunting proves. See the Detection Engineering Guide.

Hunt types and when to use each

PEAK names three hunt types; TaHiTI adds a split between structured (hypothesis-based) and unstructured (data-driven) hunting and describes itself as essentially intelligence-driven. In practice most programmes use all of them.

Decision guidance: start with intelligence-driven and hypothesis-driven hunts on identity and endpoint data; they produce results quickly and teach the team the data. Add baseline hunts for high-value sources, and model-assisted hunting only once the basics run reliably.

The hunting loop: PEAK and TaHiTI

PEAK, published by David Bianco at SURGe in 2023, builds on the Sqrrl Threat Hunting Reference Model (2015) and TaHiTI (2018). TaHiTI ("Targeted Hunting integrating Threat Intelligence") was produced by a focus group of Dutch financial institutions under FI-ISAC and is free to use under a Creative Commons licence.

Writing a hypothesis that can be tested

• Behaviour: one technique, with its ATT&CK ID, in your environment's terms. "Attackers use stolen OAuth tokens" is a topic; "a refresh token issued to a user in the UK is being redeemed from a VPS provider ASN for Exchange Online" is a hypothesis.
• Evidence: the log fields that would show it, checked as populated before you start.
• Scope: the population and time window.
• Outcome rule: what counts as proven, disproven or inconclusive. Inconclusive usually means a data gap, which is itself a deliverable.

The backlog: TaHiTI keeps abstracts on a risk-prioritised backlog (SharePoint or Jira is enough). Review it when priorities change, and add every out-of-scope lead raised during a hunt.

Data requirements

PEAK's baseline method suggests a historical window of 30 to 90 days, and Microsoft warns that Entra sign-in and audit data can be overwritten after 30 or 90 days unless exported, so retention in a SIEM or data lake is a prerequisite. See the Log Management and Retention Guide and the SIEM Guide.

• Normalise first: four spellings of "username" break joins. Build a data dictionary per source, as PEAK's baseline method requires.
• Track the gaps: each missing, sampled or misparsed source found during a hunt goes to the log owner as a tracked item.

Hunting with MITRE ATT&CK

ATT&CK gives hunters a shared vocabulary, and technique pages now carry detection strategies (DET IDs) made up of analytics (AN IDs). Use them as a starting list of observable behaviours, then adapt them to your data. The IDs below were checked on attack.mitre.org against ATT&CK v20.

Map each hunt to the techniques it tested, but a coloured matrix is not coverage: a technique counts only when a hunt showed the data would reveal it and a detection or scheduled report now watches for it. Microsoft Sentinel, for example, tags hunting queries and bookmarks by tactic and technique.

Baselining, stacking and long tail analysis

Baseline hunts define normal, then examine the exceptions. In PEAK's baseline method the hunter scopes groups of similar systems over 30 to 90 days, creates a data dictionary, reviews distributions, investigates outliers, notes data gaps and relationships between fields, then documents the baseline with a list of known-benign outliers and creates detections.

• Stack counting (least frequency of occurrence): count each value of a field across many hosts or identities and review the rarest. Bianco's maturity model notes that most procedures at HMM2 use least-frequency analysis, which is why they need data from many hosts.
• Good stacking candidates: autorun entries and services, scheduled tasks, parent and child process pairs, signed binaries running from user-writable paths, service principal user agents, OAuth app IDs per user, and countries or ASNs per service account.
• Group before you stack: stacking domain controllers with laptops hides everything. Compare like with like, as PEAK's scoping step requires.
• Beyond counts: z-scores for volume outliers (for example, mailbox items accessed per hour) and relationships between fields (logons by hour of day per account).
• Keep the known-benign list: it stops the next hunter re-investigating the same backup agent and seeds suppression lists for any detection built from the baseline.

Infrastructure hunting applies the same pivoting outwards: from one malicious domain or IP in a report, analysts pivot on registration details, hosting and certificates to find related infrastructure, then search internal DNS and proxy logs for it. See the Threat Intelligence Guide.

Where identity fits

Attackers who log in rather than break in rarely trip signature rules, and non-human identities have no user to notice odd activity. See the ITDR Guide.

• Service accounts behaving like people: stack logon types per service account. Interactive (type 2) or remote interactive (type 10) logons by an account that should only show service (type 5) or network (type 3) logons are high-value leads. See the Service Account Security Guide.
• Service principals from new places: baseline each service principal's source IPs, ASNs, user agents and target resources. Microsoft's "Suspicious Sign-ins" workload identity detection needs 2 to 60 days to learn this, and its workload identity detections do not cover managed identities, so a written baseline still matters.
• New credentials on apps (T1098.001): list every secret or certificate added to an application or service principal in 90 days and check who added it and from where.
• OAuth consent: search audit logs for "Consent to application", especially tenant-wide (AllPrincipals) grants and scopes such as Mail.*, Files.* and MailboxSettings.*. In the Microsoft Midnight Blizzard breach, attackers used a forgotten test tenant and an OAuth application to reach executive mailboxes. See the SaaS and OAuth App Governance Guide.
• Token replay: compare IPs and ASNs in non-interactive sign-ins with those in the same user's interactive sign-ins; refresh token redemption from infrastructure never used for an interactive sign-in deserves a look. Microsoft Entra ID Protection's "Anomalous token" detection covers session and refresh tokens with unusual characteristics. In the Salesloft Drift breach, OAuth tokens stolen from one integration opened hundreds of Salesforce tenants, activity that interactive sign-in monitoring alone would not show. See the Token and Session Security Guide.
• Mailbox persistence: inbox rules that forward externally or hide messages, created soon after a risky sign-in.

Documenting hunts and converting them to detections

PEAK lists the deliverables of a hunt: escalated incidents, hunt documentation, new and improved detections, gaps and risks (such as a missing event type or disabled MFA), new hunt ideas for the backlog, and stakeholder reports. Its documentation test is simple: "Someone other than you should be able to recreate your results."

A hunt record should hold: ID and title, trigger, hypothesis, ATT&CK IDs, data sources and time range, queries (in version control), findings with evidence, outcome (proven, disproven, inconclusive), escalations, detections created, gaps raised, follow-up hunts and hours spent.

PEAK's advice is to "choose the highest level that you can feasibly implement" and revisit reports and dashboards later. TaHiTI adds the handover routes: incidents to incident response, use cases to security monitoring, new TTPs to threat intelligence, weaknesses to vulnerability management. Automated enrichment of promoted detections is covered in the SOAR and Security Automation Guide.

Hunt maturity, team models and cadence

David Bianco's Hunting Maturity Model (2015), often called the Sqrrl HMM, is still the common reference.

Cadence: Microsoft recommends running Sentinel hunting queries at least once a week. Time-box each hypothesis hunt (two to five analyst days is a workable default) and agree a fixed number of hunts per quarter rather than "when time allows", which in a busy SOC means never.

Implementing a hunting programme

1. Confirm data readiness (weeks 1 to 4): check identity, endpoint, DNS or proxy, and cloud audit logs are centralised with at least 90 days of searchable history. Fix parsing of key fields first.
2. Set up the backlog and template: a ticket project with the abstract and hunt record fields above, plus a query repository under version control.
3. Seed the backlog: three to five abstracts each from intelligence, recent incidents and red team findings, ranked by risk.
4. Run a pilot quarter: one hunt at a time, each reproduced by a peer.
5. Test detections before they alert: run every new rule as a scheduled report or in audit mode for two to four weeks, measure benign hits, then promote it.
6. Roll back cleanly: keep rules in version control so a noisy detection can be disabled or reverted in one logged change.
7. Scale: add baseline hunts for high-value data sources, then documented, repeatable hunt playbooks (HMM2 to HMM3), then automation of proven hunts (HMM4).

Metrics that show hunting is working

TaHiTI's metrics focus on outcomes, not activity. Do not score hunters on incidents found: in a well-defended environment most hunts find nothing malicious.

• Detections created or improved per quarter: the clearest proof of lasting value.
• Data gaps found and closed: count raised, and the median days to fix.
• Incidents originating from hunts: and the dwell time of each finding (time from first malicious activity to discovery).
• ATT&CK techniques validated: techniques where a hunt proved visibility and a detection or report now runs.
• Backlog health: hunts completed against plan, and age of the oldest high-priority abstract.
• Vulnerabilities and misconfigurations reported: such as service accounts with interactive rights or apps with unused high-risk scopes.

Framework mapping

Common failure patterns

• Hunting without the data: hypotheses about token replay with no non-interactive or service principal sign-ins ingested, so hunts end "inconclusive" and nobody raises the gap.
• IOC sweeps called hunting: searching last month's hashes stays at HMM1 and misses attackers who rotate infrastructure.
• Findings that never become detections: the same manual hunt is rerun every quarter because nobody owns the handover to detection engineering.
• Ignoring non-human identities: hunts focus on user accounts, while OAuth apps and service principals with mail or file scopes go unreviewed, the pattern behind the Midnight Blizzard breach.
• No documentation: results live in one analyst's notebook and leave with them.

Practitioner checklist

• Confirm 90 days of searchable identity, endpoint, DNS or proxy and cloud audit logs, including non-interactive and service principal sign-ins.
• Adopt one process (PEAK or TaHiTI) and a standard hunt record template.
• Keep a risk-ranked backlog fed by intelligence, incidents, red team results and earlier hunts.
• Write every hypothesis with behaviour, evidence, scope and an outcome rule.
• Store hunting queries in version control with ATT&CK v20 technique IDs.
• Baseline service account logon types, service principal source IPs and OAuth consent grants.
• Promote each successful hunt to the highest feasible detection output, after a test period.
• Report detections created, gaps closed and techniques validated, not hours spent.

Standards and references

• Splunk SURGe: Introducing the PEAK Threat Hunting Framework
• Splunk SURGe: PEAK Baseline Hunting
• Splunk SURGe: Turning Hunts Into Detections with PEAK
• FI-ISAC NL: TaHiTI Threat Hunting Methodology
• David J. Bianco: A Simple Hunting Maturity Model
• MITRE ATT&CK: T1550.001 Application Access Token
• Microsoft Learn: Securing workload identities with ID Protection
• Microsoft Learn: Threat hunting in Microsoft Sentinel

Related NHI Mgmt Group resources: Detection Engineering Guide · SIEM Guide · Threat Intelligence Guide · ITDR Guide · Log Management and Retention Guide