Pyramid of Pain to Production: How Detection Engineers Prioritize What to Hunt

TL;DR: Hunt TTPs, Not Hashes

Prioritize detections at the TTP and behavioral layers of the Pyramid of Pain. Hashes, IPs, and domains expire in hours—attackers rotate them for free. Behaviors are expensive to change: when your detection fires on how an adversary operates rather than what they touch, you force them to burn time, money, and operational risk retooling. That’s the entire strategic argument for behavior-first detection engineering.

The Pyramid of Pain, Refresher and Why It Matters

David Bianco introduced the Pyramid of Pain in 2013 while at Mandiant, and more than a decade later it remains the most useful mental model for prioritizing detection work. The concept is simple: rank adversary indicators by how much pain—cost and disruption—blocking them inflicts on the attacker. From bottom to top:

• Hash values — File hashes change with a single byte modification. Trivially defeated, worthless beyond point-in-time blocking.
• IP addresses — Cheap to rotate via cloud providers, CDNs, or fast-flux networks. Attackers burn IPs faster than you can block them.
• Domain names — Slightly more costly (registration, DNS infrastructure), but domain generation algorithms (DGA) and bulletproof hosts make rotation routine.
• Network artifacts — URI patterns, User-Agent strings, C2 beacon jitter. Requires the adversary to modify tooling, not just infrastructure.
• Tools — Mimikatz, Cobalt Strike, Rclone. Blocking or detecting tools forces the adversary to find or build alternatives, which costs development time and introduces new operational risk.
• TTPs — The top of the pyramid. Behaviors like process injection, credential dumping, or living-off-the-land execution. Changing TTPs means changing tradecraft—retraining operators, rewriting tooling, accepting new failure modes.

The pain-cost tradeoff is the point. The bottom of the pyramid is cheap for you to implement (a hash blocklist takes minutes) and cheap for the attacker to evade. The top is expensive for both sides—but the investment compounds. A behavioral detection stays relevant across campaigns, tooling shifts, and infrastructure rotation. An IOC feed is stale the day you import it.

This is why behavioral detections outlast indicator-based ones: infrastructure is disposable, tradecraft is not. An attacker can register a new domain in five minutes; rewriting a post-exploitation chain to avoid a well-tuned process-injection detection can take weeks and may break operational tooling they’ve invested in.

Mapping Pyramid Levels to MITRE ATT&CK Data Sources

MITRE ATT&CK gives you the vocabulary for the top of the pyramid and—critically—the data sources you need to detect it. Each ATT&CK technique documents the data sources and data components that make detection possible. Mapping pyramid levels to telemetry:

• Hashes/IPs/domains — File metadata, network traffic flow. Feeds and blocklists; minimal engineering required.
• Network artifacts — Network traffic content (packet captures, Zeek logs, TLS fingerprints like JA3/JA3S).
• Tools — Process creation, module loads, file events, Windows registry modifications. Sysmon and EDR telemetry live here.
• TTPs — Cross-cutting correlation: process↔process relationships, command execution patterns, API call sequences. Requires detection logic, not just collection.

Practical implication: if your roadmap targets the top of the pyramid, your collection strategy must prioritize process telemetry, network connection logs, and authentication events—the raw material ATT&CK detections are built from.

Step 1: Inventory Your Telemetry Before You Prioritize

You cannot prioritize detections against telemetry you haven’t inventoried. Before writing a single rule, answer: what do we actually collect, and is it complete?

For Windows environments, audit your Sysmon configuration against the SwiftOnSecurity baseline and confirm coverage of:

• Event ID 1 (process creation with command line) — non-negotiable baseline
• Event ID 3 (network connection) — with process attribution
• Event ID 7 (image loaded) — for injection and DLL-side-loading detection
• Event ID 8 / 10 (CreateRemoteThread, process access) — direct T1055 signals
• Event ID 11, 13 (file creation, registry modification)

Verify your EDR vendor’s event parity. CrowdStrike, Microsoft Defender for Endpoint, and Sentinel One all expose equivalent process, network, and module events—but field names, retention windows, and default-on status differ. Query retention explicitly:

# Elastic example: confirm process event volume and retention
GET logs-endpoint.events.process-*/_search
{
  "query": { "range": { "@timestamp": { "gte": "now-30d" } } },
  "aggs": { "per_day": { "date_histogram": { "field": "@timestamp", "calendar_interval": "day" } } }
}

Then hunt blind spots: no DNS logs? No authentication events from domain controllers? No PowerShell script-block logging (Event ID 4104)? Those gaps cap your achievable ATT&CK coverage before you write any logic.

Step 2: Score Threat Activity by Pain Level and ATT&CK Coverage

With telemetry inventoried, prioritize with a simple rubric. For each candidate technique, score three dimensions:

1. Adversary frequency — How often is this technique observed in the wild? Use the ATT&CK technique data, CISA’s Known Exploited Vulnerabilities Catalog, and vendor threat reports (Mandiant, Microsoft, Red Canary’s annual Threat Detection Report).
2. Telemetry availability — Do you currently collect the required data sources? Score high/medium/low.
3. Detection difficulty — Is the technique behaviorally distinctive (high signal) or noisy (low signal)? Credential dumping via LSASS access is distinctive; T1059 PowerShell execution is noisy.

A technique used constantly by ransomware crews, backed by telemetry you already collect, with a distinctive behavioral signature is your top priority. That scoring exercise typically surfaces 15–25 techniques that deliver 80% of your realistic coverage value.

Step 3: From ATT&CK Technique to Detection Logic

Take T1055 – Process Injection as a worked example. ATT&CK lists its data sources: process access, process modification, OS API execution. A high-signal behavioral rule targets OpenProcess with PROCESS_VM_WRITE/PROCESS_CREATE_THREAD rights followed by remote thread creation into an unexpected target.

Sigma rule (abridged):

title: Potential Process Injection via CreateRemoteThread
status: experimental
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 8
        filter_main_image:
            SourceImage|endswith: 'windowssystem32'
    condition: selection and not filter_main_image
tags:
    - attack.defense_evasion
    - attack.t1055
falsepositives:
    - Legitimate debugging and security tooling
level: high

Or Elastic EQL for a behavior chain:

sequence by process.entity_id
  [process where event.action == "start_process"]
  [api where process.Ext.api.name == "WriteProcessMemory"]
  [network where process.entity_id == process.entity_id] by process.entity_id
| until 3

Note the pattern: event → correlation → anomaly condition → ATT&CK tag. Every rule you ship should carry the technique ID so coverage tracking stays automated.

Validating Detections with Atomic Red Team and Purple Teaming

An untested detection is a hypothesis, not a control. Validate with Atomic Red Team, Red Canary’s open-source library of ATT&CK-mapped test cases:

Invoke-AtomicTest T1055 -ShowDetails
Invoke-AtomicTest T1055 -TestNumbers 1,2

The purple-team loop:

1. Execute the T1055 atomic (e.g., remote thread injection via PowerShell).
2. Capture the telemetry—confirm Sysmon Event ID 8/10 fired and reached your SIEM.
3. Verify the rule fires. If not, tune: relax or tighten filters, adjust thresholds.
4. Measure false-positive rate over 48–72 hours against production traffic before promoting to alerting.

Document the result per test. This gives you evidence-based coverage claims—not “we have a T1055 rule” but “our T1055 rule fires on three emulated variants with a <1% FP rate.”

Finding and Closing Telemetry Coverage Gaps

Use ATT&CK Navigator heatmaps layered with DeTT&CT-style scoring to visualize which techniques your logs actually support. The workflow: export your log sources into DeTT&CT (or hand-roll a YAML equivalent), score each technique’s visibility (0–4 per data source), and overlay it against threat-actor technique profiles from ATT&CK’s Groups data. The gap analysis is immediate—techniques that ransomware and APT actors use frequently but your telemetry can’t see are your collection roadmap, not your detection roadmap.

Hunting Workflows: Hypothesis-Driven vs. Indicator-Driven

Structure hunts around two complementary modes:

• Hypothesis-driven (TaHiTI-style) — Start from ATT&CK: “Does anyone in our environment access LSASS from a non-SYSTEM context?” Formulate, hunt, iterate, and promote confirmed findings to automated detections. The TaHiTI framework formalizes this into a repeatable three-phase process.
• Indicator-driven — Pivot from a hash or IP outward: this C2 IP → which hosts connected → what processes made those connections → what behavior preceded them. Indicators here are entry points to behavioral investigation, not endpoints.

Indicator pivoting still makes sense at the lower pyramid levels—when you have fresh threat intel or an incident lead. The mistake is treating indicator matching as detection strategy rather than a hunting input.

Common Mistakes Detection Engineers Make

• Over-reliance on hashes and IOCs. Feed-driven alerting produces noise, burnout, and coverage that evaporates with each infrastructure rotation.
• Blocking instead of detecting. Untuned blocking rules cause outages and get the whole program discredited. Detect, tune, then block.
• Untested rules in production. Every rule should graduate through emulation testing and a false-positive soak period.
• Ignoring log source churn. Sysmon config changes, EDR agent updates, and Windows version upgrades silently break detection logic. Re-run validation after every collection change.

A 30-Day Plan to Operationalize the Pyramid

1. Week 1 — Telemetry audit. Inventory Sysmon/EDR/network/auth log coverage; document blind spots.
2. Week 2 — Technique scoring. Score your top 25 candidate techniques with the frequency/telemetry/difficulty rubric; build the Navigator heatmap.
3. Week 3 — Rule development. Convert the top 10 techniques to Sigma/EQL rules with ATT&CK tags.
4. Week 4 — Validation and reporting. Run Atomic Red Team against each rule, measure FP rates, close the loop, and present the coverage heatmap and gap roadmap to leadership.

Key Takeaways and Further Reading

The Pyramid of Pain is a prioritization framework, not just a diagram. Spend engineering hours at the top: behavioral detections mapped to ATT&CK techniques, built on telemetry you’ve verified, validated through emulation, and tracked against threat-actor profiles. Indicators still matter—as hunting inputs handled by automation, not as your detection strategy.

• David Bianco, “The Pyramid of Pain” — the original 2013 post
• MITRE ATT&CK and the ATT&CK Data Sources documentation
• Atomic Red Team — adversary emulation test library
• Sigma HQ rule repository — community detection rules
• DeTT&CT — ATT&CK coverage scoring and heatmaps

Frequently Asked Questions

What is the Pyramid of Pain in simple terms?

David Bianco’s model ranking adversary indicators by how much pain—cost and disruption—blocking them causes the attacker. Hashes and IPs sit at the bottom (cheap to rotate, cheap to block), while tools and TTPs sit at the top (expensive to change). Detections targeting the top force adversaries to rework tradecraft, not just swap infrastructure.

Should we still collect and block IoCs like hashes and IPs?

Yes—but treat them as fast-expiring tactical data. Automation should ingest feeds and handle blocking so analysts focus on behavior-level detections that retain value across campaigns and infrastructure changes.

How does MITRE ATT&CK relate to the Pyramid of Pain?

ATT&CK techniques live at the top, most painful level of the pyramid. ATT&CK’s per-technique data sources tell you exactly what telemetry you need to collect to detect them, making ATT&CK the bridge between prioritization and implementation.

What telemetry should a detection engineering team collect first?

Process creation with command line, network connections with process attribution, file and module events, and authentication logs—prioritized against high-frequency ATT&CK techniques like process injection, credential dumping, and command scripting.

How do I know if my detection coverage has gaps?

Score technique coverage against your log sources using ATT&CK Navigator and DeTT&CT heatmaps, then validate with adversary emulation via Atomic Red Team. The difference between threat-actor technique profiles and what your telemetry can see is your gap roadmap.