Glossary

#IOC #incident response #threat intelligence #detection

What is an IOC (Indicator of Compromise): traces that reveal a breach

An IOC (indicator of compromise) is a trace left by a breach, such as a file hash or attacker IP. The types, how to match them against logs, and their limits.

Published 2026-06-11 Updated 2026-10-06 8 min read

On this page

IOCs (Indicators of Compromise) are the clues that tell you whether you've been breached. Here's the meaning and types, how to use them, and why you shouldn't over-trust them — all defensively (no attack steps).

The main types of IOC

They split into four, by "where the trace lands."

Network

Destination IPs, domains, URLs

File

Malware hashes, telltale filenames

Host

Odd processes, registry changes

Behavior

Late-night bulk sends, odd logins

Type	Examples	Where you match it
Network	Attacker server IP/domain, C2 URL	Firewall / proxy / DNS logs
File	Malware SHA-256 hash, distinctive filename	EDR / antivirus / file listing
Host	Suspicious registry key, unfamiliar resident process	OS logs, process list
Behavior	Login at an unusual time/country, sudden bulk traffic	Auth logs, traffic monitoring

IOC vs IOA — "trace" vs "behavior"

The common contrast is the IOA (Indicator of Attack). The difference shows both IOC's strength and its weakness.

IOC (Indicator of Compromise) = a trace of the result

Evidence of what already happened (hashes, IPs)
Can be matched mechanically against known-bad — fast
But attackers change it easily (disposable)
Inherently reactive

IOA (Indicator of Attack) = behavior in progress

The flow of technique: privilege escalation → lateral move → exfiltration
Catches it closer to real time
Harder to change than a trace (it's the essence of the attack)
Heavier to adopt — it needs understanding the mechanics

How "changeable" each is to the attacker (the pyramid of pain)

Even among IOCs, the effort an attacker needs to change one — i.e. how much it hurts them when you catch it — varies wildly. Lower is easier to change; higher is harder.

Techniques / TTPs (hardest to change = most effective)

Tools

Domain names

IP addresses, file hashes (changed in an instant)

Bottom = attackers change it instantly (low impact). Top = hard to change (high impact).

So matching hashes and IPs works fast but goes stale fast. The more you understand the technique (how they attack), the longer your defense lasts.

Using IOCs even at small scale

Even without a dedicated EDR or threat-intelligence subscription, there's a realistic minimum you can do.

Get IOCs from trusted sources

Use IOCs published in official breach disclosures, authority/CSIRT advisories, and reputable vendor reports. Don't use a list of unknown origin.

Match them against your logs and dependencies

Cross-check the shared IPs/domains/hashes against your access logs, DNS logs, and dependency packages (e.g. on a supply-chain disclosure, check whether you use the same poisoned version).

On a hit, isolate and investigate

Cut off the affected device/key/token and scope the impact, then restore per your backup and recovery plan. For a website or server, see also how to check for intrusion and what to do first.

Record your own IOCs and check other devices

Note the traces you found and widen the inspection to other devices and services for the same signs.

Real cases: what served as the clue to match

IOCs aren't only IP addresses and hashes. In the supply-chain cases this site has covered, the package "version" itself was the first thing to check.

Case	Clue	What users checked
XZ Utils (2024)	The versions containing malicious code (5.6.0 and 5.6.1)	Whether their OS or containers had those versions. US CISA advised downgrading to an uncompromised version such as 5.4.6
Codecov (2021)	The distributed script's hash (SHA-256) didn't match the official value	The tampering was found because one company ran this check. Users looked at how long they had run it in CI and which secrets it could reach
Trivy (2026)	The maliciously published versions (v0.69.4 and others) and the published check items	Whether CI used those versions or tags during the window. If so, rotate every credential

In all three, the clues were published by the compromised party or authorities, and the matching was done by users themselves. When an official notice comes out, first check whether the same version or hash exists in your environment. That's the basic way to use IOCs.

IOCs have a shelf life

RFC 9424 (2023), the IETF document on handling IOCs, describes managing them through discovery, assessment, sharing, deployment, detection, reaction and end of life. The last stage exists because IOCs go stale.

IP addresses and domains an attacker abandons may later be reused by legitimate services. Blocking from an old list can stop legitimate traffic
Changing a single byte produces a different hash, so a new build of the same attack won't match
So record the date and source of each IOC, and review them periodically

How to match IOCs in your own environment

Even without a dedicated product, you can match three kinds of published IOCs yourself: versions, hashes and domains.

Versions: paste a lockfile into the dependency vulnerability scanner to see whether known malicious or vulnerable versions are included. For OS packages, check the version with each command, e.g. xz --version
Hashes: compute a downloaded file's value with sha256sum FILE (on Windows, certutil -hashfile FILE SHA256) and compare it with the official value or the published IOC
Domains and IPs: search DNS logs and web server access logs for the published domains or IPs. Periods without logs can't be checked, so confirm your log retention too

On a hit, cut off the affected device, key or token and go to step 3 above.

This site's view: IOCs confirm a breach after the fact; the main goal is preventing intrusion

IOC matching matters, but it's checking for traces after a breach has happened. By the time a trace shows up, you're already breached. So on this site we keep IOC matching as an inspection tool, while putting the weight on a design that prevents intrusion: least privilege, prompt patching (CVE monitoring), phishing-resistant MFA, and never storing secrets in plaintext. A defense that leans on reactive trace-matching is always a step behind. You want both: the ability to notice via traces and the ability to prevent the intrusion.

Sources (primary)

IETF RFC 9424, "Indicators of Compromise (IoCs) and Their Role in Attack Defence" (August 2023) — rfc-editor.org (definition of IoC, the pyramid of pain, the IoC lifecycle and end of life)
US CISA, "Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094" (March 29, 2024) — cisa.gov (affected versions and recommended action)
Sources for Codecov and Trivy are listed in each case write-up

FAQ

QWhat is an IOC?

Short for Indicator of Compromise — a trace left by a breach that already happened. Concretely: a suspicious file's hash, an attacker's destination IP or domain, a malicious URL, an unusual process or registry change. You keep these as a known-bad list and match them against your logs and devices to spot signs of compromise.

QHow is an IOC different from a CVE?

A CVE is 'where the vulnerability is' (a vulnerability identifier); an IOC is 'is there evidence of a breach' (proof of attack). A CVE is what you patch; an IOC is what you check to see if you've already been hit. The order: fix the vulnerability via the CVE, then inspect for traces via IOCs.

QCan I defend with IOCs alone?

No. IOCs are inherently reactive, and attackers can swap file hashes and IPs cheaply. IOC matching is useful as a final check for known-bad, but the main defense is a design that resists intrusion (least privilege, prompt patching, phishing-resistant MFA) plus monitoring the harder-to-change 'behavior.'

QWhat's the difference between an IOC and an IOA?

An IOC (Indicator of Compromise) is a trace left by a breach that already happened, such as a file hash or a destination IP or domain. An IOA (Indicator of Attack) is the behavior of an attack in progress, such as the sequence from privilege escalation to sending data out. IOCs can be matched mechanically and quickly but are easy for attackers to change; IOAs are harder to change but take more understanding and monitoring effort.

QWhat are examples of IOCs?

Malware SHA-256 hashes, destination IP addresses and domains used by attackers, malicious URLs, suspicious file names or registry keys, and compromised package versions. In the XZ Utils incident (2024), for example, the versions containing malicious code (5.6.0 and 5.6.1) were the first clue users needed to check.

QWhere do I get IOCs?

The main sources are official announcements from the compromised company or project, advisories from authorities and CSIRTs such as US CISA and JPCERT/CC, and security vendors' research reports. Don't use lists of unknown origin, which can contain wrong values that block legitimate traffic. Record the date and source, and review IOCs as they age.