The Pyramid of Pain — Why Operational Patterns Matter

Where most detection portfolios spend their effort

David Bianco introduced the Pyramid of Pain in 2013 to illustrate a simple economic relationship: different types of indicators cost different amounts for attackers to change. The pyramid has six levels, from trivially changeable at the bottom (hash values) to operationally expensive at the top (TTPs). The concept is well known. The application is not.

Most detection portfolios are bottom-heavy. Threat intelligence platforms ingest vendor feeds, extract IOCs, and push them into the SIEM as watchlists and analytics rules. When a hash, IP, or domain from the feed appears in your environment, an alert fires. This process is real detection. It catches known-bad infrastructure and known malicious binaries. It's also the most perishable detection work your team does.

The lifespan of a bottom-level indicator is measured in hours to days. A hash value changes when the attacker recompiles with one byte modified or repacks with a different packer. An IP address changes when the attacker provisions a new VPS through an automated API. A domain changes when the attacker registers through a bulk registrar that sells aged domains for a few dollars each. The detection effort is genuine, but the detection window is narrow. By the time an IOC reaches your feed, the campaign that used it may have already rotated.

The 2025 SANS Cyber Threat Intelligence Survey found that 84% of organizations use MITRE ATT&CK for threat hunting. But most of that usage focuses on mapping known IOCs to techniques for enrichment rather than building detections at the technique and TTP levels. The framework is used as a labeling taxonomy, not as a detection engineering blueprint.

The six levels and what they cost

The pyramid is an economic model. Each level represents a class of indicator, and each level carries a different cost for the attacker to change.

Hash values cost nothing to change. Recompile the binary, change one byte, use a different packer. The output is a completely different hash. Hash-based detection is necessary for catching automated or lazy attacks, but it catches only the exact binary you have a hash for. Every variant is invisible.

IP addresses cost slightly more. New VPS instances require provisioning and configuration, but cloud providers offer APIs that automate the process in minutes. Bulletproof hosting providers sell pre-provisioned infrastructure specifically for this purpose. An attacker with a credit card and a script can rotate IPs faster than your feed can update.

Domain names cost more than IPs because effective domains need DNS propagation, reputation aging, and sometimes SSL certificates. But bulk domain registration is cheap, and domain generation algorithms automate the creation of thousands of domains programmatically. Some ransomware families have been observed using DGAs that generate over 10,000 unique domains per day.

Network and host artifacts start to inflict real cost. These include things like User-Agent strings, named pipes, registry keys, file paths, and service names. Changing them requires modifying the tool's configuration or code, testing the changes against target environments, and verifying that the modifications don't break functionality. This takes hours to days of engineering effort rather than seconds of automation.

Tools are expensive to change. A custom C2 framework represents months of development: implant coding, protocol design, evasion engineering, operator training. Switching frameworks means retraining operators, rebuilding infrastructure templates, and re-testing against target defensive stacks. Groups that invest in custom tooling don't abandon it casually.

TTPs are the most expensive to change because they're embedded in operational workflow, not in code. The sequence in which an attacker chains techniques, the timing between phases, the credential strategies they employ, the lateral movement patterns they follow: these are practiced behaviors that represent institutional knowledge. Changing TTPs means rethinking how the group operates from the ground up. Most groups don't. They adjust individual techniques and tools while the operational pattern persists.

What TTP-level detection looks like

The distinction between technique-level and TTP-level detection is the difference between detecting a single action and detecting the pattern that connects actions across systems and time.

Technique-level detection identifies a specific attacker behavior regardless of the tool used. "Alert when any process opens a handle to lsass.exe with access rights 0x1010" detects LSASS credential dumping whether the attacker uses Mimikatz, comsvcs.dll, or a custom dumping tool. This is valuable. It survives tool changes. It sits in the middle of the pyramid.

TTP-level detection correlates multiple technique-level events across systems and time windows to identify the operational pattern. This is what campaign detection requires, and it's what most organizations don't build.

This course teaches TTP-level detection on top of technique-level detection. Your Purple Teaming Sigma rules catch individual techniques. Your campaign correlation rules catch the operational patterns that connect them.

Summiting the Pyramid: measuring detection robustness

MITRE Engenuity's Center for Threat-Informed Defense formalized the operational intuition behind the Pyramid of Pain with its Summiting the Pyramid (STP) methodology. Released in 2023 and updated to v3.0 in May 2025, STP provides a scoring model that quantifies how robust a detection analytic is against adversary evasion.

The scoring model evaluates each observable in a detection rule against a five-level scale. At the bottom are application-layer observables like command-line arguments and file names. These are easy for attackers to change because they control the application-layer inputs. At the top are core technique behaviors: the invariant actions that any implementation of a technique must perform, regardless of tooling. An LSASS credential dump must open a handle to the LSASS process. That handle-open is an invariant behavior. No tool can dump LSASS without it.

The v3.0 release introduced a separate network traffic model alongside the host-based model, recognizing that robustness works differently across data sources. It also addressed ambiguous techniques, behaviors that look identical whether performed by an attacker or a legitimate administrator. The methodology provides guidance for building filters that distinguish malicious from benign without reducing robustness.

The practical implication: when you write a detection rule, you can score each observable in the rule against the STP model. A rule built entirely on application-layer observables (specific command-line strings, specific file paths) scores low because the attacker controls those strings. A rule built on invariant technique behaviors (handle operations, registry key creation patterns, network protocol structures) scores high because the attacker can't change those behaviors without implementing an entirely different technique.

The Sigma analytics repository now includes an STP flag for scoring the robustness of community-contributed rules. This means you can evaluate your existing Sigma ruleset against the scoring model to identify which rules are fragile (bottom of pyramid, easily evaded) and which are durable (top of pyramid, require the attacker to redesign their approach).

The detection investment equation

Your detection engineering time is finite. Every hour spent writing and maintaining rules is an hour not spent on something else. The Pyramid of Pain provides the investment logic: spend the most engineering effort on detections that impose the most cost on the attacker.

This doesn't mean abandoning IOC-level detection. Hash-based and IP-based watchlists should be automated, not hand-crafted. They catch lazy attacks and commodity malware, and they cost almost nothing to maintain when fed by automated threat intelligence pipelines. Automate the bottom. Engineer the top.

The middle of the pyramid is where technique-level rules live. These require genuine detection engineering: understanding the technique, identifying the telemetry that captures it, writing the query that distinguishes it from legitimate behavior, and tuning the rule for your environment. Most mature SOCs have built technique-level rules for their highest-priority ATT&CK techniques. A rule detecting scheduled task creation via registry key monitoring is more durable than a rule matching a specific schtasks.exe command-line string, because the attacker can change the command-line arguments but cannot avoid creating the registry key.

The top of the pyramid is where campaign-correlation rules live, and it's where most organizations have a gap. These rules require a different kind of engineering: correlating events across multiple data sources, defining time windows that match operational tempo, and identifying the behavioral sequence that characterizes the campaign pattern rather than the individual technique.

Building TTP-level rules also forces you to answer a harder question: what does the attacker's operational workflow look like end to end? You can't correlate events into a campaign pattern unless you understand the sequence of decisions the attacker makes. That understanding comes from offensive thinking, from knowing why the attacker moves from credential access to lateral movement to persistence in a specific order and on a specific timeline. This is what the remaining modules teach.