Indicators of Compromise (IOCs) explained.

Every intrusion leaves fingerprints. A piece of malware writes a file, that file has a hash. A beacon phones home, and the destination is an IP address and a domain. A loader creates a mutex so it does not infect the same machine twice. An indicator of compromise (IOC) is any one of those observable artifacts — a forensic breadcrumb that, when you see it on your own network, strongly suggests that something bad has already happened or is happening right now.

IOCs are the raw currency of day-to-day detection: what a firewall blocks, what an EDR agent matches against process telemetry, what a SIEM correlation rule fires on, and what a threat hunter pivots from. They are also the most fragile signal in the defensive stack, because almost all of them are trivially cheap for an attacker to change. Understanding which IOCs are cheap to swap and which are expensive is the single most useful mental model in threat detection, and it has a name: the Pyramid of Pain. This article covers what IOCs are, the types you will actually meet, how they differ from indicators of attack, why they expire, and how the industry shares them.

What an IOC is, precisely

The formal framing comes from threat-intelligence standards. The US National Institute of Standards and Technology, in SP 800-150, its Guide to Cyber Threat Information Sharing, describes indicators as the technical artifacts or observables that suggest an attack is imminent, currently underway, or has already occurred. In practice an IOC is a specific, matchable value: this exact hash, this exact domain, this exact registry key. That specificity is its strength and its weakness at the same time. It is unambiguous — either you see the value in your logs or you do not — but it only describes one concrete instantiation of an attack, not the attack itself.

An IOC is not the same thing as a vulnerability (a weakness that could be exploited) or an alert (the output of a detection rule). It is the evidence in between: a vulnerability is the unlocked window, an IOC is the muddy footprint on the carpet, and the alert is the sensor that noticed the footprint.

The types you will actually see

IOCs span the whole stack, from a single hash of a file to the shape of a TLS handshake. The examples below use documentation IP ranges (192.0.2.0/24, 198.51.100.0/24, from RFC 5737), defanged domains, and the harmless EICAR anti-malware test file so nothing here is live.

• File hashes (MD5, SHA-1, SHA-256). A cryptographic digest of a file, used to identify a specific malware sample exactly. The EICAR test file, for instance, has MD5 44d88612fea8a8f36de82e1278abb02f and SHA-256 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f. MD5 and SHA-1 still appear everywhere in feeds despite being cryptographically broken, because for indicator lookups you only need uniqueness, not collision resistance. SHA-256 is the modern default.
• IP addresses. Command-and-control servers, scanning sources, exfiltration endpoints — e.g. a beacon calling out to 198.51.100.23:443. They live in firewall, proxy, and NetFlow logs.
• Domain names. Phishing and C2 domains such as secure-login-update[.]com, often generated in bulk or by a domain-generation algorithm (DGA). They surface in DNS query logs and email.
• URLs. A full path pins down a payload or panel more tightly than a bare domain: hxxp://198.51.100.23/panel/gate.php. Proxies, WAFs, and email-link scanners key on these.
• File paths and file names. Where malware drops itself, e.g. C:\Users\Public\svch0st.exe or %APPDATA%\Roaming\update\wsus.exe — a lookalike name in an unusual directory.
• Windows registry keys. Persistence usually touches the registry. A value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run pointing at that dropped binary is a classic autorun IOC.
• Mutexes (mutants). Many families create a named mutex so they do not reinfect a host. A hardcoded mutex like Global\\a7f3c1d9-hydrapanel is a high-fidelity indicator because it is often unique to one malware build.
• User-Agent strings. Malware HTTP clients frequently ship a hardcoded or malformed User-Agent, e.g. Mozilla/5.0 (Windows NT 6.1) Gecko/20100101 wininet-1.2, which stands out against real browser traffic.
• JA3 / JA4 TLS fingerprints. Rather than fingerprinting the destination, these hash the shape of the client's TLS ClientHello — its cipher suites, extensions, and elliptic curves. JA3 (from Salesforce) produces a 32-character MD5 like e7d705a3286e19ea42f587b344ee6865; its successor JA4+ (from FoxIO) is more robust and harder to spoof. Because the fingerprint is tied to the attacker's tooling rather than their infrastructure, it survives an IP change — which is exactly why it sits higher on the pyramid.
• Email headers. In phishing, the envelope tells the story: a Return-Path that does not match the From, a suspicious Received chain, a telltale X-Mailer, a Reply-To pointing elsewhere, and failing SPF/DKIM/DMARC results are all indicators.

Atomic, computed, and behavioral

The classic taxonomy, which comes from Mandiant's OpenIOC work, sorts indicators into three buckets by how they are constructed:

• Atomic indicators cannot be broken down any further and still mean something: an IP address, a domain, an email address, a fixed string. They are the leaf values.
• Computed indicators are derived from incident data — a file hash, a regular expression, a YARA condition. They require some processing to produce.
• Behavioral indicators combine atomic and computed indicators with logic to describe what an actor does: "a Word process spawns PowerShell, which downloads from this domain and writes to this Run key." These sit closest to attacker behavior and start to blur into the territory of TTPs and indicators of attack.

That progression — from a single brittle value up toward a description of behavior — is the same progression the Pyramid of Pain formalizes.

IOCs vs IOAs: evidence of the past vs the act itself

An IOC is reactive by nature. It says "this artifact was seen in a known-bad event, so if you see it too, you are probably compromised." An indicator of attack (IOA) — a framing popularized by CrowdStrike (see their IOA explainer) — describes the intent and technique of an attack as it unfolds, independent of the specific tools or infrastructure used. Credential dumping from LSASS memory, a service being created for lateral movement, or macro code spawning a shell are IOAs: they are true no matter which IP the attacker uses or which hash their binary happens to have this week.

This is why IOAs and TTPs (tactics, techniques, and procedures, as catalogued in MITRE ATT&CK) endure while raw IOCs decay. An attacker can regenerate a domain in seconds and recompile a payload to get a fresh hash in minutes, but changing how they steal credentials or move laterally means re-engineering their entire operation. Detection built on behavior degrades slowly; detection built on atomic IOCs degrades the moment the adversary rotates infrastructure. The two are complementary — IOCs give you cheap, precise, low-false-positive matches for known threats; IOAs give you resilience against variants — and a mature program runs both.

The Pyramid of Pain, level by level

In 2013, David Bianco published The Pyramid of Pain, still the single best framework for reasoning about indicator value. Its premise: not all IOCs are created equal. The pyramid ranks indicator types by how much pain you inflict on an adversary when you deny them the use of that indicator. The higher you detect, the more expensive it is for them to adapt. From bottom to top:

1. Hash values (trivial). Blocking a hash stops exactly one file. Flipping a single byte — padding, recompiling, repacking — produces a brand-new hash and defeats the block instantly. Almost no pain.
2. IP addresses (easy). Blocking an IP is slightly better, but attackers cycle through VPS providers, proxies, and fast-flux hosting cheaply. An address is abandoned and replaced with a shrug.
3. Domain names (simple). Registering a new domain costs a few dollars and a few minutes, though it is marginally more effort than rotating an IP because of registration and DNS propagation. Still low pain.
4. Network and host artifacts (annoying). Now it gets interesting. User-Agent strings, URI patterns, mutexes, registry keys, named pipes, JA3/JA4 fingerprints — these are baked into the attacker's tooling. Detecting them forces the adversary to reconfigure or modify their tools, which is genuinely irritating.
5. Tools (challenging). If you can reliably detect the tool itself — Mimikatz, a specific Cobalt Strike default profile, a custom loader — the attacker must find, build, or buy a replacement and retrain on it. That is real cost and delay.
6. TTPs (tough). At the apex you detect behavior: the techniques themselves. To evade this, the adversary must fundamentally rethink how they operate. This is the most painful and most durable place to detect, and it is where behavioral detection engineering (Sigma rules, EDR analytics) earns its keep.

The takeaway is not "ignore the bottom of the pyramid." Cheap hash and IP blocks are still worth having — they are free and they stop commodity noise. The point is to invest your detection engineering effort as high up the pyramid as you can, because that is where the durable wins are.

The map: IOC type to pyramid level

This table ties the pieces together — each IOC type, a concrete example, where you would find it in your telemetry, and how easily an attacker evades it, mapped to Bianco's pyramid.

Lifecycle and decay: why IOCs expire

An IOC has a lifecycle. It is created from an incident, a sandbox detonation, or an intelligence report; enriched and scored for confidence and context; distributed to sensors and feeds; used for blocking, matching, and hunting; and then it ages until it is retired. That last step is not optional housekeeping — it is essential, because indicators go stale and stale indicators are actively harmful.

They decay for concrete reasons. Attacker infrastructure rotates: a C2 IP is abandoned within days and, worse, the same address is later reassigned by the hosting provider to a legitimate customer — so a block you set months ago now generates false positives against a benign service. Malicious domains get sinkholed or expire and are re-registered by someone innocent. Hashes are unique to one build and become irrelevant the instant the actor recompiles. This is the indicator "half-life," and serious platforms model it explicitly. The MISP decaying models feature assigns each indicator a score that automatically drops over time based on its type and source, so low-confidence, aged indicators stop firing before they drown analysts in noise. The practical rule: an IP or domain block should have an expiry; a behavioral rule generally should not.

How IOCs are shared

An IOC discovered by one organization is far more valuable if everyone else can act on it too, which is why threat-intelligence sharing is a whole ecosystem. It runs on standards, platforms, and feeds.

Standards — STIX and TAXII. STIX (Structured Threat Information eXpression) is the JSON-based language for describing threat intel — indicators, threat actors, malware, relationships — in a machine-readable, unambiguous way. TAXII (Trusted Automated eXchange of Intelligence Information) is the transport protocol for moving STIX between servers and clients over HTTPS. The slogan is that STIX is the what and TAXII is the how; both are maintained by OASIS.

Platforms. MISP (Malware Information Sharing Platform) is the open-source workhorse for storing, correlating, and sharing IOCs across trusted communities. OpenCTI is a newer open-source platform that structures intelligence around the STIX data model and links indicators to actors, campaigns, and techniques. Both ingest and export via STIX/TAXII.

Feeds. Plenty of high-quality, free indicator feeds exist. The abuse.ch project alone runs three of the best: URLhaus for malware-distribution URLs, ThreatFox for general IOCs, and MalwareBazaar for malware samples and their hashes. AlienVault OTX is a large community "pulse" feed, and VirusTotal is the go-to for enriching a single hash, domain, or IP against dozens of engines at once.

How IOCs are used — and where they fall short

Once indicators are in hand, defenders put them to work three ways. Blocking pushes them to enforcement points — firewall deny-lists, DNS sinkholes, EDR block rules, email gateways — so the bad thing never happens. Matching feeds them into detection: a SIEM correlates live and historical logs against the indicator set, and IDS engines like Suricata or Snort alert on network matches. Retro-hunting is a special case of matching — sweeping months of stored logs against a newly published IOC to answer "were we already hit?" Hunting uses an IOC as a starting pivot: one suspicious domain leads you to the IPs it resolved to, the samples that contacted it, and the hosts that queried it. Our walkthrough on how to investigate a suspicious domain shows that pivot end to end, and all of this runs on the SIEM/SOAR/EDR machinery covered in the SOC toolstack.

The limitations are the flip side of the pyramid. Atomic IOCs are brittle — cheap for an attacker to change, so a purely IOC-driven defense is always one recompile behind. They are inherently backward-looking: you can only match a value once someone has already been burned by it, so you stay blind to genuinely novel infrastructure. And they generate false positives and noise as they age, which is exactly why decay scoring matters. The fix is not to abandon IOCs but to layer them: pair the cheap, precise, low-pyramid matches with durable behavioral detection higher up. That is the role of Sigma and YARA rules, which express host and file behavior rather than single values — and the job of turning raw indicators into vetted, contextual, decaying intelligence belongs to the people we compare in threat analyst vs CTI analyst. IOCs are the floor of a detection program, never the ceiling.

Frequently asked questions