H3AD-REF / REFERENCES / IOC VS IOA
An Artifact Isn't
The Same As A Behavior.
Indicators of compromise and indicators of attack answer different questions: what was left behind, versus what is being done. Indicator types, confidence and sharing conventions, the IOC lifecycle, and why an IOC-only detection program ages out fast. For the models this pairs with, see Attack Lifecycle & Adversary Models (Pyramid of Pain, Diamond Model) and Threat Intel Cycles (CTI Lifecycle).
IOC vs IOA
Two different questions about the same intrusion, and two very different shelf lives.
What Each One Actually Answers
IOC — Indicator of Compromise A static artifact left behind by something that already happened ├── A file hash, an IP, a domain, a registry key, a filename └── Answers "did this specific known-bad thing touch my environment" // cheap to check against, but trivial for an attacker to change: recompile the binary, rotate the IP IOA — Indicator of Attack A behavior or sequence of actions that indicates intent, independent of the specific tool used ├── A process spawning a shell, credential dumping behavior, a discovery command sequence └── Answers "is something happening right now that looks like an attack" // harder to build detection for, but survives an attacker changing their tools entirely Why both matter IOC gives you fast, cheap, high-confidence matches against things already known to be bad IOA gives you resilience against variants and unknowns the IOC list has never seen // this split is exactly what the Pyramid of Pain is describing: the higher up the pyramid, the more it hurts the attacker to change
IOC Types
Ranked roughly by how fast each type decays once an attacker knows it's been burned.
IOC
File Hash
MD5, SHA1, SHA256 — the fastest-decaying IOC type
Identifies one exact binary. A single recompile, a packer change, or even a one-byte modification produces a completely different hash, so hash-based blocking has the shortest useful lifespan of any IOC type.
IOC
IP Address
Cheap to rotate, especially with cloud or bulletproof hosting
Useful immediately, but an attacker using rented or compromised infrastructure can move to a new IP in minutes. Shared hosting also risks blocking unrelated legitimate traffic on the same address.
IOC
Domain
More expensive to rotate than an IP, cheaper than infrastructure
Registering a new domain costs a little time and, sometimes, a little money, which makes domains marginally more durable as an indicator than raw IPs, but still trivial for a resourced actor to replace.
IOC
URL / URI Path
A specific path on a specific host, narrower than the domain alone
Useful when the same domain hosts both malicious and legitimate content, letting a block target the specific path without collateral impact on the rest of the domain.
IOC
Filename / File Path
Weak alone, useful in combination
A specific filename or drop path is easy for an attacker to rename, so it's rarely used as a standalone indicator, but it's a useful secondary signal alongside a hash or a behavioral detection.
IOC
Registry Key / Value
Ties directly into the persistence keys covered on the registry reference page
A specific key path or value used for persistence or configuration. See the Registry Key Quick Reference for the keys these indicators most often show up in.
IOA Patterns
Behavioral shapes that hold up even when every IOC associated with the campaign changes overnight.
IOA
Process Lineage Anomalies
Not what ran, but what ran it
An unexpected parent-child relationship, like an Office application spawning a command shell, is a technique-level signal independent of which specific malware family triggered it.
IOA
Discovery Command Sequences
A pattern of reconnaissance, not one suspicious command
A short burst of whoami, systeminfo, net user, and similar commands run in sequence on the same host looks like reconnaissance regardless of which tool or script issued them.
IOA
Credential Access Behavior
The action, not the tool that performed it
A process opening a handle to LSASS memory is the behavior worth alerting on, whether the tool doing it is a well-known credential dumper or something custom-built that's never been seen before.
IOA
Living-Off-The-Land Patterns
Legitimate binaries used in an illegitimate sequence
certutil downloading a file, mshta executing remote content, or a similar LOLBAS technique. No single binary is inherently malicious; the pattern of use is the actual signal.
Confidence & Sharing
An indicator without a confidence rating and a handling label isn't ready to act on. Full breakdown lives on its own page.
SEE ALSO
Admiralty Code & TLP
Source reliability, information credibility, and disclosure handling, in one dedicated reference
Every IOC and IOA in this reference should carry a source-reliability rating and a sharing label before it gets actioned on. See Admiralty Code & TLP for the full A-F / 1-6 rating scale and the current TLP 2.0 tiers.
IOC Lifecycle
An indicator's usefulness is time-bound. Treating a feed as permanent is how blocklists turn into noise.
Collection Through Expiration
1. Collection Pulled from a feed, an incident, a sandbox run, or a partner share // provenance matters: record where every indicator came from, not just what it is 2. Validation Confirm the indicator is actually malicious and not a shared/CDN resource, sinkholed domain, or research artifact before it ever reaches a blocklist 3. Enrichment Add context: campaign, malware family, first/last seen, related indicators └── An IOC actioned without enrichment is how legitimate infrastructure gets blocked by mistake 4. Actioning Push to detection (SIEM correlation, EDR watchlist) or prevention (firewall, proxy, DNS sinkhole) 5. Aging Out Retire the indicator once it's stale // a hash for malware that's been recompiled, or an IP an attacker has abandoned, is dead weight that only adds false-positive risk from that point on
Common Pitfalls
The mistakes that make an indicator program noisy or blind, not the indicators themselves.
PITFALL
Treating A Match As An Automatic True Positive
A hit is a starting point, not a verdict
An IOC match still needs context: what triggered it, what else is happening on that host, and whether the indicator itself was ever validated, before it's treated as confirmed malicious.
PITFALL
Actioning On A Single Low-Confidence Source
One unconfirmed report shouldn't drive a block
Blocking or alerting based on a single source with a low Admiralty rating, with no corroboration, is how legitimate traffic ends up blocked over an indicator that was never solid to begin with.
PITFALL
Never Aging Out Stale Indicators
A blocklist that only grows becomes a liability, not an asset
An IOC feed with no expiration process accumulates dead entries that add false-positive risk (a since-repurposed IP, a sinkholed domain) without adding any real detection value.
PITFALL
Confusing The Artifact With The Technique
An IOC describes what was found, not why it worked
Building a detection program entirely on IOC matching, with no IOA or behavioral coverage, means every campaign the attacker slightly retools around slips through undetected until the next feed update.