Indicators of Compromise (IOCs) Explained

Updated: October 2026

An indicator of compromise (IOC) is a trace an attacker leaves behind on your systems: a file, an address, a registry key, a login. Advisories hand them to IT teams as long lists of hashes and IP addresses, and the hard part is knowing which ones deserve action. This guide explains what an indicator of compromise is, how IOCs differ from indicators of attack, where they come from and how a small team puts them to work.

TL;DR

• Definition. An indicator of compromise is evidence on a system or network that an attack is underway or has already happened.
• IOC vs IOA. IOCs are the leftovers, indicators of attack (IOAs) are the behavior that produces them.
• Shelf life. Hashes and IP addresses expire in days. Behaviors last years.
• Use. Sweep your fleet, block what is cheap to block, then search old logs back as far as you keep them.

What Is an Indicator of Compromise?

NIST defines an indicator of compromise as "technical artifacts or observables that suggest that an attack is imminent or is currently underway or that a compromise may have already occurred". Plain version: an IOC is a clue.

Think of a muddy boot print by a window. It doesn't prove a burglary, because the plumber has boots too. It tells you which window to look at first. An IOC works the same way, pointing at the system that deserves a closer look while the context decides the answer.

Here is what clues look like in an IT environment:

A workstation talks to an IP address nobody else in the fleet has ever contacted. A file named update.exe appears in a user's AppData folder. A scheduled task shows up at 3 a.m. An admin account signs in from a country where the client has no staff. Each of these is an observable. It becomes an IOC when it matches known malicious activity or breaks the baseline you expect.

An alert is a tool's opinion that something is wrong. An IOC is the evidence the opinion rests on. Once one is confirmed, your incident response plan decides who does what next.

Types of Indicators of Compromise

IOCs fall into a handful of families, and each family lives in a different log. Knowing where each one surfaces tells you which data you need to keep.

Security teams split these into two groups. Atomic indicators are single values you can match exactly, like a hash or an IP. Behavioral indicators are patterns, like a process chain or a beacon rhythm. Atomic ones are easy to share and easy to match. They are also easy for an attacker to swap, which the pyramid section below covers.

Several of these rows can be stopped before the user ever sees them. DNS filtering blocks known-bad domains at the resolver, so the domain indicator never gets a chance to load.

IOC Examples by Attack Type

Indicators make more sense when you see them in the order an attack produces them.

A phishing attempt leaves a reply-to address that differs from the sender, a lookalike domain in the link and a sign-in shortly after the click. Then comes the indicator people miss: a new inbox rule that forwards mail to an outside address. It's durable, because it sits in the mailbox until someone deletes it.

Ransomware tends to announce itself late. Typical indicators near the end include deleted shadow copies, stopped backup services, a burst of file writes and mass renames to a new extension. By then you are in recovery mode, which is why the earlier indicators (a new remote access tool, unusual admin logins) carry more value.

Account takeover shows up as a sign-in from a new device, a new MFA method registered, then mailbox rules. Our guide to account takeover prevention covers the controls that close that path.

IOC vs IOA: Evidence vs Behavior

An indicator of compromise is what the attacker leaves behind. An indicator of attack is what the attacker is doing while it happens. The IOC question is "have we seen this artifact before?" The IOA question is "is something behaving like an attack right now?"

A recent campaign shows the difference. In February 2026, the Notepad++ developers said their update infrastructure had been compromised. Kaspersky's Securelist analysis describes how a malicious update, launched by the legitimate updater GUP.exe, ran cmd /c whoami&&tasklist > 1.txt, uploaded the output with curl and dropped files into %appdata%\ProShow.

Split that into the two kinds of indicator. The IOCs are the folder, the file hashes and the server address the update came from. The IOA is the behavior: an updater spawning a command shell, listing processes and uploading the result. Over four months, Securelist reports, the attackers kept rotating the C2 server addresses, the downloaders and the final payloads. A list built from one week of those values would have gone stale by the next.

Each kind has a job. IOCs are cheap, fast and precise against a known attack, so a match is worth acting on today. IOAs catch attacks nobody has written up yet, including fileless malware that leaves no file to hash. Neither replaces the other.

Behavior rules usually ship inside EDR products, and our guide to the endpoint security stack shows where they sit.

The Pyramid of Pain: Why Some IOCs Expire Fast

In 2013 security researcher David Bianco published the Pyramid of Pain. It ranks indicator types by how much it hurts the attacker when you take that indicator away. The higher the tier, the more work the attacker has to redo.

• Hash values. Change one bit of a file, even a null byte at the end, and the hash is completely different. Accurate, and nearly worthless a day later.
• IP addresses. A capable attacker swaps them with little effort. Through an anonymous proxy, they may change them without noticing.
• Domain names. A new domain has to be registered and paid for, which is slightly more work. Lax registrars make it cheap anyway.
• Network and host artifacts. A distinctive user-agent string or a registry key forces the attacker to reconfigure or recompile their tooling.
• Tools. Take away a tool and they have to research, build or learn a replacement.
• TTPs (tactics, techniques and procedures). Detect the behavior, such as Pass-the-Hash, and they have to learn a new way of working or give up.

Bianco's own advice is to ask, for every indicator in a report, where it sits on the pyramid. The Notepad++ campaign is a live example of the bottom tiers decaying. Addresses, downloaders and payloads were all swapped over the four months Securelist observed.

That doesn't make a hash or an IP useless. They are cheap to block and fast to match, which makes them a good first layer. The mistake is treating them as the whole defense. A feed of IPs and hashes tells you where attackers were. Higher tiers tell you what they do, and that's where threat hunting lives.

Where IOCs Come From

You have four main sources, and they differ in cost and in how fresh the data is.

Your own telemetry comes first. Every incident you work, every phishing report from a user and every EDR detection produces indicators specific to your environment. These are the ones nobody else can sell you.

Advisories come next. Joint advisories from CISA and its partners, and vendor research like the Securelist report above, publish IOCs along with the story of how they were found. Community feeds fill the gap between advisories. abuse.ch, working with Spamhaus, runs ThreatFox for shared IOCs and URLhaus for malware URLs. MISP is an open-source platform for collecting and sharing indicators between teams.

Whatever the source, the format matters. STIX is an open language and serialization format for exchanging threat intelligence, stored as JSON so machines can read it. If a feed arrives as a PDF with a CSV stapled on, someone will be copying values by hand.

That copying cost is the real argument behind a recent r/sysadmin thread on whether paid threat intel is worth keeping.

One commenter suggests a test you can run before any renewal. Pull an IOC dump from 90 days ago, join it against telemetry you already keep, and count how many of your real incidents appeared in the feed before you found them. It's a good scorecard for any source, free or paid. A feed that produces matches and detections earns its place. A feed that produces PDFs doesn't.

One more caution before you load anything into a blocklist. A single IP can be a shared host or a CDN node, and blocking it takes legitimate sites down with it. Check the age and confidence of every indicator before you act on it.

How to Use IOCs: Sweep, Block, Expire

An IOC does nothing sitting in a spreadsheet. A small team can run the same short routine for every indicator that arrives.

1. Check the source and the date. Who published it, when, and how confident are they? Old, unlabeled indicators go to the bottom.
2. Sweep your own data. Search DNS, firewall, proxy and endpoint logs for the value. Check device inventories for the file path or service name.
3. Block what is cheap to block. Domains at the resolver, IPs at the firewall, sender addresses at the mail gateway.
4. Escalate any hit. A match goes to your incident response plan with the indicator, the device and the timestamp attached.
5. Set an expiry date. Every indicator gets a review date. IP addresses go stale first, so they get the shortest.

Step 2 is where small teams save the most time with a script. After the Notepad++ report, one sysadmin wrote a PowerShell script that checks a machine for the folders, files and services Securelist listed and prints CLEAN or FOUND for each.

The author says it plainly: read any script yourself before you run it. The pattern is sound, though. An advisory's indicators become a checklist you run across every device and collect in one place. On OpenFrame, the open, AI-native infrastructure layer for IT and security, that means running a script across a client's devices and reading the output back in one view.

Search Old Logs Before You Relax

New indicators often describe activity that started weeks ago. Google's M-Trends 2026 report puts the global median dwell time at 14 days, up from 11 the year before. For cyber espionage and North Korean IT worker incidents the median was 122 days.

Long-running intrusions stretch the gap further. M-Trends notes that threats like BRICKSTORM reached dwell times of nearly 400 days, and that a standard 90-day log retention policy leaves organizations blind to the initial access.

So run every new indicator backward as well as forward. Search the logs you have for the value, and note the date range you can't cover. That range is itself a finding: it tells you how far back an attacker could have been sitting without leaving a trace you can read. Our guide to log management covers retention choices for small teams.

What to Do This Week

Pick one source you trust and one place to match its indicators, whether that's DNS logs, your firewall or an endpoint script. Run the 90-day backtest on it and write down how many real incidents it would have caught. Give every indicator an expiry date.

Then move one step up the pyramid. Choose a single behavior worth watching, such as an updater process that starts a command shell, and write it down as a rule or a hunt. Hashes and IPs answer the question of what hit someone else last week. Behaviors answer what is happening on your network today.

If you want the next piece of the picture, read how a ransomware attack moves hour by hour and which indicators show up at each stage.