What is the Pyramid of Pain?

The Pyramid of Pain is the invention of security professional David J Bianco, who came up with it in 2013. Essentially, the Pyramid of Pain demonstrates that some indicators of a compromise are more troubling to adversaries than others. This is because when those indicators are denied to an attacker, the loss of some will be more painful to them than the loss of others. This is what the Pyramid of Pain looks like:

Pyramid of pain

What are the Indicators in the Pyramid of Pain?

As outlined by David J Bianco himself, the Pyramid indicators are:

  1. Hash values: SHA1, MD5, or other similar hashes that correspond to specific suspicious or malicious files. Hash values are often used to provide unique references to specific samples of malware or to files involved in an intrusion
  2. IP addresses: As the name suggests, but also includes netblocks
  3. Domain names: A domain name itself, or sub domains
  4. Network Artifacts: Adversaries’ network activities that are observable. Typical examples include URI patterns, C2 information embedded in network protocols, distinctive HTTP User-Agent, or SMTP Mailer values, etc.
  5. Host Artifacts: Observables caused by adversary activities on one or more of your hosts, such as registry keys or values known to be created by specific pieces of malware, files, or directories
  6. Tools: Software used by attackers to accomplish their mission. This includes utilities designed to create malicious documents for spear phishing, backdoors used to establish C2 or password crackers, or other host-based utilities
  7. Tactics, Techniques and Procedures (TTPs): How the adversary goes about accomplishing their mission, from reconnaissance all the way through data exfiltration and at every step in between

How Does the Pyramid of Pain Work?

The Pyramid of Pain provides a useful reference for network defenders in enterprises.

For instance, the Pyramid tells us that if an attacker is using malware to infect an endpoint within their attack chain, a defender will know that they’ll need to use more than file hash values to detect such behavior. This is because it is “trivial” for attackers to get around the technique (they can simply recompile the malware sample so that the file hash value the defender used to detect the original sample is rendered useless).

Similarly, if a defender’s network security controls use IP address, CIDR block, or even ASN range blacklists to disrupt malicious network communication, the Pyramid suggests they may still be in trouble as these controls are “easy” to circumvent (in this case, the attacker could simply move their command-and-control infrastructure or operations center to another network server).

What Does the Pyramid of Pain Tell Us?

Ultimately, the Pyramid shows that nearly all indicators have a transitory value that fades over time. The exception is attacker TTPs. So, if a defender focuses on detecting or preventing attacker behavior (as, for example, defined in the MITRE ATT&CK® framework of common threats) rather than basic artifacts, then they make life more costly and more painful for an attacker.

The Pyramid of Pain therefore provides an ascending priority list of indicators against which security controls should be applied. Each level provides an opportunity for defenders to detect and prevent various indicators of attack. For example, hash values, IP addresses, and domains are accessible via micro threat intelligence feeds like AT&T’s  Alien Labs® Open Threat Exchange® (OTX™) or commercial threat intelligence feeds. It’s also possible to find network and host artifacts as observables within micro threat intelligence feeds.

However, only the most resilient security programs will incorporate the ability to detect and prevent TTPs and procedures, which describe and help predict future attacker behavior. Attacker TTPs can be consumed through strategic threat intelligence reports, feeds such as STIX/STIX2 and frameworks like MITRE ATT&CK.

Once you have detection and prevention capabilities in place for each level of The Pyramid of Pain, it’s critical to validate your security capabilities by emulating attacker activities at each level and proving true security efficacy, a process made exponentially easier through automation.

How can you use the Pyramid of Pain to Validate Security Controls?

Each level of the pyramid can be used to emulate indicators of attack and validate your security controls in the following way:

Indicators of Attack How to Emulate Attacker Activities and Validate Security Controls
Hash values
  • Retrieve malware sample based on file hash value
  • Pass malware sample through network from one endpoint to another endpoint
  • Use integrations into security stack to measure prevention and detection technologies for gaps and evidence of true positives
IP addresses
  • Emulate connection to destination host IP address, e.g., 6.6.6.6
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps and evidence of true positives or error that IP address is not accessible
Domain names
  • Emulate connection to destination network host domain name, e.g., badguy.com
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps and evidence of true positives or error that IP address is not accessible
Network artifacts
  • Emulate observables related to the content of various traffic protocols including exact C&C protocol to destination network resource including URI patterns, C2 information embedded in network protocols, distinctive HTTP User-Agent, or SMTP Mailer values, etc.
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps and evidence of true positives or error that destination network resource is down
Host artifacts
  • Emulate specific observables on one or more endpoint/host devices including changes to registry keys or values known to be created by specific pieces of malware, files or directories dropped in certain places or using certain names, names or descriptions or malicious services, or almost anything else that’s distinctive
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps or evidence of true positives
Tools
  • Emulate software adversary uses to accomplish their mission, e.g., Tor, Windows Task Scheduler, GCC, Powershell, etc. The software itself might not be directly malicious, but the specific use, time or location might be indicative of malicious or at least suspicious
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps or evidence of true positives
TTPs
  • Emulate single or multi-phase attack tactics, techniques and procedures that replicate a pattern of behavior, e.g., “Spear phishing with a trojaned PDF file” or “… with a link to a malicious .SCR file disguised as a ZIP” or “Dumping cached authentication credentials and reusing them in Pass-the-Hash attacks”
  • Use analytics from emulation and integrations into security stack to measure prevention and detection technologies for gaps or evidence of true positives that artifacts have been detected for each phase of the attack chain