David Bianco's Pyramid of Pain ranks indicators by one question: if you deny this, how much does it hurt the adversary to work around it? From the bottom up - hash values, IP addresses, domain names, network and host artifacts, tools, and TTPs.
Why the ordering matters
- Hashes change with a recompile or a single padded byte. Denying one costs the adversary seconds.
- IP addresses change with a new VPS. Minutes, and a few dollars.
- Domains cost a little more: registration, some aging, and reputation systems to get past.
- Network and host artifacts - a distinctive user agent, a named-pipe pattern, a service description, a mutex, a staging directory - require them to modify their tooling.
- Tools require rebuilding or replacing the implant, and relearning it.
- TTPs require changing how they operate. That is the expensive one, and it is the only level where a detection survives the next campaign.
Indicators decay, so treat them as context
Hashes and IPs are perishable. Ingest them as enrichment with an expiry rather than as your detection strategy: an alert on a six-month-old IP list produces noise that teaches analysts to close things unread. What low-pyramid indicators are genuinely good for is retro-hunting - sweeping a fresh set across ninety days of retained telemetry to find the intrusion you already had.
Read the report for behavior, not the appendix
For every observable in a report, ask what the adversary would have to change to break a detection built on it. Then look past the appendix into the prose, because the durable material is described there and rarely tabulated.
Say a report describes an intrusion set that creates a scheduled task with a randomized name, running a signed binary from a directory under ProgramData. Three separate outputs come from that one paragraph:
- Bottom of the pyramid. Load the listed hashes and domains into your intel platform with an expiry, and retro-hunt the last ninety days.
- Artifact level. Detect the specific shape: a task whose action points at
ProgramData. - TTP level. Hunt the general behavior: scheduled tasks created on hosts where no admin was working, whatever the path.
The artifact-level rule is straightforward Sigma:
title: Scheduled Task Created To Run From ProgramData
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\schtasks.exe'
CommandLine|contains|all:
- '/create'
- '\ProgramData\'
condition: selection
falsepositives:
- Vendor installers that register updaters from ProgramData
level: medium
Pair it with Security Event ID 4698, which records task creation regardless of whether the attacker used schtasks.exe, a PowerShell cmdlet or the task-scheduler API directly. The command-line rule catches one tool; 4698 catches the behavior.
Map it, then measure yourself
Tag each detection you produce with the ATT&CK technique it covers, so the report's contribution shows up on your coverage layer rather than in an email thread. Then use a simple scorecard for the intel function: how many detections did this report produce above the domain line? A program that only produces IOC feed entries is buying indicators, not defense.
Where the pyramid misleads
Two caveats keep this from becoming dogma. High-pyramid detections are broader and therefore noisier, so a TTP-level hunt often belongs on a hunting dashboard rather than in the paging queue until it is tuned. And "TTP" is not automatically durable - a rule keyed to one exact command-line string that a tool happens to emit is a tool-level detection wearing a TTP costume. The test is always the same: what would they have to change, and would you still see it?