From Behaviour to Indicators: Extracting and Judging IOCs
What is it?
An indicator of compromise (IOC) is an observable that betrays the malware elsewhere: a file hash, a domain or IP, a file path, a mutex, a registry key, or a behavioural pattern. Extracting IOCs turns one detonation into a net you can cast across the whole estate. The Pyramid of Pain ranks indicators by how much it costs the attacker to change them — from a trivially swapped hash to the tools and behaviours they cannot easily abandon.
Why it matters
A verdict on one machine is worth little if the same malware is on twenty others. IOCs are how you scope an incident. But not all indicators are equal: block a hash and the attacker recompiles in seconds; detect a behaviour and you force them to change their whole tradecraft. Knowing which indicators to hunt with — and which will drown you in false positives — is the difference between scoping an incident and paralysing the business.
Where you see it
IOCs are read out of the same detonation report — hashes and paths from the file activity, domains and IPs from the network activity, registry keys and mutexes from the host activity — and then matched against SIEM, EDR and proxy logs across the estate to find every other affected host.
What normal looks like
A well-chosen IOC is specific to the threat: a full malicious domain, a mutex the family always creates, a distinctive persistence path. Matched across the estate it lights up only truly affected hosts, giving a clean scope.
What suspicious looks like
A badly-chosen IOC is over-broad and shared with legitimate use: the IP of a large shared CDN, a common Windows path, a generic user-agent. Hunting on it floods you with false positives and can trigger harmful blocks — a self-inflicted incident. Over-broad indicators are as dangerous as missing ones.
How analysts investigate
Extract every observable from the report, then rank them on the Pyramid of Pain. Prefer durable, specific indicators (behaviours, tooling, distinctive artefacts) to hunt broadly, and use brittle ones (hashes, single IPs) only for exact confirmation. Before hunting on any indicator, ask what legitimate activity also matches it — and discard the ones that would cause false positives.
Common beginner mistakes
- Hunting only on the file hash — the attacker changes it on the next build and the hunt goes blind.
- Blocking an over-broad indicator (a shared CDN IP) and taking down legitimate services.
- Extracting indicators without asking what benign activity also matches them.
What you will be able to do
- Extract IOCs of every type from a detonation report.
- Rank indicators on the Pyramid of Pain by cost-to-change.
- Reject over-broad indicators that would cause false positives.
One infected host is a finding; twenty is an incident, and you cannot tell which you have until you scope. IOCs are the scoping tool: pull every observable from the report and match it across the estate. But choosing which indicator to hunt on is a judgement — and the Pyramid of Pain is how you make it.
Pyramid of Pain (cost to the attacker to change)
^ hardest to change
/ TTPs & behaviour \ <- hunt broadly here
/ tools / tooling \
/ host & network artefacts \
/ domain names \
/ IP addresses \
/ file hashes \ <- confirm only
v trivial to changeStep by step: (1) list every observable — hash, dropped path, Run key, mutex, domain, IP, and the behaviours themselves; (2) place each on the pyramid; (3) for each candidate, ask 'what legitimate activity also matches this?'; (4) hunt broadly on the durable, specific ones and keep the brittle ones for exact confirmation.
Worked example — which IOC do you hunt with?
| Candidate IOC | Pyramid tier | Also matches… |
|---|---|---|
| File hash of the sample | Bottom (trivial) | Nothing — but changes next build |
| 104.18.x.x (shared CDN IP) | Low | Thousands of legitimate sites |
| Mutex the family always creates | Artefact (durable) | Only this malware family |
Before reading on, decide which of the three to hunt on. The answer: the mutex. The hash is specific but brittle — it finds today's build and misses tomorrow's, so it is for confirmation only. The shared CDN IP is a trap: hunting or blocking on it hits thousands of legitimate sites, a self-inflicted outage. The mutex is both durable and specific — the family creates it every time and nothing benign shares it, so it lights up exactly the affected hosts. High on the pyramid and low on false positives is what you want.
Recap
- IOCs turn one detonation into an estate-wide scope of the incident.
- The Pyramid of Pain ranks indicators by cost-to-change — hunt high, confirm low.
- Reject over-broad indicators; they cause false positives and harmful blocks.
Sign in to save your progress on the server.