Stop Searching, Start Hunting: A TaHiTI Hunt-Program Walkthrough Against This Week’s Threat Surface

77,118 unique indicators. 155 clusters. 25 attributed APT clusters running in parallel this cycle — the widest concurrent APT footprint of the year. This is not a list of things to block. It is a hunt-program-scale challenge that no ad-hoc query survives.

TaHiTI — Targeted Hunting integrating Threat Intelligence — is the framework that turns a threat surface this wide into a queue of executable hunts, a backlog of scored hypotheses, and a shipping-cadence for detection content. Developed by the Dutch Financial Community in 2018, it is the discipline that separates hunt programs that scale from hunt teams that burn out.

This post is a walkthrough. We take the live intelligence from this week, categorise the adversary surface into eight hunt-program buckets, generate fifteen ABLE-scored hypotheses across those buckets, execute two hunt sprints end-to-end (three MUST-hunts + three SHOULD-hunts), and ship six detection-engineering handoffs. TaHiTI theory is present but demoted — the point of this post is application.

Written for the working threat hunter, the SOC senior moving into hunting, and the detection engineer whose queue never empties. Vendor-neutral. Program-first. Operator-grade.

01 · TaHiTI in 60 seconds

The framework is small on purpose. Six steps in three phases, with threat intelligence flowing as continuous input beneath. If you can hold this diagram in your head, you can operate a TaHiTI program.

Three phases, briefly

• Initiate — a signal (threat intelligence, incident retro, red-team output, analyst intuition) becomes an ABLE-scored hypothesis stored in the hunt backlog.
• Hunt — the hypothesis is scoped, converted to a query cascade, and executed until it is confirmed, refuted, or promoted to a follow-up.
• Finalize — the outcome becomes documented findings, detection-engineering tickets, or awareness bulletins. Nothing is lost.

ABLE is the hypothesis-quality standard: every hypothesis must name an Actor, a Behavior, a Location, and expected Evidence. A hypothesis that scores less than 4/4 is not backlog-ready.

That is the entire framework. The rest of this post is what happens when you apply it to the intelligence that landed on your desk this week.

02 · The adversary surface — eight hunt-program categories

77,118 unique indicators across 155 clusters is not a hunt plan. It is raw material. Before we can hunt, we must categorise. TaHiTI programs categorise the adversary surface into buckets that map to hunt-program planning — each bucket ends up with its own hypothesis, its own scope, its own priority. Below is how the current week’s dataset decomposes.

How to read this table

Priority is a TaHiTI-native scoring call, not a threat-severity rating. MUST-hunt categories combine high adversary tier, active exploitation risk, and strategic-vertical impact. SHOULD-hunt categories are important-but-not-urgent — work them if capacity allows. COULD-hunt categories represent broad-and-noisy signal that yields more from detection content than from a bespoke hunt.

Sprint assignment is a capacity-planning call. A single hunter with 12 hours per week can execute 2-3 hunts. A team of three can execute 8-10. Categories drop into Sprint 1 (this week), Sprint 2 (next week if MUST-hunts confirm), or Sprint 3+ (backlog). Nothing is skipped — the backlog is the durable state.

The categorisation itself is the hunt program. A hunt team that cannot describe its adversary surface in eight buckets does not have a program — it has a query list. The bucket structure is what makes the backlog prioritisable, the retro loop meaningful, and the metrics comparable across weeks.

03 · The hunt backlog — 15 ABLE-scored hypotheses from this week’s intelligence

Every category above produces one or two hypotheses. Below is the full backlog. All fifteen have been ABLE-scored (Actor, Behavior, Location, Evidence) and priority-tagged. The priority is the hunt-program-planning call, not a threat-severity rating. Effort estimates are hunter-hours end-to-end.

Fifteen hypotheses. Six MUST, five SHOULD, four COULD. Total effort: 48 hunter-hours. Two hunters at 20 hours per week each clears the MUST tier by Wednesday, the SHOULD tier by Friday, and starts the COULD tier the following Monday. That is a realistic weekly hunt-program rhythm.

04 · Sprint 1 — executing the three MUST-hunts

Monday morning, the hunt team pulls the three MUST-hunts (H·01, H·03, H·05) off the top of the backlog. Total estimated effort: nine hunter-hours. Two hunters splitting the load can clear the sprint by Tuesday evening. Below is what actually happens.

FROM edr_process_create AS pc
WHERE pc.parent_image IN ('<browser-A>','<browser-B>','<browser-C>',
                          '<mail-client>','<word-processor>',
                          '<spreadsheet>','<presentation>',
                          '<pdf-reader>')
  AND pc.image_path REGEXP '(Downloads|Temp|AppData/Local/Temp)/'
  AND pc.image_extension IN ('exe','dll','scr','bat','app')
  AND pc.event_time >= NOW() - INTERVAL 30 DAY

... [Q01] ...
  AND (pc.image_signer_subject IS NULL
       OR pc.image_signer_subject NOT IN (allowlisted_signers))
  AND pc.image_signature_status != 'valid_trusted'

FROM edr_process_create AS pc
JOIN edr_network_connect AS nc
  ON nc.host = pc.host
  AND nc.parent_process_sha256 = pc.image_sha256
  AND nc.event_time BETWEEN pc.event_time
                        AND pc.event_time + INTERVAL 60 SECOND
WHERE ... [Q01B conditions] ...
  AND nc.dest_port IN (80, 443, 8080, 8443)
  AND nc.dest_ip NOT IN CIDR('10.0.0.0/8','172.16.0.0/12','192.168.0.0/16')
  AND nc.dest_ip NOT IN (allowlisted_corporate_egress)

FROM [Q02 result] AS ev
LEFT JOIN threat_intel AS ti ON ti.value IN (ev.dest_ip, ev.dest_domain)
WHERE ti.first_seen_in_env >= NOW() - INTERVAL 7 DAY
   OR ti.domain_registration_age < INTERVAL 30 DAY
   OR ti.category IN ('malware','c2','loader')

FROM perimeter_firewall
WHERE source_ip IN CIDR('185.82.73.0/24',
                        '175.110.121.0/24',
                        '88.80.150.0/24')
  AND destination_port IN (502, 44818, 20000,
                           34962, 34963, 34964)
  AND event_time >= NOW() - INTERVAL 60 DAY
| PROJECT source_ip, destination_ip, destination_port, action, event_time

FROM perimeter_firewall
WHERE source_ip IN CIDR('185.82.73.0/24',
                        '175.110.121.0/24',
                        '88.80.150.0/24')
  AND destination_port IN (502, 44818, 20000, 34962, 34963, 34964)
  AND action = 'accept'

FROM ot_dmz_netflow
WHERE destination_port IN (502, 44818, 20000, 34962, 34963, 34964)
  AND source_ip IN (internal_corporate_ranges)
  AND destination_ip NOT IN (known_ot_vendor_ranges)
| PROJECT source_ip, destination_ip, destination_port, bytes, event_time

FROM dns_query AS dq
JOIN host_role_tag AS ht ON ht.host = dq.source_host
WHERE ht.role_tag IN ('dev','eng','finance','c-suite')
  AND (
       dq.query_name REGEXP '^[a-z0-9]{2,10}\.(video-conf|meet|zoom-like|join|call)[^.]*\.(sbs|xyz|link|top|shop)$'
    OR dq.query_name REGEXP '.*(meeting|conference|videocall).*\.[a-z]{2,6}$'
        AND dq.query_name NOT IN (allowlisted_meeting_domains)
      )
  AND dq.query_time >= NOW() - INTERVAL 14 DAY

FROM dns_resolution AS dr
WHERE dr.query_name IN [Q01 candidate list]
  AND dr.resolved_ip IN CIDR('45.61.163.0/24')
| PROJECT dr.query_name, dr.resolved_ip, dr.first_seen

FROM proxy_log AS pl
WHERE pl.destination_domain IN [Q02 confirmed list]
  AND pl.event_time >= [Q02 dns_time]
  AND pl.event_time <= [Q02 dns_time] + INTERVAL 10 MINUTE
| PROJECT pl.source_host, pl.destination_domain, pl.url_path, pl.status_code

End of Sprint 1

Three MUST-hunts executed. Two CONFIRMED (H·01 loader chain, H·05 DPRK lookalike domain), one REFUTED (H·03 ICS/OT probing — perimeter held, but 47 attributed probe attempts confirmed the campaign is active against us). Four IR tickets opened. Two Sigma-rule patterns promoted to Step 06 handoff. One user-awareness bulletin drafted for cryptocurrency-adjacent teams. One backlog escalation (H·02 loader delivery vector). Retro noted the ICS/OT hypothesis should recur every 60 days as a baseline hunt.

Notice what did not happen. No hunter said “let’s go hunt something,” no query returned “nothing found,” no analyst wasted eight hours in a scroll-through-alerts trance. Every hour spent was against a specific hypothesis with a defined stopping condition and a downstream handoff. That is the difference TaHiTI makes.

05 · Sprint 2 — three SHOULD-hunts (briefer walkthrough)

Sprint 2 begins Wednesday. The SHOULD-hunts do not warrant the same query-cascade depth as Sprint 1 (that is why they are SHOULD-tier), but they follow the same structure — scope, execute, iterate, close.

Hunt 04 — H·07 · SVG-embedded script delivery

Category C·4 · 3h · Mail-gateway + endpoint file-write. Query the mail gateway for the last 30 days for any attachment with MIME image/svg+xml where content-inspection flagged <script or javascript: substrings. Join to endpoint file-writes of .svg files to browser cache folders within 5 minutes of mail-delivery. Result: 6 candidate deliveries, 0 with subsequent endpoint activity (users did not preview) — hypothesis REFUTED for compromise, but the 6 delivered attachments confirm the campaign is testing our defences. Handoff: mail-gateway policy update to block (not just log) SVG attachments with embedded script content. Sigma rule promoted.

Hunt 05 — H·08 · Drive-by fake-update chain

Category C·5 · 4h · Web proxy + EDR download folder. Query the proxy for user sessions where a browse to a benign-category site was followed within 5 minutes by a download from a different, non-corporate domain claiming to be a browser or plugin update. Enrich with domain-age filter (registration < 30d). Result: 3 suspicious sessions, all cleared as false positives (legitimate but obscure SaaS onboarding flow — added to allowlist). Hypothesis REFUTED, allowlist improved. Handoff: web-proxy rule to flag downloads from newly-registered domains for user-visible confirmation.

Hunt 06 — H·09 · Regional APT subnet-anchor first-seen contact

Category C·6 · 2h · Netflow + TI enrichment. Query netflow for any internal host reaching an IP in the attributed subnet-anchor list where the (host, destination) pair was first-seen within the last 90 days. Enrich with attributed-cluster metadata from TI. Result: 5 candidate flows, 3 confirmed as false-positive (research team testing external services in the same CIDR block), 2 flagged for follow-up — opened as sub-hunts for the following week. Hypothesis DEFERRED pending investigation. Handoff: a targeted watch for the specific hosts flagged, escalation to sub-hunts for the next backlog cycle.

End of Sprint 2

Three SHOULD-hunts executed. All REFUTED for direct compromise, but each produced a downstream artefact: a policy update, an allowlist improvement, and two follow-up sub-hunts. This is what a healthy SHOULD-tier week looks like — the hunts do not confirm active infection, but they harden the environment and refine the backlog. The team ends the week with more capacity, not less.

06 · Detection engineering handoffs — six Sigma rules ship

Sprint 1 and Sprint 2 together produce six handoffs to detection engineering. Every confirmed and every well-scoped-refuted hunt yields at least one production artefact. This is the loop that compounds — each week’s hunts become the next week’s detection content, permanently improving coverage without permanently consuming hunter time.

Two Sigma rules ready to deploy today

Sigma LDR-01 · loader chain (universal, medium severity)

title: Loader Chain — Browser-or-Doc Parent Spawns Unsigned Binary from Downloads with 60s Outbound
id: 7f3c2a8e-6b45-4930-a681-3f9b5c2e8d10
status: experimental
description: |
  Detects the universal loader chain — browser or document-reader process
  spawns a binary from Downloads/Temp with no valid trusted signature, which
  then makes outbound web connection to non-corporate destination within 60s.
  Ships from HackForLab hunt H·01 CONFIRMED (3 TPs).
references:
  - https://hackforlab.com/tahiti-threat-hunting-framework-series-part-1/
author: HackForLab Threat Hunt Program
date: 2026/07/30
tags:
  - attack.execution
  - attack.t1204
  - attack.command_and_control
  - attack.t1105
  - attack.t1071.001
logsource:
  product: correlation
detection:
  s1_downloaded_binary:
    ProcessCreateEventID: any
    # Substitute your environment's actual process names
    ParentImage|endswith:
      - '\<browser-A>.exe'
      - '\<browser-B>.exe'
      - '\<mail-client>.exe'
      - '\<word-processor>.exe'
      - '\<spreadsheet>.exe'
      - '\<pdf-reader>.exe'
    Image|contains:
      - '\Downloads\'
      - '\Temp\'
      - '\AppData\Local\Temp\'
    ImageSignatureStatus|not:
      - 'valid_trusted'
  s2_outbound_web:
    DestinationPort: [80, 443, 8080, 8443]
    DestinationIp|expand: '%non_corporate_destinations%'
  condition: s1_downloaded_binary and s2_outbound_web within 60s
falsepositives:
  - Legitimate installers from allowlisted publishers (maintain signer allowlist)
level: medium

Sigma OT-01 · PLC-targeted subnet + OT-protocol egress (critical severity)

title: OT-Protocol Traffic to or from Attributed Subnet Anchors (ICS/OT)
id: 8d1a4b6f-5c92-4670-a881-3f9c7d5b2a40
status: experimental
description: |
  Detects any perimeter connection to or from three concentrated subnet
  anchors attributed to active PLC-targeted campaign, or internal OT-protocol
  egress to non-vendor destinations. Ships from HackForLab hunt H·03.
references:
  - https://hackforlab.com/tahiti-threat-hunting-framework-series-part-1/
author: HackForLab Threat Hunt Program
date: 2026/07/30
tags:
  - attack.command_and_control
  - attack.t1071
  - ics.t0819
  - ics.t0866
logsource:
  category: network_connection
detection:
  ot_subnet_anchors:
    DestinationIp|cidr:
      - '185.82.73.0/24'
      - '175.110.121.0/24'
      - '88.80.150.0/24'
  ot_protocol_egress:
    DestinationPort:
      - 502    # Modbus TCP
      - 44818  # EtherNet/IP
      - 20000  # DNP3
      - 34962  # Profinet
      - 34963  # Profinet
      - 34964  # Profinet
    DestinationIp|expand: '%external_destinations%'
  condition: ot_subnet_anchors or ot_protocol_egress
falsepositives:
  - Legitimate OT vendor remote-support (allowlist by known-good IPs)
level: critical

Handoff discipline is what makes TaHiTI a program instead of an activity. A hunt that confirms but never becomes a Sigma rule leaves no institutional memory. A hunt that refutes but never updates the allowlist or the mail-gateway policy leaves no operational improvement. Every hunt outputs at least one downstream artefact — that is a program-level requirement, not a hunter preference.

07 · Scaling TaHiTI when 25 APTs are concurrent

Twenty-five attributed APT clusters running in parallel is more adversary surface than any single hunter, or any small team, can chase in a single week. The temptation is to try — run twenty-five little hunts, one per cluster, spread thin, generate no findings, retreat exhausted. TaHiTI programs resist that temptation with three disciplines.

Discipline 1 · Ruthless prioritisation

Of 25 attributed APT clusters this cycle, only 3-6 are MUST-hunt for any given organisation. The MUST tier is defined by your adversary-tier + your asset value + your exploitation risk. A cryptocurrency-adjacent finance team hunts DPRK-adjacent clusters MUST; a heavy-industry utility hunts ICS/OT-focused clusters MUST; a research organisation hunts intellectual-property-focused clusters MUST. The rest is SHOULD or COULD.

The MUST tier is not a “most severe” ranking. It is a “most likely to matter to us this week” ranking. Twenty-two of twenty-five clusters this week did not make our MUST tier. That is correct.

Discipline 2 · Defer, do not ignore

The 22 non-MUST clusters do not disappear. They enter the backlog as SHOULD or COULD hypotheses. Every week the backlog is re-scored. A cluster that stays in the field for three weeks and gains fresh IOCs may promote from COULD to SHOULD. A cluster whose IOCs age out with no fresh signal retires quietly at 90 days.

The backlog is the durable state that lets a small team hunt a wide adversary surface. Without a backlog, every week the team either over-commits (25 shallow hunts) or under-commits (3 hunts, 22 forgotten). With a backlog, the coverage compounds over time.

Discipline 3 · Detection engineering compounds

Every confirmed hunt that ships a Sigma rule removes that hypothesis from the backlog going forward. Next week we no longer need to hunt the loader chain by hand — Sigma LDR-01 catches it in real time. The hunter cycles freed up move to the next-tier hypotheses. Over three months, a TaHiTI program that ships 4-6 Sigma rules per week converts what would be an infinite backlog into a stable one.

This is why the Sprint 3-and-beyond COULD-tier is not a “we never get to it” graveyard — it is the reservoir the program pulls from as detection engineering absorbs the MUST and SHOULD tiers over time.

The scaling answer. A team of two hunters running TaHiTI against a 25-APT surface can produce four production Sigma rules per week, defer sixteen hypotheses to a healthy backlog, and reduce the MUST-tier by one hypothesis every fortnight through detection-engineering absorption. That is a program that scales.

08 · The weekly cadence — making this repeatable

TaHiTI at program-scale runs on a weekly rhythm. Below is the cadence a working team of two hunters plus one part-time detection engineer maintains against the kind of adversary surface described above.

Total weekly hunter-hours: ~24 (two hunters at 12 hours each). Weekly detection-engineering time: ~4 hours. Weekly hunt-lead overhead: ~3 hours. That is a working TaHiTI program at operational scale — not a research project, not a heroic effort, a sustainable weekly rhythm.

09 · What good looks like — four-week metric benchmark

Four weeks into a TaHiTI program running the weekly cadence above, a healthy dashboard shows the following. If your program lands close to these numbers, you are at L2 (TaHiTI-basic) with a trajectory to L3 (TaHiTI-integrated) within the following quarter.

What NOT to measure. Number of queries run. Number of alerts triaged. Time spent in the SIEM. These are vanity metrics — they reward activity, not outcome. The metrics above reward hunt yield and detection compounding, which are the only two things that make a hunt program better next month than it was this month.

10 · Frequently asked questions