PEAK Framework — Prepare, Execute, Act with Knowledge

PEAK (Prepare, Execute, Act with Knowledge) is Splunk SURGe’s formalization of the threat hunting workflow. It solves the most common hunting failure mode: starting a hunt without clear success criteria, collecting data without a plan, and ending the hunt without producing anything actionable.

Phase 1: Prepare

The Prepare phase has four steps — all must complete before querying begins.

Step 1: Define the Hypothesis

A hunt hypothesis is a falsifiable statement about attacker behavior. Template:

“I believe [attacker behavior] is/was occurring in [scope] because [reason], and if true, I expect to find [evidence].”

Example:

“I believe APT29-affiliated actors may be using WMI event subscriptions (T1546.003) for persistence on our Windows servers, based on the CISA advisory AA24-057A published last week, and if true, I expect to find Sysmon Event 20 (WmiEventConsumerToFilter) or Event 19 (WmiEventFilter) activity from non-administrative processes in the past 30 days.”

This hypothesis is:

Specific: WMI subscriptions, not “malware”
Scoped: Windows servers, 30-day window
Falsifiable: either Event 19/20 exists or it doesn’t
Anchored: tied to real threat intel (CISA advisory)
Evidence-linked: specifies what artifact to search for

Step 2: Identify Required Data Sources

List the telemetry the hunt requires:

Hunt topic	Required data source	Sysmon events / log types
WMI persistence	Sysmon WMI events	Events 19, 20, 21
Lateral movement via SMB	Process creation + network	Event 1 + Event 3
Kerberoasting	Domain controller logs	Windows Event 4769
Cloud IAM persistence	CloudTrail	management events

Step 3: Verify Data Availability

Before hunting, confirm the data actually exists:

# Verify Sysmon WMI events are present
index=sysmon EventCode IN (19, 20, 21)
  earliest="-30d"
| stats count by EventCode, host

If this returns zero results: Sysmon WMI logging isn’t enabled in the config. The hunt can’t proceed until the data gap is remediated. Document this as a telemetry gap finding — it’s a valuable output even before the hunt begins.

Step 4: Establish Baseline

Before looking for anomalies, know what normal looks like:

# Baseline: WMI event subscription activity in the past 90 days
index=sysmon EventCode IN (19, 20, 21)
  earliest="-90d" latest="-30d"
| stats count by host, User, EventCode
| sort -count

This tells you: which hosts typically generate WMI subscription events, who creates them, and at what frequency. Anything outside this baseline during the hunt window is a candidate for investigation.

Phase 2: Execute

The Execute phase is the actual hunting: querying, collecting candidates, triaging.

The Query Progression

Don’t start with the most specific query — start broad and narrow:

# Step 1: Broad — all WMI subscription events
index=sysmon EventCode IN (19, 20, 21) earliest="-30d"
| stats count by host, EventCode

# Step 2: Narrow — unexpected hosts or users
index=sysmon EventCode IN (19, 20, 21) earliest="-30d"
| stats count by host, User, EventCode
| where NOT User IN ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE")

# Step 3: Deep — inspect the subscription details
index=sysmon EventCode=20 earliest="-30d"
  NOT User IN ("SYSTEM", "LOCAL SERVICE")
| table _time, host, User, Name, Type, Destination

Candidate Triage

For each suspicious event, classify:

Classification	Criteria	Action
Confirmed benign	Known process, documented use case	Add to baseline documentation
Suspicious	Unusual but not confirmed malicious	Escalate for investigation
Confirmed malicious	Clear attack behavior, IOC match	Trigger incident response

Build a triage log as you work:

## Hunt Triage Log — WMI Persistence Hunt 2026-05-20

| Time | Host | User | Subscription Name | Classification | Evidence |
|------|------|------|------------------|----------------|----------|
| 2026-05-18 02:14 | ws-dev-04 | jdoe | WindowsUpdate | Suspicious | Created at 2am by non-admin user; subscription calls powershell.exe |
| 2026-05-15 11:30 | dc01 | svc-backup | BackupMonitor | Benign | Documented backup monitoring subscription; verified with IT |

Phase 3: Act with Knowledge

Every hunt ends with four outputs, regardless of whether an attacker was found:

Output 1: Finding Report

## Hunt Finding: WMI Subscription Activity — ws-dev-04

**Classification:** Suspicious — escalated to investigation
**Time:** 2026-05-18 02:14 UTC
**Host:** ws-dev-04 (Tier 2 workstation, owner: jdoe)
**User:** CORP\jdoe
**Subscription:** Name=WindowsUpdate, Destination=powershell.exe -enc SGVsbG8=

**Evidence:**
- Sysmon Event 20 at 02:14 (WMI event consumer created)
- Subscription executes encoded PowerShell at midnight daily
- Created by a non-admin user account (jdoe is Finance staff)
- No legitimate business reason for this subscription identified

**Next action:** IR escalated — host isolated, jdoe account suspended

Output 2: Detection Rule

title: Suspicious WMI Event Subscription — Non-System Account
logsource:
  product: windows
  category: wmi_event
detection:
  selection:
    EventID: 20   # WmiEventConsumer
  filter_system:
    User|contains:
      - 'SYSTEM'
      - 'LOCAL SERVICE'
      - 'NETWORK SERVICE'
  condition: selection and not filter_system
level: high
tags:
  - attack.persistence
  - attack.t1546.003

Output 3: Baseline Update

Document what normal looks like now that the hunt is complete:

## WMI Subscription Baseline — Updated 2026-05-20

Normal WMI event subscription activity:
- BackupMonitor: svc-backup account on DC/servers (daily, documented)
- WindowsUpdate: SYSTEM account only (automated, verified)
- Anomaly threshold: any WMI subscription by non-service-account users = investigate

Output 4: Hunt Library Entry

Add the hunt to the team’s hunt library so it can be repeated:

## Hunt: WMI Event Subscription Persistence (T1546.003)
**Author:** hunt-team
**Last run:** 2026-05-20
**Frequency:** Monthly
**Hypothesis:** Attackers use WMI subscriptions for persistence on Windows hosts
**Key queries:** [link to query library]
**Known FP:** BackupMonitor subscription from svc-backup
**Finding this run:** 1 suspicious (escalated to IR)

PEAK Threat Hunting Framework— Splunk SURGe

Retrieval Practice

You run a PEAK hunt for Kerberoasting (T1558.003). In the Prepare phase, you query for Kerberos TGS requests (Event 4769, EncryptionType=0x17) and get zero results. Before concluding 'no Kerberoasting,' what must you verify?

Reveal answer

Verify data availability first: (1) Are Windows Security Event 4769 events flowing from domain controllers to your SIEM? Query for any 4769 events in the time window — if zero 4769s exist at all (not just filtered ones), the data source is absent or misconfigured. DCs may not be shipping Security events, or the log channel isn't configured in Winlogbeat/NXLog. (2) Is Kerberos Service Ticket auditing enabled? Advanced Audit Policy → Account Logon → Audit Kerberos Service Ticket Operations must be Enabled. Without this policy, 4769 events are never generated regardless of activity. Zero results on a filtered query (EncryptionType=0x17) is only meaningful if zero-filtered means 'no Kerberoasting,' not 'no 4769 data at all.'

Retrieval Practice

Your PEAK hunt for lateral movement via PsExec finds 47 candidate events. 43 are from IT admins using PsExec for legitimate remote management, 3 are from service accounts for automated deployment, and 1 is from a user account (jdoe) that has never used PsExec before. How do you triage these, and what outputs does each category produce?

Reveal answer

43 IT admin events: Confirmed benign — cross-reference with baseline (IT admins regularly use PsExec). Document as baseline pattern. No further action. 3 service account events: Confirmed benign — verify against deployment system documentation. Add to baseline if expected. 1 jdoe event: Suspicious — jdoe is a Finance user with no documented reason to use PsExec. Pivot: when was it? What destination? What did jdoe's account do before/after? If investigation confirms attack: IR escalation. If confirmed benign (jdoe was moved to IT temp): update baseline. Outputs: (1) Finding report for jdoe event (suspicious or confirmed malicious). (2) Sigma rule for PsExec usage by non-IT-admin users. (3) Baseline documentation: PsExec usage expected from IT-Admin group only, service accounts deployer-svc-* only. (4) Hunt library entry with the triage criteria for future monthly runs.