7.3 IoC vs IoA and the Pyramid of Pain

Indicators you can type versus behaviors you can see

SAL1 training content covers Indicators of Compromise (IoCs) and Indicators of Attack (IoAs), common IoC types (IP addresses, file hashes, domains), the difference between IoC and IoA, and the Pyramid of Pain. You also need practical judgment: where to use an IoC in a SOC workflow so it actually finds or stops something.

An IoC is an observable artifact that suggests a system, account, or network path has been compromised or used in a compromise. Classic IoCs are static enough to put in a block list or a SIEM lookup: file hashes, IP addresses, and domain names. Related artifacts (email addresses, mutex names, certificate serials) behave like IoCs when you match them exactly.

An IoA is evidence of adversary behavior in progress—the technique, not only the leftover fingerprint. Examples: a process opening Local Security Authority Subsystem Service (LSASS) memory, an encoded PowerShell download cradle, a burst of failed logons followed by success and then directory-replication queries, or Office apps spawning cmd.exe. IoAs answer what the attacker is doing. IoCs answer whether this object matches a known-bad value.

You need both. A hash block stops that exact sample. A behavioral IoA can still fire when they recompile the sample.

This section is independent study material covering those SAL1 topics.

IoC types SAL1 emphasizes

File hashes

MD5, SHA-1, or SHA-256 of a file. Highest confidence that you mean this exact byte sequence. Lowest resilience: flipping one unused bit produces a different hash. Use hashes to pivot in a malware-intelligence portal, to match a dropped payload in EDR, and to write a precise case-report IoC. Do not build your whole defense on hash equals malware.

IP addresses

Source of scans, C2 servers, payload hosts. Easy for attackers to swap (new cloud virtual machine, content delivery network, residential proxy, Tor). Still useful for emergency blocks and for asking who talked to this address at 01:12. Watch shared hosting: one IP may be thousands of sites, so a reckless block can hurt business traffic.

Domain names

C2 hostnames, phishing look-alikes, payload sites. Slightly costlier than IPs because of registration and DNS propagation, but still cheap with stolen cards, freshly registered names, or fast-flux. Blocking invoices-update.example often hurts more than blocking today's resolved IP if they round-robin addresses behind the name.

Where SOC teams define and use these IoCs:

• Email security and DNS or proxy filters (domains, sometimes sender IPs)
• Firewall and EDR block lists (hashes, IPs, domains)
• SIEM lookups that tag events (this is how intel becomes an alert)
• Ticket and case-report fields (simulations expect you to record IoCs you actually observed)
• Threat intelligence platforms that share structured indicators with other tools

An IoC you never search for is a souvenir.

IoC versus IoA in a single incident

Take the hospital macro case from the Kill Chain section. The hash of update.exe is an IoC. The C2 IP and invoices-update.example are IoCs. Maya's mailbox receiving a look-alike sender is an email artifact you can match like an IoC.

IoAs: Excel spawning wscript.exe; a new HKCU Run key created by a non-admin user at 10:14; HTTPS beacons with a tight 60-second interval to a 48-hour-old domain; sudden archive creation on \\filesrv01\finance. Those statements remain true even if the attacker changes the hash and buys a new domain tomorrow—unless they also change the behavior.

If your only detection is the hash, they recompile and walk in. If you detect Office spawning a script interpreter, then a new Run key, then periodic beacons, they must change tradecraft.

David Bianco's Pyramid of Pain

In 2013 (with a Hash Values level added in a 2014 update), David Bianco published the Pyramid of Pain: a ranking of indicator types by how much pain you cause the adversary when you detect and deny that type quickly. The bottom of the pyramid is easy for them to change. The top means they must relearn how to operate.

Memorize this order bottom to top:

1. Hash Values
2. IP Addresses
3. Domain Names
4. Network/Host Artifacts
5. Tools
6. TTPs (Tactics, Techniques, and Procedures)

Hash Values (trivial pain)

Exact file fingerprints. Adversary recovery: recompile, pad the file, or generate a unique sample per victim. SOC example: add the SHA-256 of update.exe to EDR block. The next email carries update2.exe with a new hash; the block never fires.

IP Addresses (easy)

C2 or scanner addresses. Recovery: a new VPS in minutes, or hide behind a CDN. SOC example: a firewall drops 203.0.113.44. Beacons resume to 198.51.100.10 an hour later. Still worth blocking for this incident's containment.

Domain Names (simple)

Need registration and DNS. Recovery: a new domain, a domain-generation algorithm, or a hijacked legitimate name. SOC example: sinkhole invoices-update.example. Attackers send a new campaign using invoice-secure.example. You bought hours, not a career change for them.

Network and Host Artifacts (annoying)

Distinctive leftovers that are not just the IP or the hash. Network: URI patterns such as /gate.php?id= plus 16 hex characters, a broken User-Agent string, unusual TLS fingerprints, a rigid beacon interval. Host: a mutex Global\OfficeTemplateUpdate, a file path under %APPDATA%\Microsoft\Templates\, a service display name, a Run key named OfficeTemplateUpdate. Recovery: they must reconfigure or recompile. SOC example: alert on that Run key name or on Excel writing executables under AppData. They can rename, but they spend lab time.

Tools (challenging)

The software they bring: a specific remote-access family, a builder, a password dumper. Detections that survive moderate edits (YARA on a code family, a parser for a C2 protocol, this is that implant family's beaconing) force them to buy, build, or train on a new tool. SOC example: you consistently catch their remote-access family even after hash changes. They must switch implants.

TTPs (tough)

How they work, independent of one binary: spearphishing with macro-enabled invoices to accounts-payable clerks; dumping credentials and reusing hashes; living-off-the-land with wscript.exe after Office. Detecting the TTP—for example, Office child process is a script host, then a persistence Run key, then periodic HTTPS to a newly registered domain—forces them to change targeting, social-engineering style, or post-exploitation habits. That is weeks of practice, not a new VPS.

That is why blocking TTPs hurts attackers more than blocking a hash. A hash is a disposable costume. A TTP is the play they know how to run.

Worked SOC examples at every level

Incident: the same Q3-Invoice-8891.xlsm campaign against the hospital.

Notice the case report still lists hashes, IPs, and domains. Those IoCs help partners and tomorrow morning's blocker push. The durable win is climbing the pyramid: artifacts, tools, TTPs.

Practical habits

• Record IoCs you saw, not every feed hash. Stale hashes create false confidence.
• Enrich: domain age, registrar, whether the IP is a known cloud network-address translation pool.
• Pair every IoC with an IoA question: if they change this value, what behavior remains?
• Do not call a User-Agent string a hash. Keep the pyramid labels straight.
• Do not confuse IoA with any alert. A CPU spike is not automatically an IoA; a documented technique pattern is.

Memory hook: hashes, IPs, and domains are the names on the wanted poster. Artifacts, tools, and TTPs are how the suspect actually commits the crime. Posters expire. Methods take longer to unlearn.