Pyramid of Pain Guide: Prioritising Indicators That Cost Attackers Most

The Pyramid of Pain is a model, published by David J. Bianco in 2013, that ranks six types of threat indicator by how much difficulty, or "pain", you cause an attacker when you detect and respond to each one. In plain terms: blocking a file hash costs the attacker almost nothing, while detecting the way they work forces them to change their behaviour, which is slow and expensive. Most security teams still spend most of their effort at the bottom of the pyramid, ingesting feeds of hashes, IP addresses and domains. This guide explains the six levels, why behaviour-based detection hurts attackers most, how to apply the model to threat intelligence and detection engineering with MITRE ATT&CK, and how it applies to stolen tokens and machine credentials. It is for SOC analysts, detection engineers and threat intelligence teams.

Key takeaways

• Pain is set by indicator type. Bianco's point is that the cost you impose on an adversary depends on the types of indicator you are able to use, not on how many you collect.
• The bottom three levels are cheap to change. Hashes, IP addresses and domains rotate in minutes to days, so they are best for retrospective hunting and blocking known infrastructure, not for lasting detection.
• TTPs sit at the top for a reason. Detecting behaviour, such as Pass-the-Hash seen in Windows logs, means the attacker must learn new behaviour rather than swap a file or server.
• ATT&CK is the vocabulary for the top level. Techniques such as T1550.001 Application Access Token describe behaviour you can turn into durable detections.
• Stolen machine credentials need behavioural detection. A valid token used from new infrastructure has no malicious hash at all; only behaviour reveals it.

What it is

Bianco posted the model on his blog, Enterprise Detection & Response, on 1 March 2013, and updated it on 17 January 2014 to add hash values as the bottom level. He wrote it after the Mandiant APT1 report of February 2013, observing that most public discussion focused on the report's list of domains while the tool artefacts in its Appendix A received little attention. His conclusion was that most organisations were not using intelligence effectively, because they used the indicators that are easiest for the adversary to change.

The model is a way of asking two questions of every piece of intelligence or every detection: what does this let me detect, and where does it sit on the pyramid? The higher it sits, the more it costs the adversary to evade. Bianco also stressed that the entire point of detecting indicators is to respond to them; a detection nobody acts on causes no pain at all.

How it works

The six levels

Bianco's own examples show the climb. A recon tool with a distinctive user-agent string is a network artefact: block it and the attacker must work out why and change the tool. Pass-the-Hash, by contrast, can be detected from Windows logs regardless of which tool performs it, so it is detection at the TTP level (ATT&CK T1550.002 Pass the Hash).

Applying it to an intelligence report

1. Extract every indicator from the report or feed and tag it with its pyramid level.
2. Load the bottom three levels with an expiry: push hashes, IPs and domains to blocklists and retro-hunts with a time to live, typically days to weeks for IPs, and record the source.
3. Turn artefacts into signatures: user agents, URI patterns and registry paths become Sigma or EDR rules. See the Sigma Rules Guide.
4. Turn tools into family-level detections: YARA rules on code traits shared across a family, not one sample. See the YARA Rules Guide.
5. Map behaviours to ATT&CK techniques and check whether you already detect each one; any gap becomes a detection engineering backlog item.
6. Test before enabling: run new behavioural rules in alert-only mode against 30 days of history, measure false positives, then promote. Keep the previous rule version so you can roll back.

Mapping levels to ATT&CK and detection work

Coverage is not the same as depth. MITRE's Center for Threat-Informed Defense runs the Summiting the Pyramid project to measure detection quality beyond an ATT&CK heatmap: how many distinct ways of performing a technique an analytic can see, and how robust and precise its signals are. That is the Pyramid of Pain applied to individual analytics. See the MITRE ATT&CK Coverage Mapping Guide.

Why it matters

Feeds of atomic indicators are cheap to ingest and easy to count, so they dominate many programmes. The pyramid explains why that produces a steady stream of alerts but little lasting effect. It gives SOC and threat intelligence leads a defensible way to move effort upwards, and the Detection Engineering Guide covers how to build and maintain the resulting rules.

Decision guidance

• Small SOC or managed service customer: automate the bottom three levels from one or two trusted feeds with expiry, and spend analyst time on a short list of high-value behaviours such as credential theft, token abuse and remote execution.
• Large SOC with detection engineers: track the share of rules at each level, and require that every new intelligence requirement produces at least one TTP-level analytic.
• During an active incident: low-level indicators are still valuable for scoping and containment, because they are specific and fast. Use them first, then write behavioural rules so the attacker cannot simply return with new infrastructure.

Measuring progress

• Detection mix: percentage of active rules at artefact, tool and TTP level versus atomic indicators.
• Indicator half-life: median days before an ingested IP or domain stops producing true positives, which justifies your expiry policy.
• Technique coverage with depth: priority ATT&CK techniques with at least one tested behavioural analytic.
• Re-detection after infrastructure change: in purple team or red team exercises, whether detection survives when the tester changes hashes, IPs and domains.
• False positive rate per behavioural rule after tuning, to show the higher-level rules are sustainable.

Where identity fits

Credential and token abuse is the clearest case for the top of the pyramid. When an attacker uses a stolen API key, OAuth token or cloud access key, there is no malware, no malicious hash and often a fresh IP address. In the Salesloft Drift breach in August 2025, stolen OAuth tokens for a trusted integration were used through Tor and anonymising proxies. Published indicators included the user agent Salesforce-Multi-Org-Fetcher/1.0, an artefact the actor could change at will. The durable signals were behavioural: count queries against Account, Opportunity, User and Case objects followed by bulk export, then searches of the stolen data for strings such as AWS access keys beginning "AKIA".

These detections depend on knowing what each machine identity normally does, which is why an inventory with owners and expected behaviour is a detection prerequisite. See the OAuth Token Theft Incident Playbook.

Common misconceptions

• "Low-level indicators are useless": they are precise and fast. They are poor as a long-term defence, not as an incident response tool.
• "More indicators means better intelligence": a feed of a million IP addresses sits entirely on the second level. Volume says nothing about pain.
• "Mapping a rule to an ATT&CK technique makes it TTP level": a rule tagged T1003.001 that matches one tool's file name is still a tool or artefact detection. What matters is what the rule actually keys on.
• "Behavioural detection is too noisy": untuned behavioural rules are noisy. Scoping them to the identities, hosts and parent processes where the behaviour is abnormal is the work of detection engineering.
• "The pyramid ranks threats": it ranks indicator types by cost to the adversary. It does not say which threat actor or technique matters most to you; your intelligence requirements do that.

Related concepts

• Indicators of compromise and indicators of attack: roughly, the lower levels hold compromise evidence and the upper levels describe attack behaviour. See the Indicators of Compromise vs Indicators of Attack Guide.
• Cyber Kill Chain and Diamond Model: other analytical models often taught alongside the pyramid. See the Cyber Kill Chain and Diamond Model Guide.
• Threat intelligence levels: strategic, operational, tactical and technical intelligence map loosely onto how high on the pyramid a product sits. See the Threat Intelligence Guide.
• STIX and TAXII: the formats used to exchange indicators and, increasingly, attack patterns. See the STIX and TAXII Guide.
• Threat hunting: hypothesis-led hunts at the TTP level often produce the next generation of detections. See the Threat Hunting Guide.

Framework mapping

Practitioner checklist

• Tag every indicator and every detection rule with its pyramid level.
• Set expiry on IP and domain indicators and measure their real half-life.
• Convert intelligence reports into ATT&CK-mapped behaviours, not just blocklists.
• Check what each ATT&CK-tagged rule actually matches on, and re-level it honestly.
• Test behavioural rules in alert-only mode against historical data before enabling them.
• Baseline normal behaviour for service principals, API keys and OAuth clients so token abuse stands out.
• Prove in exercises that detections survive a change of hashes, IPs and domains.
• Report the detection mix by level to SOC leadership each quarter.

Standards and references

• David J. Bianco, Enterprise Detection & Response: The Pyramid of Pain
• MITRE ATT&CK: Application Access Token
• MITRE ATT&CK: Pass the Hash
• MITRE ATT&CK: Steal Application Access Token
• MITRE Center for Threat-Informed Defense: Summiting the Pyramid
• SigmaHQ: Rules
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Detection Engineering Guide · Threat Intelligence Guide · Indicators of Compromise vs Indicators of Attack Guide · MITRE ATT&CK Guide for Defenders