Your threat intel feed just delivered 400 new file hashes. You load them into the EDR blocklist and the dashboard shows the gap as closed. Meanwhile, the attacker behind those hashes has already recompiled the payload, and every one of those 400 entries now protects you from a file nobody will ever send you again.
David Bianco’s Pyramid of Pain explains why this keeps happening. It doesn’t rank indicators by how useful they are to you. It ranks them by how much it costs the attacker when you detect them. My argument is that a SOC should spend most of its engineering effort near the top of the pyramid. The bottom still has its uses, and I’ll be fair about what those are.
The pyramid, bottom to top
Each level is harder for the adversary to change than the one below it. When you deny them a hash, they lose seconds. When you deny them a technique, they have to learn a new way to do the job.
| Level | Worked example | What the attacker does to evade | Their cost |
|---|---|---|---|
| Hash | SHA-256 of a loader DLL | Recompiles it or changes one byte | Seconds |
| IP address | C2 server on a rented VPS | Rents another VPS or routes through a CDN | Minutes |
| Domain | Lookalike domain used for phishing | Registers a new cheap domain | Minutes to hours |
| Network/host artifact | Distinctive URI path or named-pipe pattern in a C2 profile | Rewrites the profile and retests | Hours |
| Tool | A known credential-dumping utility | Switches tools or builds a custom one | Days |
| TTP | Reading LSASS memory to steal credentials | Finds a different way to get credentials | Weeks, or gives up |
One worked example per level
Hashes. A hash identifies one exact file. Change any byte and you get a completely different hash, so a match tells you that you’ve seen that exact file and nothing more. Its value is in retro-hunting: searching historical telemetry to find out whether that file ever ran in your environment.
IP addresses. You block the C2 IP. The operator moves to new infrastructure or puts their traffic behind shared hosting, and if you block that shared IP you may break legitimate traffic too. IP blocks decay quickly and carry a risk of collateral damage.
Domains. Blocking one domain does little. Detection rules about domains as a category last longer: newly registered domains, domains that almost no one in your organisation visits, or names that look algorithmically generated. That’s the first step from matching an indicator to recognising a pattern.
Network and host artifacts. This is where things start to hurt the attacker. Examples include a C2 framework’s default URI structure, an odd User-Agent string, or a named-pipe naming convention. Changing these means editing the configuration and testing again. Many operators never bother, so default artifacts stay useful for longer than you’d expect.
Tools. You don’t detect a tool by its hash. You detect what’s characteristic about it: imphash, YARA rules on embedded strings, command-line argument patterns. To get past that, the attacker has to switch tools or write their own.
TTPs. Credential dumping from LSASS (MITRE ATT&CK T1003.001) is the classic example. Drop the question of which tool was used and ask what has to happen for the technique to work: a process has to open a handle to lsass.exe with memory-read access. That’s true whichever tool does it.
A rule built that way catches tools you’ve never seen, renamed binaries, and living-off-the-land methods such as abusing a built-in DLL’s minidump export, because all of them end up doing the same thing to the same process.
The fair case for indicators
People who defend IOCs have real points, and you should take them seriously:
- Precision. A hash match almost never produces a false positive. A behavioural rule on LSASS access will fire on backup agents, antivirus products and crash handlers until you tune it.
- Speed and cost. You can deploy a blocklist in minutes. A good TTP detection needs the right telemetry, a baseline of normal activity, and ongoing upkeep.
- Scoping. Once an incident is underway, indicators are the fastest way to answer “where else is this?”
- Sharing. Indicators are easy to pass between organisations. Behavioural logic usually isn’t.
The pyramid doesn’t tell you to throw indicators away. It tells you not to treat them as your detection strategy.
| Use it for | Indicators (bottom) | Behaviours (top) |
|---|---|---|
| Incident scoping | Strong | Supporting |
| Detecting unknown threats | Weak | Strong |
| Day-one alert fidelity | High | Needs tuning |
| How long the detection stays useful | Days | Months to years |
| Telemetry needed | Basic logs | Process, handle, command-line data |
Moving a detection up the pyramid
You can practise this with any indicator alert. Each time you go up a level, ask “what has to be true for this to work?”
When you get to the technique, write the rule there and treat the lower-level indicators as enrichment for that rule, not as the rule itself.
What to learn from this
- Treat IOCs as scoping tools, not as your defence. Load them for retro-hunts and triage, and give them an expiry date.
- Ask what must be true for the attack to succeed. That question takes you from a hash to a behaviour that every variant of the attack shares.
- Collect telemetry before you write rules. Behavioural detection needs process creation, command-line and process-access data. Without it, you can’t work at the top of the pyramid.
- Budget for tuning. A TTP rule that’s noisy on day one is normal. Baseline the legitimate activity, write exclusions, and then promote the rule.
- Measure attacker cost, not blocklist size. The useful question is how long it would take an attacker to get around a rule, not how many indicators you blocked this week.