Threat intelligence lands on your desk every week. Advisories, feed digests, IOC drops, adversary reports. The question that separates hunt programs that scale from teams that drown is: what do you do with it?
TaHiTI — the Targeted Hunting integrating Threat Intelligence methodology from the Dutch financial-sector CERT community — answers that question with a specific artefact called the investigation abstract. The abstract is the Phase-I output that converts a raw threat-intelligence trigger into an executable hunt. Without the abstract, intelligence stays intelligence — consumed, filed, forgotten. With the abstract, intelligence becomes hunt inventory.
This is Part 2 of the TaHiTI series. In this post we cover the investigation abstract in full depth: its five fields (per the official methodology), the five characteristics of a hypothesis worth hunting, the sources that trigger abstracts, the enrichment mechanics of Phase II Step 3, and three worked examples that convert this week’s live threat-intelligence signal into methodology-faithful investigation abstracts you could pull off the backlog Monday morning.
Part 1 covered the framework end-to-end and a hunt-program walkthrough. This one goes deep on the single most under-invested Phase-I mechanic. Written for the working threat hunter, the CTI analyst moving into hunting, and the detection engineer whose queue never empties. Vendor-neutral. Methodology-faithful. Operator-grade.
02 · What an investigation abstract IS
03 · The five trigger sources
04 · Five characteristics of a good hypothesis
05 · Example A · macOS multi-family surge
06 · Example B · Supply-chain wave
07 · Example C · Regional APT contact
08 · Enrichment (Phase II · Step 3)
09 · Backlog prioritisation
10 · Investigation bias — the anti-patterns
11 · The abstract template
12 · FAQ
HuntIntel ships the threat-intelligence feed the three worked-example abstracts below are drawn from — category-tagged, ATT&CK-mapped, confidence-scored, ready for hunt-time enrichment.
01 · TaHiTI process recap — where the abstract lives
The official FI-ISAC methodology (v1.0, published 2018) defines TaHiTI as three phases, six steps. The single artefact that carries information across every phase is the investigation abstract. In Phase 01 it is created from a trigger. In Phase 02 it is enriched, and its hypothesis is refined and executed. In Phase 03 it is updated with findings and handed off. If you understand how the abstract flows through the process, you understand TaHiTI.
Part 2 focuses on Phase 01 · Step 02 (Create investigation abstract) plus the Step-03 enrichment that turns the abstract into an executable investigation. This is where threat intelligence and threat hunting actually meet.
Everything else in this post is about the four boxed items in Phase 01 Step 02 and Phase 02 Step 03. Those are the mechanics that decide whether your hunt program compounds or stalls.
02 · What an investigation abstract IS — per the official methodology
Directly from the FI-ISAC v1.0 specification: when a hunt trigger is received, the hunting team creates a hunting investigation abstract. The abstract is a basic description of the investigation — not the full detail (that comes in Phase 02 Step 03). Its purpose is to be lightweight enough to be captured quickly, structured enough to sit in a backlog and be prioritised against other abstracts, and complete enough to be selected for execution weeks later without needing to reconstruct the context.
The four fields of the initial abstract (Phase 01 · Step 02)
| Field | Contains |
|---|---|
| Date | Creation date of the abstract. Anchors when the intelligence signal was captured — important because signals age. |
| Initial hypothesis | A preliminary hypothesis that will be refined when the abstract is selected for execution. The initial version does not need to be perfect — but it must be specific enough that the hunt team, three weeks from now, can reconstruct what was intended. |
| Trigger | Where the abstract came from. URLs to online resources, references to internal ticket IDs, feed identifiers, incident numbers, red-team report references. Any evidence that lets a hunter re-derive the source of the intelligence. |
| Hunt priority | A risk-driven priority score. TaHiTI names contributing factors: active campaigns targeting the organisation’s sector, adversary tier, existing detection coverage, existing preventative measures, prevalence of the TTP in the wild. |
That is the abstract at creation time. Four fields. Enough to be filed in the backlog. Not yet enough to execute.
The five additional fields added at enrichment (Phase 02 · Step 03)
When the abstract is pulled from the backlog for execution, it is enriched. TaHiTI specifies exactly what is added:
| Field added | Purpose |
|---|---|
| ATT&CK reference | Technique ID from the ATT&CK framework linking the abstract to a documented adversary technique. Lets the hunter find related techniques the adversary might also employ. |
| Threat intelligence | Actor identification (attributed cluster, category), capabilities, motives. Determines how sophisticated the adversary is and how hard they will try to hide. |
| Hunt classification | Where the hunt sits in the cyber kill chain (or equivalent classification model). Determines what evidence would be visible at what stage of an attack. |
| Required resources | Estimated hunter-hours, cooperation with other departments, additional technical resources needed. Allows realistic sprint planning. |
| Refined hypothesis | The initial hypothesis, sharpened into something clear, precise, testable, scoped, and completable in reasonable time. The next section covers the five characteristics of a good hypothesis. |
Nine total fields on a fully-enriched abstract. Four at creation, five at enrichment. Every field has a purpose. Every field is used. This is not documentation for documentation’s sake — each field prevents a specific failure mode later in the process.
03 · The five trigger sources — where abstracts are born
The official methodology names five sources that can trigger the creation of an investigation abstract. A mature hunt program pulls from all five, not just one. Below is what each source produces, with commentary on how they map to this week’s live intelligence.
Trigger source 01 · Threat intelligence
The major source per TaHiTI. External TI feeds, weekly advisories, ISAC bulletins, sector-specific intelligence, adversary reports. This week’s catalogue delivered 54,763 unique IOCs across 107 clusters — every one of them a potential abstract trigger. The mature program filters: not every indicator becomes an abstract. Abstracts are generated only when the intelligence carries at least one of: high-tier adversary attribution, sector relevance, active campaign status, or a novel TTP.
Trigger source 02 · Threat hunting itself
Hunts spawn hunts. When a hunt uncovers evidence of a technique or pattern, that finding often generates follow-up abstracts for related techniques or adjacent target profiles. TaHiTI calls this the iterative nature of the process — and it is where mature programs generate their highest-yield hypotheses (post-hunt follow-ups have insider context that external TI lacks).
Trigger source 03 · Security monitoring gaps
Detection-coverage reviews (using frameworks like MaGMa or ATT&CK-navigator overlays) surface use cases that are absent or incomplete. Each gap is a candidate abstract. This week’s data example: if your detection coverage does not include the framework-C2 signature layer (52,717 IOCs of pressure this cycle), that gap becomes an abstract for a hunt validating whether the framework has been active in your environment before you shipped detection.
Trigger source 04 · Security incident response
Two sub-sources under this heading. First: historical incidents — especially incidents where the root cause could not be fully resolved. Those cases are the best abstract candidates because the method has already been proven to work against you. Second: red teaming output — TTPs that succeeded during authorised offensive testing warrant hunt abstracts for real-world use of the same TTPs predating the exercise.
Trigger source 05 · Other (domain expertise, crown jewel analysis, hunter intuition)
Crown-jewel analysis identifies the assets that matter most, then works backward from “how would an attacker reach these?” to generate abstracts. Domain expertise and hunter intuition — the “something is odd here” feeling — are also legitimate triggers per the methodology, but they must pass the hypothesis-quality check (next section) before entering the backlog. Intuition without a testable hypothesis is not an abstract; it is a hallway conversation.
Diversify your triggers. A hunt program sourcing 100% of abstracts from external TI is drinking from one well. When the well runs shallow, the program stalls. A mature program pulls 40-60% from external TI, 15-25% from post-hunt follow-ups, 10-20% from monitoring-gap reviews, 10-15% from IR retros, and 5-10% from crown-jewel / intuition. The mix matters.
04 · The five characteristics of a good hypothesis
The hypothesis is the load-bearing element of the abstract. Get it wrong and the hunt either yields no results, or worse, yields wrong results. TaHiTI names five characteristics a hypothesis must satisfy. Below is each characteristic, with a bad example from this week’s data and its improved rewrite.
Characteristic 01 · Clear and precise
The hypothesis must be unambiguous. If two hunters can read it and reach different interpretations, it fails this test.
| Bad: “Look for suspicious activity” | Good: “Any workstation initiating outbound TLS to destinations matching this cycle’s framework-C2 concentrated anchors, where the (host, destination) pair is first-seen within the last 7 days” |
Characteristic 02 · Testable
The hypothesis must be provable or disprovable with evidence available in your environment. Hypotheses about the absence of something are usually not testable.
| Bad: “Attackers are hiding their presence” (unfalsifiable — absence of evidence is not evidence of absence) | Good: “Endpoint hosts show file-write of a LaunchAgent plist to a user-writable path by a process whose signer is not on the allowlist — within the last 90 days” |
Characteristic 03 · Limited in scope and specific
Vague-scope hypotheses have no clear stopping condition. Narrow the scope until you can define what “done” means.
| Bad: “Adversaries are targeting our developers” | Good: “Untrusted-signer installer file-writes on subnet-tagged developer endpoints, where the installer filename matches known package-registry-tool naming conventions, within the last 60 days” |
Characteristic 04 · Consistent with most known facts
The hypothesis must build on what is already known about the adversary and the environment. High-quality threat intelligence is the input that keeps hypotheses grounded.
| Bad: “Nation-state actor infiltrating our developer environment via supply chain” (unsupported by any specific attribution this cycle) | Good: “Fake-package supply-chain campaign observed with 19 IOCs this cycle — test whether our developer endpoints have installed any of the attributed package names in the last 60 days” |
Characteristic 05 · Testable within reasonable time
Hunting is expensive. Time-box every hypothesis. If it cannot be tested in a reasonable window, decompose it into sub-hypotheses that can.
| Bad: “Attackers have compromised our environment at some point in the last 5 years” | Good: “Framework-C2 signature match at network egress in the last 30 days” (executable in 2 hours with pre-existing signature content) |
The 5/5 rule. A hypothesis that scores less than 5/5 on these characteristics is not backlog-ready. Send it back to the analyst who proposed it, with the missing dimension flagged. This gatekeeping is the single most under-invested-in discipline in immature hunt programs — and the discipline that separates programs that ship detection content from programs that ship nothing.
Signal: multi-family macOS surge — three concurrent families
Raw intelligence signal from this week: three concurrent macOS-native malware families active this cycle (combined 136 IOCs across DOMAIN + HASH + IP). Individually each family is small; the concurrent-family signal is the anomaly. Typical baseline is one macOS family per cycle.
TI actor: three attributed macOS-native families this cycle (labels sanitised)
Kill chain stage: Installation / Persistence
Resources: 4h hunter-time · EDR file-event query · signer-allowlist reference
Refined hypothesis: Endpoint hosts running macOS show file-write of a LaunchAgent or LaunchDaemon plist to a user-writable path by a process whose signer is not on the vendor / allowlist, within the last 90 days
Signal: developer-ecosystem supply-chain wave
Raw intelligence signal from this week: multiple concurrent supply-chain campaigns targeting the developer ecosystem — fake package registrations (19 IOCs), fake developer-tooling installer sites (10), fake AI-assistant installers (8), fake job-interview software (13). Modest aggregate volume; disproportionate blast radius per compromise.
TI actor: multiple concurrent operators, none attributed to single tracked cluster
Kill chain stage: Delivery + Installation
Resources: 6h hunter-time · endpoint file-event + mail-flow + web-proxy joins · signer allowlist maintenance
Refined hypothesis: Endpoints tagged as developer / engineer / DevOps show file-write of installer files (.msi, .pkg, .dmg, .exe, .deb) where the writer’s signer is not on the developer-tooling allowlist AND the source is a mail attachment or web download from a non-corporate domain, within the last 60 days
Signal: regional APT cluster first-seen contact
Raw intelligence signal from this week: two tracked APT clusters attributed to regional operations produced fresh IOCs (combined 44 IOCs across DOMAIN + HASH + IP). Target profiles include diplomatic, defence-industrial-base, government-adjacent research, and specific regional verticals.
TI actor: two attributed regional-operation clusters (label sanitised) — long-dwell surveillance profile
Kill chain stage: Command and Control · Actions on Objectives (long-tail surveillance)
Resources: 3h hunter-time · netflow + DNS + TI enrichment table
Refined hypothesis: Netflow records where destination_ip OR resolved-domain matches the attributed IOC list for the two regional-operation clusters active this cycle, where the (source_host, destination) pair is first-seen within the last 90 days
08 · Enrichment — Phase 02 Step 03 mechanics
The three worked examples above show the abstract at creation. When any of them is pulled from the backlog for execution, Phase 02 Step 03 (Define / refine) enriches the abstract with five additional fields. TaHiTI specifies exactly what to add and why.
Enrichment field 01 · ATT&CK reference
Add the ATT&CK technique ID (or IDs) the hypothesis maps to. This lets the hunter navigate the framework to find related techniques the adversary might also employ — extending the hunt scope without requiring the analyst to remember every pivot. The ATT&CK navigator is a common tool for this pivoting. For each hypothesis: one primary technique, optionally 1-3 related pivots.
Enrichment field 02 · Threat intelligence
Add attributed actor (or cluster category), capabilities, and motives. Determines how sophisticated the adversary is and how hard they will try to hide. A commodity ransomware operator behaves differently from a nation-state APT — the hunter needs to know which they are chasing. The threat-intelligence field also enables the pivoting behaviour described in TaHiTI — from actor to closely-related actors that might share infrastructure.
Enrichment field 03 · Hunt classification (cyber kill chain)
Where in the attack lifecycle does the hypothesis sit? Delivery? Installation? Command and Control? Exfiltration? This determines what evidence is even possible to find. A hypothesis about Persistence looks for filesystem artefacts. A hypothesis about C2 looks for network patterns. Classification prevents hunters from looking in the wrong data source.
Enrichment field 04 · Required resources
Hunter-hours, cooperation with other departments (IR, TI, engineering), additional technical resources (new data-source ingestion, sandbox capacity, enrichment API budget). Turns the abstract from an intention into a sprint-plannable work item. Prevents the pattern where hunts start without capacity commitment and stall halfway.
Enrichment field 05 · Refined hypothesis
The initial hypothesis, run through the five-characteristics checklist and rewritten. Every worked example above shows this progression: the “Initial hypothesis” line is short and general; the “Refined hypothesis” line is precise, testable, scoped, and time-boxable. The refinement is not cosmetic — it is the difference between a hunt that produces a defensible outcome and one that produces nothing.
Determining data sources and analysis techniques
Phase 02 Step 03 also determines which telemetry to query and how to analyse it. TaHiTI names six analysis-technique classes to consider:
| Technique | When to use |
|---|---|
| Simple querying | When the hypothesis maps to specific field values (e.g. process names, ports, hashes). Fastest. |
| Stack counting | When you need to identify outliers by frequency (least-common signer, least-common destination port for a host). Great for scoping. |
| Request / response ratio | When abnormal traffic-flow shape is the signal — large-request / small-response = potential exfiltration; small-request / large-response = potential download. |
| Statistical analysis | When you have a baseline and want to identify deviations (mean + 2 standard deviations, percentile-based outlier detection). Requires stable baseline. |
| Clustering | When you want to group events that behave similarly — time-based clusters for burst detection, k-means for behaviour groups. Requires basic statistics familiarity. |
| Grouping | When you want to find shared attributes across a candidate set — common accounts across suspicious hosts, common destinations across compromised users. Post-hoc pivot technique. |
A well-enriched abstract names the primary technique and 1-2 fallback techniques for when the primary yields inconclusive results.
09 · Backlog prioritisation — which abstracts survive
Not every abstract in the backlog becomes an executed hunt. A healthy backlog holds 20-40 abstracts at any time; a healthy sprint executes 4-8. Prioritisation decides which 4-8 survive the cycle. TaHiTI names five contributing factors that should feed the priority score:
| Factor | Effect on priority |
|---|---|
| Active campaigns targeting your sector | + Elevate. If an attributed campaign is currently active against organisations in your industry, hunt now. The intelligence is fresh; the operator is engaged. |
| Adversary tier | + Elevate for nation-state / long-dwell surveillance; standard for commodity operators. Higher-tier adversaries reward proactive hunting because passive detection alone often misses them. |
| Existing detection coverage | − De-prioritise. If you already have production detection content for the TTP, a proactive hunt is lower-value — unless you have reason to believe the detection missed something. |
| Existing preventative measures | − De-prioritise. If the technique is architecturally blocked (MFA blocks credential-stuffing, application allowlisting blocks unsigned binaries), hunt is lower-value. |
| Prevalence of the TTP in the wild | + Elevate for common-and-currently-active; ~ Standard for rare-and-observed; − De-prioritise for rare-and-theoretical. |
Backlog review cadence
Priorities change. An abstract that scored MUST-hunt last week may be COULD-hunt this week if detection engineering shipped coverage for it. An abstract that sat as COULD-hunt for two months may promote to MUST-hunt if fresh intelligence shows the campaign has reactivated. TaHiTI mandates regular backlog reviews to maintain scoring accuracy.
Backlog age retirement
Abstracts that sit untouched for 90+ days should be actively retired — either promoted (with fresh intelligence source) or archived. The intelligence signal that generated them has aged out; the hypothesis needs re-sourcing before it can be trusted. Backlogs that grow without bound become graveyards; retirement discipline keeps them working.
10 · Investigation bias — the anti-patterns TaHiTI warns about
Any investigation is vulnerable to bias. Bias causes hunters to overlook evidence and reach wrong conclusions. TaHiTI explicitly names three bias types to defend against.
Confirmation bias
The hunter is looking for ways to prove the hypothesis and ignoring facts that would refute it. Every query is designed to find supporting evidence; contradicting data is dismissed as noise. The defence: an explicit “what would disprove this hypothesis?” question in the abstract, and adversarial hunt-partner review of findings before they leave the hunt team. If two independent hunters reach the same conclusion from the same data, the confirmation risk drops materially.
Anchoring bias
The hunter fixates on the initial information and refuses to update the mental model when new evidence arrives. Refinement stops. The TaHiTI process explicitly counters this — Phase 02 Step 3 is iterative for a reason. Hypotheses, scope, data sources, and analysis techniques can all be refined mid-hunt. Discipline: schedule an explicit checkpoint at 50% of the estimated hunter-hours where the hunt lead reviews whether the current direction still makes sense.
Availability bias
The hunter investigates whatever data is easiest to reach, not the data that would best test the hypothesis. This is common when data-source-inventory work in Phase 02 Step 3 is skipped or superficial. Defence: the required-data-sources field is not optional. If the required data source is missing or hard to reach, that is a Phase-3 finding (data-source coverage gap), not a reason to substitute an inferior source.
The bias-defence checklist. Before closing any hunt, the hunt lead should answer three questions: (1) What evidence would have refuted this hypothesis, and did we look for it? (2) Did any evidence arrive mid-hunt that should have changed our approach, and did it? (3) Did we hunt against the right data, or the easy data? A “no” or “unclear” answer to any question is a signal to reopen before handoff.
11 · The abstract template — copyable structure
The reusable structure for every abstract in your backlog. Adapt to your tooling (spreadsheet, issue tracker, documentation platform — TaHiTI is tool-agnostic). What matters is that every field is captured.
INVESTIGATION ABSTRACT · HYP-YYYY-NNN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PHASE 01 · STEP 02 · CREATION (four fields)
─────────────────────────────────────────────
DATE : [YYYY-MM-DD]
TRIGGER : [source · reference · URL · ticket ID]
INITIAL HYPOTHESIS : [brief, will be refined at execution]
HUNT PRIORITY : [MUST | SHOULD | COULD | WONT]
[justification: adversary tier · sector · coverage · prevalence]
PHASE 02 · STEP 03 · ENRICHMENT (five fields added)
────────────────────────────────────────────────────
ATT&CK REFERENCE : [primary technique ID · related pivots]
THREAT INTEL : [actor category · capabilities · motives]
KILL CHAIN STAGE : [Recon | Weaponisation | Delivery | Exploitation |
Installation | C2 | Actions on Objectives]
REQUIRED RESOURCES : [hunter-hours · departments · technical resources]
REFINED HYPOTHESIS : [clear · precise · testable · scoped · time-boxable]
PHASE 02 · STEP 03 · ADDITIONAL (data + analysis)
──────────────────────────────────────────────────
DATA SOURCES : [comma-separated list · verify availability]
ANALYSIS TECHNIQUES: [query | stack-count | ratio | statistical |
clustering | grouping]
SCOPE : [hosts · time-window · exclusions]
STOPPING CONDITION : [what makes this hunt done?]
PHASE 03 · STEP 05 · FINALISATION (added post-hunt)
────────────────────────────────────────────────────
VALIDATION : [PROVEN | DISPROVEN | INCONCLUSIVE]
FINDINGS : [true positives · false positives cleared]
ROOT CAUSE : [why did the technique succeed / fail?]
HANDOFFS : [IR ticket · Sigma rule · awareness bulletin · backlog additions]
RETRO NOTES : [what worked · what did not · missing data · lessons]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Fifteen fields total across the three phases. Every field prevents a specific failure mode. Skipping fields feels like efficiency and produces the classic anti-patterns: hunts that cannot be reconstructed later, hypotheses that turn out to be untestable at execution time, hunts that never produce detection content because the handoff field was never populated.
12 · Frequently asked questions
Do I really need 15 fields per abstract? Feels like a lot.
At maturity, yes. In early program stages, start with the four Phase-01 fields (Date, Trigger, Initial Hypothesis, Priority). Add the five Phase-02 enrichment fields when you have a hunt lead who can enforce the discipline. Add the Phase-03 finalisation fields when detection engineering handoff is a working loop. Programs that try to do all 15 fields on day one usually fail the discipline within 4 weeks. Grow into it.
What tool should I use for the backlog?
TaHiTI is explicitly tool-agnostic. The original methodology suggests a spreadsheet or a lightweight collaboration tool works fine. Common patterns: issue tracker with custom fields; documentation platform with database views; spreadsheet with pivot filters. What matters is capturing every field consistently and being able to sort by priority. Do not delay the program waiting for the right tool.
How is the investigation abstract different from a Sigma rule?
An abstract is a hunt plan; a Sigma rule is a production detection. The abstract describes an episodic proactive investigation you will run once (or periodically). The Sigma rule describes an always-on real-time detection deployed to production tooling. A confirmed hunt frequently produces a Sigma rule as its Phase-03 handoff artefact, which is one of the main ways hunt programs compound value over time.
What is the minimum viable ABLE-style hypothesis?
Actor + Behavior + Location + Evidence. TaHiTI does not use the ABLE acronym explicitly, but its five hypothesis characteristics translate directly. Actor = who might be doing this. Behavior = what specific action to look for. Location = where in the environment. Evidence = what specific data row would confirm. If your hypothesis omits any dimension, refine before adding to the backlog.
What if the initial hypothesis turns out to be wrong at execution time?
Refine it. Phase 02 Step 3 exists specifically for this reason. The initial hypothesis is a placeholder that gets refined when the abstract is pulled for execution. If refinement reveals the hypothesis is unrecoverable (untestable, too broad, based on aged-out intelligence), retire the abstract and open a fresh one with a corrected trigger source. Do not force a bad hypothesis through execution.
How do I convince leadership the investment in Phase 1 pays off?
Metric: hypothesis confirmation rate. A hunt program with disciplined Phase-1 gatekeeping (5/5 characteristics enforced) typically runs at 25-45% confirmation rate. A program with weak Phase-1 gatekeeping runs at 5-15%. Same hunter-hours, 3-4x the yield. That is the ROI story: better hypotheses at creation time = more confirmed findings per hunt = more detection content shipped per quarter.
Where does this leave threat intelligence in the picture?
Threat intelligence is the major trigger source per TaHiTI, and it flows into every phase — feeding initial hypothesis creation (Phase 1), enriching abstracts with actor context (Phase 2 Step 3), providing context for finding interpretation (Phase 2 Step 4), and receiving new intelligence generated by hunts as handoff (Phase 3). If threat intelligence does not touch your hunts at three specific points — you are running searches, not TaHiTI.
Where can I access this week’s threat-intelligence feed operationally?
The HuntIntel operator console exposes every IOC with category attribution, ATT&CK technique, severity, confidence, and source provenance pre-joined. Open at huntintel.hackforlab.com/login.html. For the specific dataset the three worked examples above are drawn from, see the Weekly Threat Advisory · Jul 27 – Aug 2, 2026.
Part 1 covered the framework end-to-end and a hunt-program walkthrough. This is Part 2. New parts publish weekly — the topic queue includes hunt-execution mechanics, Phase-3 handoff engineering, and case-study collections built from live threat intelligence.
