The Pyramid of Pain Explained: Why Your Hash Feeds Aren't Enough

One diagram, one uncomfortable question

In 2013, David Bianco published a simple triangle that has aged better than almost anything else in threat intelligence. The Pyramid of Pain ranks indicator types not by how easy they are for you to collect, but by how much it costs the adversary when you detect and respond to them.

The uncomfortable question it forces: if your detection program runs almost entirely on hash and IP blocklists, how much pain are you actually inflicting? For most attackers, the answer is close to zero. Rotating a hash is a recompile. Rotating an IP is an API call to a hosting provider. Changing how they operate is a retraining problem, and that is where the pyramid points.

The six levels, bottom to top

Level 1: Hash values

An MD5 or SHA-256 identifies exactly one byte sequence. Flip a single bit, append a null byte, rebuild with a different timestamp: new hash, same malware. Automated build pipelines give many families a unique hash per victim, which means the hash you ingested from a feed may never appear anywhere else on Earth.

Hashes are still useful. They are precise, they never false-positive on the wrong file, and they are perfect for confirming "is this exact known sample present?" during an investigation. Just be clear about what they are: retrospective confirmation, not forward-looking detection.

Level 2: IP addresses

Attackers rent infrastructure like everyone else. Cloud providers, VPS resellers, compromised routers, residential proxy networks: a burned IP is replaced in minutes and costs cents. Worse, IPs are shared. Blocking an address that fronts a CDN or shared hosting will break legitimate traffic and erode trust in your blocklists.

IP indicators decay in hours to weeks. If your feed has no first-seen and last-seen timestamps, treat every entry as expired until proven otherwise.

Level 3: Domain names

Domains cost a few dollars and a registration form, so they are only slightly harder to rotate than IPs. But they carry more signal: registration patterns, name server choices, and resolution history all leave traces an analyst can pivot on. A domain also has to exist before the attack for phishing to work, which creates a detection window that IPs rarely offer.

Domains hurt more than IPs, but a determined adversary with a DGA (domain generation algorithm) or a stack of pre-registered lookalikes shrugs them off.

Level 4: Network and host artifacts

This is where detection starts to bite. Artifacts are the side effects of the adversary's tooling and habits: a distinctive user-agent string, a URI pattern in C2 traffic, a registry key used for persistence, a mutex name, a scheduled task called GoogleUpdateTaskMachineCore with a typo, a specific pipe name.

Changing these requires modifying tools and re-testing them. Not a rewrite, but real friction. When you alert on the artifact rather than the infrastructure, the attacker has to notice what you detected, figure out which behavior produced it, and engineer it out. That takes days, not minutes.

Level 5: Tools

Detect the tool itself and the adversary has to find or build a replacement. If your environment reliably catches Mimikatz in all its recompiled, obfuscated, in-memory forms, the attacker must move to a different credential theft technique entirely, retrain operators, and accept new operational risk.

This is the natural home of YARA: good rules target the invariants of a tool family (code structure, configuration blocks, unique capabilities) rather than one build's hash. One well-written rule can neutralize hundreds of future samples. If you want to practice, the workbench at hunt.mlab.sh lets you author and validate YARA rules in the browser.

Level 6: TTPs

Tactics, techniques, and procedures sit at the top because they describe the adversary's behavior, independent of any tool. Credential dumping via LSASS access. Lateral movement over SMB with stolen admin credentials. Persistence through scheduled tasks. Exfiltration over cloud storage APIs.

Detect behavior and there is nowhere left to rotate to. An actor who relies on LSASS dumping cannot trivially stop needing credentials. Forcing a change at this level means forcing the adversary to re-plan their entire operation, and some will simply move on to a softer target. That is the maximum pain the pyramid describes.

Why everyone still lives at the bottom

If TTPs are so effective, why do most detection programs run on hashes and IPs? Because the pyramid of pain is also, implicitly, a pyramid of effort for defenders:

• Low levels are machine-readable. A hash feed drops into a SIEM lookup with zero engineering. A TTP detection requires understanding the technique, knowing your telemetry, writing logic, and tuning out admin noise.
• Low levels have vendors. You can buy indicator feeds by the million. Nobody sells you a finished, tuned behavioral detection for your environment, because it does not exist until you build it.
• Low levels look productive. "We ingested 2 million IOCs this quarter" is an easy slide. "We wrote nine behavioral detections" sounds smaller, even when it catches more intrusions.

The pyramid does not say the bottom is worthless. It says the bottom is insufficient, and that your effort distribution should not be inversely proportional to impact.

Climbing the pyramid in practice

You do not climb by abandoning IOCs. You climb by changing what you do with each intrusion and each intel report.

1. Extract more than the appendix. When a vendor report lands, most teams grab the IOC table and stop. The valuable content is in the narrative: which techniques, in what order, with what tooling. Map those to MITRE ATT&CK technique IDs and ask "would we see this?" for each one.

2. Turn incidents into artifacts and TTPs. After every incident, list what you observed at each pyramid level. The hashes go into retro-hunts. The URI patterns, named pipes, and registry keys become artifact detections. The techniques become Sigma rules and hunt hypotheses.

3. Write tool-level signatures. For any tool you see twice, invest in a YARA rule targeting its invariants instead of its hash. Test against known variants, not just the sample you have.

4. Build behavioral detections for the techniques that matter to you. Not all 600+ ATT&CK techniques. Start with the ones used by actors that target your sector; the profiles on actors.mlab.sh map named groups to their known techniques and CVEs, which makes prioritization concrete rather than speculative.

5. Keep the bottom levels cheap. Automate IOC ingestion, enrichment, and expiration so they consume near-zero analyst time. A lookup on mlab.sh or its API answers "is this indicator known-bad?" in seconds; that question should never occupy a human for ten minutes.

Restructuring the detection budget

A rough allocation that reflects the pyramid instead of fighting it:

The exact numbers matter less than the direction: human effort concentrated at the top, automation handling the bottom.

One warning as you climb: false-positive pressure rises with altitude. A hash never fires on the wrong file; a behavioral rule for "scheduled task creation" fires on every sysadmin. Higher-level detections need baselining, tuning, and enrichment context. That is the price of hurting the adversary, and it is worth paying.

Every indicator you detect asks the adversary a question: "how much will it cost you to come back?" Make the answer expensive.