From intelligence to detection and threat hunting

The clearest way a CTI function proves its value is by changing what the organisation can detect. That requires producing something detection engineering and hunters can actually build on.

The Pyramid of Pain

David Bianco's 2013 model ranks indicator types by how much it costs the adversary when you deny them. It is the reference for deciding what to spend effort on.

Level	Cost to adversary	Durability of your detection
Hash values	Trivial — recompile	Hours
IP addresses	Easy — rotate	Days
Domain names	Simple — register more	Days to weeks
Network / host artefacts	Annoying — requires tooling changes	Weeks to months
Tools	Challenging — retool or rebuild	Months
TTPs	Hard — change how they operate	Months to years

The practical reading is not "ignore the bottom". Atomic indicators are cheap to deploy and worth blocking. It is that your analytical effort should go where the adversary's cost is highest, and that a product consisting only of hashes and IPs has produced almost no lasting defensive value.

Writing a hunt hypothesis

A hypothesis is testable and scoped. "Look for APT activity" is neither.

Hypothesis: An intrusion set using this technique would establish persistence via a scheduled task executing a script interpreter from a user-writable directory. If true, we would see scheduled task creation events on endpoints where the task action references %APPDATA%, %TEMP% or %PUBLIC%. Data required: task-creation telemetry from EDR, 90-day retention. Expected benign volume: moderate — software updaters do this; filterable by signature and parent process.

That structure — hypothesis, expected observable, data required, expected noise — is what a hunter needs and what interviewers listen for. The last element matters most: an analyst who has never thought about false positives has never shipped a detection.

The hunt loop

Derive the hypothesis from intelligence — a TTP from reporting or your own analysis.
Check you have the telemetry. If not, the output of the hunt is a visibility gap finding, which is a legitimate and valuable result.
Query broadly, then filter. Characterise the benign population before hunting the malicious one.
Whatever the outcome, produce something durable: a detection, a documented gap, or a tuned baseline.
Feed the result back into collection requirements — this is the Exploit–Analyse–Disseminate half of F3EAD.

A hunt that finds nothing is not a failed hunt

It either raises confidence that a technique is not present, or reveals you could not have seen it. Both are reportable findings. An analyst who says "we found nothing, so we documented the coverage we now have and the two log sources we lack" is giving the right answer.

Handing off well

What detection engineering actually needs from intelligence:

The behaviour described precisely, not just the ATT&CK ID. A technique ID is a label; the procedure is the buildable detail.
The specific observable — process, command line, registry path, network pattern.
The data source and whether the organisation has it.
Known benign causes and how to filter them.
Priority grounded in the threat model, not in what was interesting to research.
Where possible, a draft rule. Sigma is the usual portable format.

The reverse handoff matters too: detections that fire teach you about the environment and should update your assessments. Teams where intelligence writes and never hears back are producing reports, not intelligence.

Practise detection and hunting questions.