OD0.3 The Pyramid of Pain — Why Operational Patterns Matter

Operational Objective

Your threat intelligence feed delivers hundreds of IOCs per week. Your detection rules catch specific hashes, domains, and IP addresses. When the attacker changes infrastructure — which takes hours — your detections are worthless. Meanwhile, the attacker's operational patterns — how they chain techniques, how they time their movements, how they structure their infrastructure — stay consistent across campaigns.

Most detection engineering effort targets the bottom of the pyramid: the indicators the attacker can rotate with minimal effort. Campaign detection targets the top: the operational patterns embedded in tradecraft that persist across infrastructure rotations, tool changes, and campaign restarts. This sub connects the Pyramid of Pain to detection engineering investment and shows you what detection at each level actually looks like in your SIEM.

Learning Objectives

By the end of this sub you will be able to:

• Classify any detection rule by pyramid level (IOC, technique, or TTP) based on what it matches and what the attacker would need to change to evade it. This matters because most environments run 60–80% IOC-level rules — quantifying the imbalance is the first step toward fixing it.

• Explain the economic logic behind the pyramid — why each level costs the attacker progressively more to change — using the same framework that Mandiant uses to track threat group persistence across campaigns in their annual M-Trends report. This matters because detection investment should follow attacker economics: spend the most effort on detections that are the most expensive to evade.

• Write a TTP-level detection rule description that catches a multi-step operational pattern (not an individual technique or indicator) and explain why it survives infrastructure rotation, tool changes, and technique substitution. This matters because TTP-level detection is the capability gap between SOCs that catch individual alerts and SOCs that detect campaigns.

The bottom of the pyramid is where IOC feeds live

Most threat intelligence consumption happens at the bottom three levels. The detections are real but disposable.

Your threat intel platform ingests feeds from multiple vendors, extracts IOCs, and pushes them into your SIEM as watchlists, blocklists, or analytics rules. When a hash, IP, or domain from the feed appears in your environment, an alert fires.

This works — for the specific indicators in the feed. The problem is lifespan. A hash value changes when the attacker recompiles the binary with one byte modified. An IP address changes when the attacker spins up a new VPS. A domain changes when the attacker registers a new one through an automated registrar.

The detection effort at the bottom of the pyramid is real but disposable. You're building detections against the most temporary part of the attacker's operation. The moment they rotate infrastructure — which they do routinely — your detections are inert.

The top of the pyramid is where campaigns live

TTPs are expensive to change because they're embedded in tradecraft, not in infrastructure.

TTPs — tactics, techniques, and procedures — are at the top because they're expensive for the attacker to change. Not expensive in money. Expensive in tradecraft development time, operational testing, and capability engineering.

An attacker group that uses AiTM credential phishing as their primary initial access method has invested months in developing their phishing kit, testing it against various security stacks, refining the proxy infrastructure, and training operators. Switching to a fundamentally different initial access method requires a different skill set, different tooling, different infrastructure, and different operational procedures. The switch isn't impossible, but it's expensive in time and effort.

Campaign-level patterns are even more persistent than individual techniques. The sequence in which an attacker chains techniques, the timing between phases, the infrastructure architecture they use, the credential strategies they employ — these are operational habits that persist across campaigns, across infrastructure rotations, and across individual tool changes.

What TTP-level detection looks like in practice

Three examples at three pyramid levels — same attack, different detection durability.

IOC-level detection (bottom): "Alert when any process communicates with IP address 198.51.100.47." This detects one campaign, one infrastructure setup, one time. When the attacker rotates to 198.51.100.48, the detection is dead.

Technique-level detection (middle): "Alert when any process opens a handle to lsass.exe with access rights 0x1010." This detects LSASS credential dumping regardless of the tool used. It survives tool changes. Purple Teaming teaches this level.

TTP-level detection (top): "Alert when the same user identity produces a credential-access event followed by a new authentication from a different source IP within 4 hours, followed by persistence installation on the authenticated system within 2 hours." This detects the credential-harvest → replay → persist campaign pattern regardless of which credential technique, which authentication method, and which persistence mechanism the attacker uses. It survives tool changes, technique changes, and infrastructure rotations.

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

The economics of attacker adaptation

Every level of the pyramid has a cost to the attacker for changing. Your detection investment should follow the economics.

Hash values cost nothing to change. Recompile the binary, change one byte, repack with a different packer. Zero effort. Hash-based detection is necessary (it catches lazy or automated attacks) but insufficient (it catches nothing else).

Infrastructure costs something to change. New domains need registration and aging. New VPS instances need provisioning. New certificates need procurement. But these are commodity operations — most attacker groups automate them. Days to weeks of effort, mostly automated.

Tools cost more. Developing a custom C2 implant takes weeks to months. Switching C2 frameworks requires retraining operators, re-testing payloads, and re-building infrastructure templates. But it happens — especially when a framework becomes heavily signatured.

TTPs cost the most. Changing how you operate — your sequencing, your timing, your decision logic, your credential strategy, your movement patterns — requires fundamentally rethinking your operational workflow. Groups that invest years in refining their tradecraft don't abandon it because a defender wrote a detection rule. They adjust individual techniques but keep the operational pattern.

Your detection engineering investment should follow the economics: spend the most effort on detections that are the most expensive for the attacker to evade.

STEP 1 — Export your rule list
   In Sentinel:
     Go to Microsoft Sentinel → Analytics → Active rules
     Note the total count of enabled rules.

   In Splunk:
     Go to Settings → Searches, reports, and alerts
     Filter to "Enabled" alerts only.

STEP 2 — Sample 30 rules across categories
   If you have more than 100 rules, sample 30 rules spread across
   different rule categories (threat intel match, behavioral,
   anomaly, scheduled query). If fewer than 100, classify all of them.

STEP 3 — Classify each rule
   For each rule, read the detection logic and assign one level:

   IOC — The rule matches a specific hash, IP, domain, or URL.
         Test: "Would this rule still fire if the attacker changed
         all their infrastructure?" If NO → IOC level.

   TECHNIQUE — The rule matches a behavioral pattern: process
         relationships, command-line arguments, registry modifications,
         file operations. Test: "Would this rule fire regardless of
         which tool the attacker used?" If YES → technique level.

   TTP — The rule correlates multiple events across systems or time
         windows to detect an operational pattern. Test: "Does this
         rule require events from 2+ log sources or a time-window
         correlation?" If YES → TTP level.

STEP 4 — Calculate the distribution
   Count rules at each level. Calculate percentages.
   Typical finding: 60-80% IOC, 15-30% technique, 0-5% TTP.

STEP 5 — Document the gap
   Write one sentence: "Our detection portfolio is [X]% IOC-level,
   [Y]% technique-level, [Z]% TTP-level. The campaign detection gap
   is [100-Z]% of our rules provide no campaign-level visibility."