The PEAK Act Phase — Turning Every Finding into Lasting Value

The hunt is not done when the finding is confirmed. It’s done when the organization is better defended than it was before the hunt — and that requires all three outputs of the Act phase to be produced and delivered.

The PEAK Act Phase Framework

Confirmed Hunt Finding
        │
        ├─────────────────────────────► (1) IR Ticket
        │                                   If: active adversary confirmed
        │                                   Contents: scope, IOCs, ATT&CK chain, 
        │                                   containment recommendation
        │                                   Timeframe: IMMEDIATE
        │
        ├─────────────────────────────► (2) Detection Rule  
        │                                   If: behavioral pattern is stable + log source reliable
        │                                   Process: ABLE gate → Sigma rule → PR to detection repo
        │                                   Timeframe: within sprint (1-2 weeks)
        │
        └─────────────────────────────► (3) CTI Deliverable
                                            If: novel actor, TTP, or technique
                                            Contents: hunt report + IOC pack + ATT&CK layer
                                            Timeframe: within 2 weeks of hunt close

Output 1: IR Ticket (Time-Critical)

When to produce: any confirmed C2 channel, confirmed data access, confirmed lateral movement — attacker is active.

The IR ticket is the most time-sensitive output. An active adversary needs to be contained before they detect the hunt and destroy evidence or accelerate operations.

Key sections (from M22 hunt-to-IR-ticket):

Affected host(s) + owner + business function
Finding summary + confidence level
Evidence chain (every pivot step with artifact reference)
IOCs (C2 IP, payload hash, persistence mechanism)
ATT&CK chain
Scope assessment (lateral movement check)
Containment recommendation + order

Containment order principle: Network block before host isolation (prevent attacker awareness).

Output 2: Detection Rule (Permanent Capability)

When to produce: any confirmed TP where the behavioral pattern is stable enough to detect future occurrences.

ABLE Gate Application

Finding: Host with CV=0.028, conn_count=2880, self-signed cert, svchost.exe from AppData

ABLE check before writing the rule:

A — Assumptions:
  "svchost.exe running from AppData is always malicious"
  VALID for our environment? → YES — svchost.exe should only run from System32
  Exception: check with endpoint team for any custom software

B — Behaviors:
  Target: svchost.exe path anomaly (binary location != System32) AND network activity
  NOT: specific C2 IP (rotates) or specific JA3 hash (trivially bypassed)
  DURABLE: yes — legitimate svchost will always be in System32

L — Logging:
  Required: Sysmon Event 1 (process image path) AND Event 3 (network connection)
  Available in all environments? → HQ: YES. Branch: Event 1 yes, Event 3 only at Zeek edge
  Coverage gap documented: branch network connections not correlated with host process

E — Exploitability:
  Can attacker bypass? → Move svchost.exe to System32\subfolder — harder
  Or rename malware to a non-svchost name — different rule catches it
  Expected TP lifespan: 12+ months (requires attacker to fundamentally change delivery)

Sigma Rule Output

title: Svchost Running from Non-Standard Path with Network Connection
id: 9f3e2a1c-...
status: experimental
description: Detects svchost.exe executing from a path other than System32,
             which indicates masquerading. Legitimate svchost.exe always 
             runs from C:\Windows\System32\.
references:
  - https://attack.mitre.org/techniques/T1036/005/
author: Threat Hunt Team
date: 2024-09-02
tags:
  - attack.defense_evasion
  - attack.t1036.005
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\svchost.exe'
  filter_legitimate:
    Image|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
  condition: selection and not filter_legitimate
falsepositives:
  - Unknown — validate against environment before production deployment
level: high

Output 3: CTI Deliverable

When to produce: when the finding reveals something the organization didn’t previously know about adversary activity — novel TTP, new actor, or significant campaign evidence.

CTI Deliverable Structure

## HUNT REPORT: Network Beacon + Process Hollowing — 2024-09-02

**Classification:** TLP:AMBER (internal + trusted partners)
**Analyst:** M. Torres
**Hunt date:** 2024-09-02 (30-day data window)

### Executive Summary
One host confirmed running Cobalt Strike beacon via process hollowing into 
svchost.exe. Active for ≥30 days. Escalated to IR (Case #2024-089).
C2: 185.220.101.9:443 (Scaleway VPS, France).

### ATT&CK Chain
| Phase | Technique | Evidence |
|---|---|---|
| Initial Access | T1566.001 (Phishing) | invoice_Q4.docm LNK chain |
| Execution | T1059.001 (PowerShell) | Encoded command, macro spawned |
| Defense Evasion | T1055.012 (Process Hollowing) | Volatility malfind, MZ in svchost |
| C2 | T1071.001 (Web Protocols) | TLS port 443, self-signed cert |
| Persistence | T1547.001 (Registry Run) | HKCU\...\Run\svcmon |

### IOC Pack
#### Tactical IOCs (short TTL)
- C2 IP: 185.220.101.9 (Scaleway AS12876)
- C2 domain: update-cdn-proxy.net (registered 14 days before discovery)
- Payload SHA256: 4a3f7e2c...
- Cert serial: 1 (self-signed, 30-day validity)

#### Strategic IOCs (behavioral, durable)
- svchost.exe running from non-System32 path (see Sigma rule c3f7a2e1)
- Process with MZ header in private EXECUTE memory (malfind signature)
- Beacon CV < 0.05 to rare external destination (RITA score > 0.9)

### Detection Coverage
- [Sigma rule shipped] c3f7a2e1 — svchost path anomaly
- [Hunt journal] 2024-09-02 — beacon hunt, 30-day scope, HQ segments
- ATT&CK Navigator layer: [attached] hunt-2024-09-02.json

### Open Questions for Future Hunts
- Initial access vector: LNK from phishing? How did docm arrive?
  → Hypothesis: T1566.001 hunt in email gateway logs
- Are there other hosts with similar behavioral patterns?
  → Hypothesis: fleet-wide rarity hunt for non-System32 network-connected processes

Retrieval Practice

A hunt finds a null result for DNS tunnelling in a 30-day window. The hunter decides not to produce any Act phase outputs because 'nothing was found.' What PEAK Act output is still required and why?

Reveal answer

A null result still requires Act phase output: a documented hunt journal entry and, optionally, an updated ATT&CK Navigator layer (green = covered). The hunt journal entry must include: (1) hypothesis, (2) data source and time window, (3) queries run, (4) null result with explicit coverage statement (e.g., 'covered HQ DNS traffic via Zeek, 30 days'), (5) confidence in the null result, (6) coverage gaps (e.g., branch offices not in scope). This matters because: without documentation, the null result is indistinguishable from 'we never ran this hunt.' The journal entry becomes evidence of defensive posture: 'We searched for DNS tunnelling in these segments over this period and found no evidence of it.' It also prevents other analysts from re-running the same hunt unknowingly. No TP is not the same as no output — the output is the documented coverage.

Retrieval Practice

Why must a detection rule target the 'behavior' rather than the 'artifact' according to ABLE, and what is a concrete example of the transformation?

Reveal answer

Artifact-based rules expire when the artifact changes (IP rotates, hash recompiled, domain abandoned). Behavior-based rules remain valid as long as the technique is used. Concrete example: Artifact-based (bad): 'Alert when dst_ip = 185.220.101.9 AND JA3 = a1b2c3d4.' Expires the moment the attacker rotates infrastructure — within days to weeks. Behavior-based (good): 'Alert when svchost.exe runs from a non-System32 path AND makes an outbound TCP connection to an external IP.' This captures the masquerading + C2 technique regardless of which IP the attacker uses, which JA3 they configure, or which domain they register. The behavioral rule catches the next campaign as well as the current one. The ABLE B gate forces the analyst to ask: 'What would remain true about this attack even if the attacker changed every piece of infrastructure?' — that remainder is the behavior the rule should target.