TaHiTI — Structured Hunt Documentation

PEAK gives you the workflow. TaHiTI gives you the documentation standard. A hunt that produces no shareable, repeatable report is valuable only to the analyst who ran it — it can’t be reviewed, repeated, or built upon. TaHiTI solves this by specifying exactly what every hunt report must contain.

The TaHiTI Report Structure

A TaHiTI report has five mandatory sections:

┌────────────────────────────────────────────────────┐
│                  TaHiTI Hunt Report                 │
├────────────────────────────────────────────────────┤
│ 1. Hunt Objective      (why this hunt)             │
│ 2. Data Sources        (what was queried)          │
│ 3. Hunt Queries        (how it was searched)       │
│ 4. Findings            (what was found)            │
│ 5. Recommendations     (what happens next)         │
└────────────────────────────────────────────────────┘

Worked Example: A TaHiTI Hunt Report

Hunt topic: Lateral movement via SMB (T1021.002, PsExec-style) in the financial environment.

Section 1: Hunt Objective

## Hunt Objective

**Hypothesis:**
Threat actors targeting financial institutions use PsExec or equivalent SMB-based 
lateral movement (T1021.002) for post-compromise traversal. Based on the Q2 2026 
FS-ISAC advisory on TTPs targeting European banks, we assess a moderate probability 
that similar TTPs may have been used in our environment in the past 60 days.

**Predicted evidence:**
If PsExec-style lateral movement occurred, we expect:
- Sysmon Event 1: PSEXESVC.exe created on target hosts
- Sysmon Event 17/18: Named pipe creation/connection for PSEXESVC
- Windows Event 7045: New service (PSEXESVC) installed on target
- Sysmon Event 3: SMB connections (port 445) from unusual source hosts

**Scope:**
- Asset: All Windows hosts (servers + workstations)
- Time window: 2026-03-21 to 2026-05-20 (60 days)
- Threat intel anchor: FS-ISAC Advisory 2026-Q2-17, published 2026-05-15

Section 2: Data Sources

## Data Sources

| Source | Event types | Coverage | Verified |
|--------|------------|----------|----------|
| Sysmon (workstations) | Events 1, 3, 17, 18 | 100% of 4,200 workstations | ✓ |
| Sysmon (servers) | Events 1, 3, 17, 18 | 87% of servers (230 of 265) | ✓ |
| Windows Security (all) | Events 4624, 7045 | 100% of domain | ✓ |
| DNS logs | All queries | 100% | ✓ |

**Coverage gaps identified:**
- 35 servers (13%) do not have Sysmon deployed. These are legacy application servers.
  → Gap documented for telemetry remediation. Hunt coverage for these servers is limited
  to Windows Security events only (no CommandLine, no process tree).

Section 3: Hunt Queries

## Hunt Queries

### Query 1: PSEXESVC.exe process creation
```spl
index=sysmon EventCode=1 Image="*\\PSEXESVC.exe"
  earliest="-60d"
| table _time, host, User, Image, CommandLine, ParentImage

Results: 0 events

Query 2: New service installation (7045)

index=windows EventCode=7045 ServiceName="PSEXESVC"
  earliest="-60d"
| table _time, host, ServiceName, ServiceType, StartType

Results: 0 events

Query 3: Lateral movement candidates — unusual SMB connections

index=sysmon EventCode=3 DestinationPort=445
  earliest="-60d"
  NOT SourceIp IN (10.0.0.0/8)   # filter internal expected traffic
| stats count by SourceHostname, DestinationHostname
| where count < 5   # rare pairs
| sort count

Results: 23 candidate host pairs — see Findings

Query 4: Admin shares access

index=windows EventCode=5140 ShareName IN ("\\\\*\\ADMIN$", "\\\\*\\C$")
  earliest="-60d"
  NOT SubjectUserName LIKE "svc-%"   # filter service accounts
| stats count by SubjectUserName, IpAddress, ShareName
| sort -count

Results: 147 events — see Findings


---

### Section 4: Findings

```markdown
## Findings

### Query 1 & 2: PSEXESVC — No findings
No PSEXESVC.exe creation or service installation events detected in the 60-day window.
Note: 35 servers without Sysmon remain unvalidated for this specific artifact.

### Query 3: Unusual SMB connections — 23 candidates

| Source | Destination | Count | Classification | Notes |
|--------|------------|-------|----------------|-------|
| ws-dev-04 | db-prod-01 | 2 | **SUSPICIOUS** | Dev host connecting to prod DB server via SMB — no business justification |
| backup-01 | *.* (all servers) | 847 | Benign | Scheduled backup agent — documented |
| helpdesk-01 | various | 12 | Benign | IT helpdesk remote support tool (verified) |
| [... 20 more benign pairs] | | | Benign | Documented admin activity |

**Suspicious finding — ws-dev-04 → db-prod-01:**
- SMB connections from a developer workstation (Tier 2) to a production database server (Tier 1)
- 2 events on 2026-05-12 at 01:47 UTC and 01:48 UTC
- Source user: CORP\dev-jsmith (developer, no production access)
- Investigation status: Escalated to IR team

### Query 4: Admin share access — 147 events
All 147 events attributed to IT administrators using ADMIN$ for authorized remote management.
Verified against IT change management records. No anomalous accounts.

Section 5: Recommendations

## Recommendations

### Detection Rules (Back-pressure)

**Rule 1 (NEW):** Dev-to-Prod SMB connections
```yaml
title: SMB Connection from Development to Production Network
logsource:
  product: windows
  category: network_connection
detection:
  selection:
    DestinationPort: 445
    SourceIp|startswith: '10.10.'   # dev subnet
    DestinationIp|startswith: '10.20.'  # prod subnet
  condition: selection
level: high
tags:
  - attack.lateral_movement
  - attack.t1021.002

Rule 2 (IMPROVE): Existing PsExec rule — add named pipe coverage for Sysmon Events 17/18

Telemetry Gaps

Deploy Sysmon to 35 remaining legacy servers (prioritize those with production data access)
Add Sysmon Events 17/18 (pipe creation/connection) to existing config

Coverage Matrix Update

T1021.002: Changed from “untested” to “Hunted — no confirmed activity; 1 suspicious finding escalated to IR”

Baseline Updates

Normal SMB connections from helpdesk-01 documented in exception list
backup-01 SMB traffic documented as expected backup pattern

Repeat Frequency

Re-run this hunt monthly. Add to hunt library as “SMB Lateral Movement Hunt v1.1”


<KeyTakeaway title="The Recommendations section is where hunt value accumulates">
Analysts sometimes spend 10 hours on the hunt queries and 10 minutes on recommendations. This is backwards. The queries are ephemeral — they run once. The recommendations are permanent: the Sigma rule runs forever, the baseline prevents future false positives, the telemetry gap gets remediated. A hunt report with thin recommendations is 10 hours of work that disappears after the debrief. A hunt report with thorough recommendations is 10 hours of work that permanently improves the detection program.
</KeyTakeaway>

<Reference href="https://www.betaalvereniging.nl/wp-content/uploads/FI-ISAC-use-case-Threat-Hunting-TaHiTI.pdf" title="TaHiTI White Paper" source="Betaalvereniging / FS-ISAC" />

---

<Recall question="A hunt report's Data Sources section says: 'Queried Sysmon for all Windows hosts, 60-day window.' What is wrong with this Data Sources entry, and what should it contain?" answer="The entry is too vague. A complete TaHiTI Data Sources entry should contain: (1) Coverage percentage — what fraction of Windows hosts actually have Sysmon? '100% of workstations, 87% of servers (230/265).' (2) Specific event types queried — Events 1, 3, 17, 18? All events? Event-specific coverage matters because many Sysmon configs exclude specific event types. (3) Coverage verification — was it verified that the data source is actively flowing? A simple query for any Sysmon events in the window confirms the pipeline is working. (4) Identified gaps — the 13% of servers without Sysmon should be called out explicitly. Vague data source documentation leads to ambiguous null results: was there no attack activity, or was there no data? These are very different conclusions." />

<Recall question="Your TaHiTI hunt finds a developer workstation connecting to a production database server via SMB at 2am. You've escalated to IR. The IR team clears the finding — turns out the developer had an authorized emergency access window. What two things must you update in your hunt artifacts, and why?" answer="(1) Update the Findings section of the TaHiTI report: change the classification of ws-dev-04 → db-prod-01 from 'SUSPICIOUS' to 'Benign — verified emergency authorized access, ITCM ticket #XXXX.' Document the specific conditions of the authorized access so future hunters know this specific pair can appear legitimately under emergency change control. (2) Update the detection rule or add an exclusion: the dev-to-prod SMB rule you created should have a filter for documented emergency access windows, OR you accept that the rule will fire for emergency access and require IR validation each time (appropriate for high-severity rules). Without these updates, the next hunter running the same hunt will escalate the same finding to IR, wasting both the hunter's and IR team's time. Documentation is what prevents recurring false positives in the hunt program." />