Pyramid of Pain Explained with Real Detections

Not all indicators of compromise are equal. Blocking an IP address annoys an attacker for about five minutes. Detecting how they move through your network can cost them weeks. The Pyramid of Pain is the simplest model for explaining that difference, and it changes how you write detections.

This is Part 7 of 30 in the Blue Team Learning Path. In Part 6 we learned the ATT&CK vocabulary. Now we learn which detections are worth your time.

Key takeaways

• The Pyramid of Pain ranks indicator types by how much it hurts the attacker when you detect them.
• Hashes, IPs and domains are cheap for attackers to change. Tools and TTPs are not.
• Use low-level indicators for fast triage and high-level behaviours for durable detections.
• Every detection you write should answer: what would the attacker have to change to avoid this?

Where the Pyramid of Pain comes from

Security researcher David Bianco published the model in March 2013 in his post The Pyramid of Pain. Its idea is simple. When you deny the adversary an indicator, they have to respond. How much effort that costs them is the “pain”. Climb the pyramid and the pain grows, but so does the difficulty of detecting the indicator in the first place.

The six levels, from bottom to top

1. Hash values

A hash such as SHA-256 identifies one exact file. It is very precise, with almost no false positives, but changing a single byte produces a new hash. Attackers recompile or repack malware constantly, so a hash blocklist is trivial to evade.

2. IP addresses

Blocking an address or range stops that connection. Attackers rent new infrastructure or hide behind proxies and cloud services, so this is the easiest indicator for them to change. Blocking shared cloud addresses can also break legitimate traffic.

3. Domain names

Domains are slightly harder to replace because they must be registered and pointed somewhere. Still, many attackers buy domains in bulk, and automated domain generation makes blocklists a losing race.

4. Network and host artifacts

Artifacts are traces that separate attacker activity from normal use: an unusual User-Agent string, a specific named pipe, a registry key, a file dropped in a distinctive path. Detecting these forces the attacker to change how their tooling behaves, which takes real work.

5. Tools

If you can reliably detect the attacker’s software, they must find or build a replacement. Detection here usually combines several traits of the tool rather than a single hash, for example its default behaviours and artifacts.

6. TTPs

Tactics, techniques and procedures describe the behaviour itself, such as credential dumping or Pass-the-Hash. To avoid a TTP detection, the attacker has to change how they operate. That is the most expensive thing to ask of them, and it is why ATT&CK techniques are the natural home of high-value detections.

The same attack at every level

Take one scenario: an attacker uses a remote access tool to run commands on a workstation. Here is how a defender might detect it at each level.

• Hash: block the SHA-256 of the dropped executable. The attacker rebuilds it and the rule is useless.
• IP: block the command server address. The attacker moves to a new server.
• Domain: block the domain. The attacker registers another one.
• Artifact: alert on the named pipe or registry key the tool always creates. The attacker has to modify the tool.
• Tool: alert on the tool’s behaviour pattern, such as its parent process chain. The attacker needs a different tool.
• TTP: alert on the behaviour, for example an Office document spawning a script interpreter that then creates a new service. Any tool that does the same job triggers it.

The bottom three rules took minutes to write and will expire fast. The top rule took longer and keeps working.

A real detection at the TTP level

Here is a behaviour-based check for suspicious parent and child processes. It needs process creation logging, event 4688 with command-line auditing, as described by Microsoft. Sysmon event 1 gives richer detail and we cover it in Parts 11 and 12.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-1)} |
  Where-Object { $_.Message -match 'WINWORD.EXE' -and $_.Message -match 'powershell.exe|cmd.exe|wscript.exe' } |
  Select-Object TimeCreated, Id -First 20

It is crude, and it will need tuning against your normal software, but it detects a behaviour rather than a file. Any malware family that abuses Word to launch a shell triggers it. Technique T1059.001 on the ATT&CK site describes the PowerShell side of this.

What you need to log for each level

The higher you climb, the richer the telemetry you need. This is the part many teams skip, and it explains why their detections stay at the bottom of the pyramid.

• Hashes: file hashing from your EDR or from Sysmon. The Sysmon documentation lists the hash algorithms it can record.
• IPs and domains: firewall, proxy and DNS logs.
• Artifacts: registry, file creation and named pipe events, plus HTTP headers from a proxy or network sensor.
• Tools: process creation with full command lines and parent process, and loaded modules.
• TTPs: all of the above, correlated over time, plus authentication logs.

If you only collect firewall logs, the bottom of the pyramid is all you can reach. Improving what you log is often a better investment than writing more rules.

Case study: from IOC to behaviour

Suppose a threat report gives you five IP addresses and three file hashes from a phishing campaign. A junior analyst loads them into the SIEM and moves on. A stronger analyst asks what the intruders had to do on the victim machine: open an attachment, launch a script, reach out to the internet, and create something that survives a reboot.

Each step suggests a detection that no feed contains. The attachment opening a scripting engine is a process-chain rule. The outbound call from a script host is a network rule. The persistence step is a service or scheduled task creation rule, for example the techniques T1543.003 and T1053.005 on the ATT&CK site. Three rules, none tied to a single hash, all of them still useful when the next campaign arrives with new infrastructure.

That is the real lesson of the pyramid. Treat a threat report as a story about behaviour that happens to include some indicators, not as a list of indicators that happens to include some story.

Using the pyramid in daily SOC work

• Triage: hashes, IPs and domains are fast to check against threat intelligence and fast to block. Use them to contain an incident quickly, as the NIST incident handling guide suggests for containment.
• Detection engineering: invest your writing time at the artifact, tool and TTP levels. Part 17 goes deeper.
• Reporting: when you share findings, list indicators at every level so other teams can pick what fits their tooling.
• Phishing response: sender domains and URLs are low in the pyramid, while the lure technique is high. See our phishing guide.

Why not just ignore the bottom of the pyramid?

Because it is cheap and precise. A hash match gives a near-certain answer, and an IP blocklist stops lazy scanning. The pyramid does not say low-level indicators are bad. It says they should not be your only defence. Think of them as the quick lock on the door, with behaviour detection as the alarm system.

How the pyramid fits with the other parts of the path

The pyramid is a decision tool you will reuse in nearly every later post. When we build Sysmon rules in Part 11, you will ask which level each rule sits at. When we write Sigma rules in Part 16, the best examples describe behaviour, not strings. When we hunt in Part 21, the hypotheses start at the top of the pyramid because that is where attackers are least able to adapt.

It also helps with communication. Telling a manager “we blocked 400 IPs” sounds impressive, but it says nothing about resilience. Telling them “we now detect the persistence technique that three relevant threat groups use” is a statement about the attacker’s cost, and it is much easier to defend in a budget meeting. Keep a simple table of your detections by pyramid level, update it each month, and watch the balance move upward.

Finally, remember that the pyramid describes cost to the attacker, not the importance of an alert. A single hash hit on a domain controller is still an emergency. Use the model to shape your long-term detection strategy, and use your judgement on the alert in front of you.

Common pitfalls

• Building an IOC feed and calling it detection. Feeds expire fast and miss anything new.
• Writing TTP rules that are too broad. A behaviour rule that fires hundreds of times a day gets ignored.
• Forgetting the telemetry. A TTP detection needs process, command-line and authentication logs. See our Windows event logs guide.
• Confusing pain with difficulty. Top-level detections are harder to build and test, so plan time for tuning and for lab validation.
• Never expiring indicators. Add a review date to every low-level IOC you block.

A short exercise

Take the last three alerts your team closed. For each one, write down which level of the pyramid the detection sat at, and what the attacker would change to avoid it. If every answer is “a hash” or “an IP”, you have found your next project: lift one of those detections up to the artifact or behaviour level, and test it in your lab.

Frequently asked questions