CTI Foundations: Part 2 - The Threat Intelligence Pyramid

Pyramid of Pain Focus: Not all indicators have equal defensive value. Understanding which indicators are cheap for attackers to change and which are expensive fundamentally reshapes how you allocate detection effort.

TL;DR: The Pyramid of Pain, published by David Bianco in 2013, remains the most useful framework for prioritizing detection investment. Lower layers (hashes, IPs, domains) are trivial for attackers to change. Upper layers (TTPs) are profoundly expensive. Mature detection strategies combine fast IOC-based blocking with high-fidelity behavioral detection based on techniques rather than indicators.

Why the Pyramid Matters

Not all indicators are equal. Some are trivially cheap for attackers to change. Others are profoundly expensive. A defensive program that optimizes for the cheap indicators spends enormous effort on things that produce minimal friction for the adversary. A program that can operate at the upper levels of the pyramid forces attackers to change the way they fundamentally operate, and that costs them time, money, and operational risk.

David Bianco published this framework in 2013. Over a decade later, it remains the single most useful conceptual framework in threat intelligence. The reason it has aged so well is that it describes something fundamental about adversary economics, not something about a specific tool or technique that might go obsolete.

The pyramid has five layers, each representing a category of indicators. Each layer up represents a higher cost for the attacker to change. Understanding where your program invests its effort determines how resilient your defenses actually are.

Note on layer count: The original Bianco framework describes six layers, treating IP addresses and domain names as separate tiers. We consolidate them here into a single "Infrastructure" layer because they share nearly identical evasion economics. Both rotate within hours using automated provisioning pipelines.

Level 1: Hash Values - The Trivia Layer

A cryptographic hash (MD5, SHA-1, SHA-256) is a fingerprint of a specific file. If you have the hash of a malicious executable, you can detect that exact file on any system. Simple, fast, automatable. The appeal is obvious.

The problem is equally obvious: changing a hash requires changing one byte of the file. One byte. Attackers routinely repack, recompile, or lightly modify their tools to produce a different hash while maintaining identical functionality. Tools like UPX (T1027.002: Software Packing), a common packer, will produce a different hash on each run with different settings.

When the LockBit 3.0 builder leaked in September 2022, security researchers documented dozens of distinct variants being distributed within weeks. Each had a unique hash. Each was functionally identical to the others. Blocking the original hash did nothing against the variants.

The same dynamic played out when Emotet returned in November 2021, ten months after Europol's coordinated infrastructure takedown. Within 72 hours of resuming operations, researchers at ESET and Checkpoint documented multiple distinct binary variants circulating simultaneously. Each packed differently. Each with a unique hash. The behavioral chain, macro-enabled document to VBA dropper to DLL loader, was unchanged. Defenders who had built hash-based blocklists from the January 2021 takedown were starting from zero. Defenders who had built behavioral detections on the execution chain caught the first wave without writing a single new rule.

This was not an edge case. It is the rule. Every time a public YARA signature or hash blocklist appears, the commodity actor pipeline produces new variants before incident responders have even read the advisory.

Hashes are still worth collecting. They are useful for confirming attribution when you suspect a known malware family. They provide rapid initial triage of suspicious files. They enable retrohunting across historical telemetry to identify past compromises. But never treat hash coverage as security coverage. Hash-level detection has a half-life measured in hours at most.

Beyond Standard Hashing

Beyond simple file hashes, specialized hashing techniques survive basic evasion attempts. Imphash (import hash) hashes the import table structure rather than the full binary, surviving basic repackers and simple mutations. Ssdeep generates a fuzzy hash that can identify files that are similar but not identical, useful for detecting slight variants of the same tool. TLSH (Trend Micro Locality-Sensitive Hash) improves on ssdeep by providing a more stable similarity score across larger modifications.

These techniques are more resilient than simple hashing, but the principle remains: determined attackers change their files regularly, and hash-based detection decays rapidly.

Level 2: IP Addresses and Domains - Fast-Rotating Infrastructure

A command-and-control (C2) IP address or a phishing domain is slightly more painful to change than a hash, but not by much. Infrastructure costs money and takes time to set up and validate, but attackers operating at any meaningful scale have automated provisioning pipelines. A threat actor can spin up a new VPS (T1583: Acquire Infrastructure), register a new domain, update their implant configuration, and be back online within hours.

The average lifespan of a C2 domain for commodity malware is measured in days. Feodo Tracker data on Emotet's 2021-2022 operational period showed median C2 host lifespans under 72 hours before rotation or takedown. Nation-state actors who value operational security maintain infrastructure longer, but they do rotate when burned. The infrastructure rotation cycle is dramatically faster than the cycle required to change tradecraft.

The intelligence value of an IP or domain is not in the indicator itself. It is in the pivoting it enables. If you find a C2 IP, you can look at its historical DNS records, find other domains that resolved to it, find other IPs those domains resolved to, and start mapping an adversary's infrastructure footprint. That footprint, though temporary, is far more durable than any single indicator.

Infrastructure Pivoting Workflow

Starting from a suspicious IP, the pivoting workflow unfolds in stages. First, use passive DNS to identify which domains have resolved to that IP by querying SecurityTrails, DNSDB, or RiskIQ. Next, check Shodan to determine what services are running and examine the certificate Subject Alternative Names (SANs), which often reveal co-hosted infrastructure. Then check VirusTotal to see which files communicated with the IP by reviewing the Relations tab for linked samples and URLs. Finally, cross-reference abuse feeds like abuse.ch, AbuseIPDB, and Feodo Tracker to understand the infrastructure's history and reputation.

A single IP becomes the seed of an infrastructure map. That map, when maintained over weeks rather than hours, outlasts the IP and can be extended to identify related infrastructure that has not yet rotated.

Infrastructure maps reveal the full operational footprint. Even when individual components rotate, the patterns of infrastructure relationships persist. Understanding how infrastructure connects teaches you how to anticipate what else might be part of the same campaign.

Level 3: Network and Host Artifacts - Behavioral Signatures

At this level, we move from pure infrastructure to behavioral signatures. Network artifacts are patterns in traffic: a specific HTTP User-Agent string (T1071.001), a particular URI structure, a distinctive TLS fingerprint (JARM), a packet timing pattern. Host artifacts are file paths, registry keys (T1547: Boot/Logon Autostart), mutex names, named pipes. These are the traces a tool leaves behind on a system it runs on.

These are harder to change because they are often baked into how a tool is built. A C2 framework's default configuration might use a specific User-Agent and URI structure for HTTP beaconing. Changing these requires modifying the framework configuration, recompiling, and retesting. That is more work than rotating an IP, and work that scales poorly across a large operational footprint.

Cobalt Strike: A Case Study in Artifacts

Cobalt Strike provides a useful case study. Default Cobalt Strike beacons are detectable via JARM fingerprinting and specific HTTP response patterns. When operators fail to customize the malleable C2 profile, their infrastructure lights up in Shodan queries for specific default response characteristics. The artifact, the specific HTTP response pattern, is more durable than the infrastructure indicator. Some nation-state operators have run Cobalt Strike on the same certificate across entire regional campaigns because customization requires more effort than infrastructure rotation.

The JARM fingerprint for a default Cobalt Strike listener (07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1) has appeared in Shodan scans reliably enough that it is now a standard hunting query. Operators who failed to customize their TLS configuration essentially labeled their infrastructure. The Conti ransomware group, whose internal communications leaked in February 2022, provides a documented case: Conti affiliates were using default Cobalt Strike profiles across hundreds of intrusions. The leaked chat logs confirmed operators were aware of the detection risk but prioritized speed of deployment over profile customization. Defenders running JARM-based Shodan queries had already mapped significant portions of their active infrastructure.

Host-Level Artifacts

Host artifacts follow the same logic. Emotet consistently used a mutex derived from a hash of the infected system's volume serial number, producing a victim-unique but structurally patterned mutex name. This behavior was documented across Emotet's operational history from 2014 through its 2022 resurgence in ESET and Checkpoint analyses. Defenders who wrote detection logic around the mutex naming pattern rather than specific mutex values caught every iteration of the malware, including variants with entirely new hashes and infrastructure. Malware families consistently leave similar host-level traces because those traces reflect design decisions, not configuration. Changing them requires rewriting the code, not rotating a domain.

The practical implication is significant: when analyzing a malware sample, document every host and network artifact observed. These become the seeds for YARA rules and Sigma detections that remain valid long after the original IOCs have rotated. A single artifact-driven detection rule can identify variants and related samples that share the same behavioral signature even when every infrastructure indicator has changed.

Level 4: Tools - Malware Families and Frameworks

Tools are the software an adversary uses to accomplish their objectives: Cobalt Strike, Metasploit, Mimikatz, custom loaders, specific remote access trojans (RATs). Detecting tool usage is significantly more valuable than detecting infrastructure, because an actor's toolset changes slowly. Developing, testing, and operationalizing a new tool is expensive. Rotating an IP is free.

When you identify that an attacker is using a specific tool, you immediately know its full capability set, its typical usage patterns, and the detection opportunities it creates. If you know an actor uses Mimikatz for credential harvesting (T1003.001: LSASS Memory), you can deploy detections for every known Mimikatz technique across your environment, even before you have observed any activity specific to your organization.

The tool layer is also where malware families live. Knowing that a sample belongs to the Qakbot family tells you its persistence mechanism, its network communication protocol, its lateral movement behavior, and the threat actors known to deploy it. That is significant intelligence derived from a single attribution data point.

The Qakbot case demonstrates exactly how durable this intelligence is. Operation Duck Hunt in August 2023, a coordinated FBI action, disrupted Qakbot's infrastructure entirely and redirected approximately 700,000 infected machines away from operator-controlled servers. By December 2023, Cisco Talos observed fresh Qakbot distribution campaigns. The delivery mechanism was thread hijacking, exactly as before. The execution chain was DLL-based C2 registration via regsvr32, exactly as before. The post-compromise lateral movement used VNC, exactly as before. The infrastructure was entirely new. Every hash was different. The behavioral signatures defenders had built from years of Qakbot analysis caught the resurrection without modification.

The Limits of Tool-Level Detection

Nation-state actors with access to large development resources build custom tools specifically to avoid being detected by signatures for known frameworks. The documented case is APT29's 2020 COVID-19 vaccine research targeting campaign. Rather than use Cobalt Strike or Metasploit and risk triggering the signatures that most mature security programs had deployed, APT29 used two previously unknown custom frameworks: WELLMESS and WELLMAIL. Both were designed to blend with legitimate TLS traffic and had no existing detection signatures. A joint advisory from NCSC, CSE, NSA, and CISA in July 2020 confirmed the targeting and the tooling. Organizations that had spent months tuning Cobalt Strike detections were fully exposed to an actor that simply chose not to use Cobalt Strike.

Commodity actors operating at scale rarely invest in custom tooling. They continue using Metasploit or Cobalt Strike because the economics favor it. Detection at the tool layer is most effective against this long tail.

Custom tools remain a detection challenge because each requires bespoke analysis. YARA and memory forensics can often identify novel tools through behavioral or structural characteristics even when no public signatures exist, but that analysis takes time — time the defender does not have if the tool is already executing in the environment.

Level 5: TTPs - The Hardest Layer to Change

TTPs (Tactics, Techniques, and Procedures) are how an adversary accomplishes their objectives, independent of which specific tool they use or which infrastructure they run on. They answer the "how", not the "what."

The DOJ's September 2020 indictment of five APT41 members provides a documented measure of TTP persistence. Investigators traced the same behavioral signature across intrusions spanning 2012 to 2020 — eight years of activity across more than 100 victims in multiple countries. The specific pattern: spearphishing with malicious attachments (T1566.001) for initial access, DLL sideloading via their DUSTPAN loader (T1574.002) for execution, and living-off-the-land binaries (T1218) for lateral movement. Infrastructure had rotated completely across those eight years. Tools had been recompiled dozens of times. Hashes were unrecognizable from one campaign to the next. The behavioral fingerprint was, by the DOJ's own evidentiary record, identical.

To change those TTPs, APT41 would need to fundamentally retrain their operators, retool their operational pipeline, and rebuild their tradecraft. That is a multi-month undertaking involving coordination across global teams, validation in test environments, and operational risk during the transition. That is not a weekend rotation.

The timeline above shows this in concrete terms. Same campaign, same adversary, same objectives: hash values rotated 31 times over 12 months. Infrastructure rotated 12 times. TTPs rotated zero times. Detection built on TTPs survived every rotation. Detection built on hashes was obsolete before the ink dried on the first blocklist.

MITRE ATT&CK maps TTPs systematically. When you can attribute a technique (T1566.001: Spearphishing Attachment, T1574.002: DLL Side-Loading), you gain access to all the existing detection logic the community has built around that technique. You can build detection that persists across campaign rotations and infrastructure changes.

Real-World Campaign: TA551 (Shathak)

Proofpoint tracked TA551, also known as Shathak, across 2021-2023 and documented the same behavioral chain repeating across entirely different infrastructure rotations. The group ran new domains and IPs with every campaign wave, repackaged their loaders regularly, and still produced the same end-to-end attack sequence every time. The table below maps what defenders observed at each pyramid layer.

The same group. The same campaign objectives. Dozens of distinct hashes. Continuously rotating infrastructure. One behavioral chain that never changed. Defenders who built detections on the thread-hijacking delivery pattern and the IcedID-to-Cobalt Strike execution sequence caught every wave. Defenders who relied on domain blocklists rebuilt their defenses from scratch with each rotation.

Investment Strategy: Where to Allocate Detection Effort

Understanding the pyramid informs how to allocate detection effort for maximum defensive return. Most organizations get this backwards.

Lower Layers: IOC Sharing

Share IOCs aggressively at the bottom of the pyramid. Indicator sharing (hashes, IPs, domains) costs little to produce and provides immediate blocking value for other organizations facing the same threat. MISP was built for exactly this use case. Push fresh IOCs to sharing communities, ingest what others share, and automate the exchange through standardized feeds.

IOC sharing is high-volume and low-friction. It is your first line of defense but not your last.

Middle Layers: Behavioral Detection

Network and host artifacts should receive substantial analytical investment. These turn into YARA rules and Sigma detections that protect regardless of infrastructure rotation. Every analyst hour spent building a solid YARA rule from a real sample pays dividends across future campaigns from the same family. Sigma detection rules based on behavioral artifacts persist across tool version changes and infrastructure migrations.

This is where IOCs become intelligence. The artifacts are durable because they reflect how tools are actually built, not just where infrastructure happens to sit.

Upper Layers: TTP Hunting

TTP-based threat hunting is the most sustainable and resilient detection strategy. Instead of looking for specific indicators, you look for behaviors that match known adversary playbooks. A hunt query that searches for execution of PowerShell with obfuscation followed by credential dumping will catch new tools and new infrastructure as long as the adversary maintains that behavioral pattern.

TTP hunting requires more analytical sophistication. It is also the hardest for attackers to defeat.

The Pyramid Inversion Problem

The pyramid does not suggest ignoring lower levels. It suggests understanding their limitations and calibrating investment accordingly. Many organizations fall into the trap of pyramid inversion: they automate massive amounts of IOC collection and dissemination while leaving their TTP-level detection capabilities underdeveloped.

The result is a program that can identify a threat actor's presence only after infrastructure has burned or a detection has already fired. By contrast, a program with mature TTP-based detection can identify threat actor activity proactively, before obvious indicators become available to the broader community.

The inverted model is not the expensive one. It is the effective one. And the talent required to run it, analysts who can translate ATT&CK techniques into hunt queries, is far more leveraged than an analyst whose primary job is updating blocklists.

Using the Pyramid as a Planning Tool

When planning a CTI program, use the pyramid to structure your work. For each relevant threat actor, map their documented TTPs from MITRE ATT&CK. Then assess your current detection coverage at each pyramid level. The gap is your roadmap.

A CISO planning detection investment should see the pyramid as an argument for rebalancing resources. Most organizations spend 80% of detection budget on hash-based signatures and 20% on behavioral detection. Reverse that allocation. Hash-based detection provides fast triage but minimal defensive friction. Behavioral detection provides friction that meaningfully constrains adversary operations.

The pyramid also explains why MITRE ATT&CK has become so critical to modern security operations. It is the public, standardized, and crowdsourced documentation of exactly what sits at the top layer of the pyramid. An organization that uses ATT&CK to guide detection engineering gains access to years of distributed analytical effort on the hardest layer to detect.

Conclusion

The Pyramid of Pain is not a ranking of indicator types. It is a ranking of attacker pain. The pain gets worse as you move up the pyramid because changing behavior is harder than changing infrastructure. This fundamental truth about adversary economics has not changed in thirteen years and will not change in the next thirteen.

Building defensive capabilities around this truth forces adversaries to make difficult choices: innovate faster, invest more in tooling, retrain operators, or accept lower operational tempo. Every one of those options is expensive compared to rotating an IP address.

The best detection programs stack all five layers. They share IOCs for fast blocking. They build behavioral detections for persistence. They hunt for TTPs proactively. They do not mistake activity at any single layer for comprehensive coverage. Instead, they recognize that a mature defense operates across all layers, with investment proportional to the pain each layer inflicts on the attacker.

What's Next

In Part 3, we will move to practical reconnaissance methodology: passive OSINT techniques, pivoting workflows using free tools like Shodan and VirusTotal, and how to organize your findings. The pyramid tells you what to look for and how to prioritize. OSINT tells you how to find it.

References & Further Reading

1. Pyramid of Pain by David Bianco. https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html The original framework. Read this first. Understanding the original reasoning provides context for all modern applications of the pyramid.

2. MITRE ATT&CK Framework. https://attack.mitre.org Use this to understand the TTP layer in depth. Each technique page includes documented examples from real campaigns and references to the intelligence source.

3. Shodan Search Engine. https://www.shodan.io Use this to understand infrastructure artifacts and identify host-level behavioral signatures. Free accounts provide sufficient query budget for initial investigations.

4. YARA: Malware Research and Detection. https://virustotal.github.io/yara/ Use this to translate host and network artifacts into detection rules that persist across file hash changes.

5. Sigma Rule Repository. https://github.com/SigmaHQ/sigma Community-maintained detection rules mapped to ATT&CK techniques. These are pre-built rules implementing behavioral detection at the TTP level.

6. abuse.ch Threat Sharing. https://abuse.ch/ Community repository for IOC sharing focused on specific malware families and botnets. Useful for infrastructure-level threat hunting.

7. JARM Fingerprinting. https://github.com/salesforce/jarm Understanding TLS fingerprinting as a behavioral artifact. JARM provides a method to identify infrastructure based on TLS response patterns rather than specific IPs.

8. OWASP ModSecurity Core Rule Set. https://owasp.org/www-project-modsecurity-core-rule-set/ A reference for detection rule structure and layered defensive logic, applicable to understanding how behavioral rules are composed across multiple indicator types.