Skip to content
>_ITDITDWeb Security Platform

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 that already happened — a suspicious file hash, an attacker's IP or domain, an unusual process. The meaning and types, how to match them against your logs, and the limit (traces are reactive and easily changed) — explained defensively.

Published 2026-06-11 Updated 2026-06-11 5 min read

"How do I tell whether I've been breached?" — the clues are IOCs (Indicators of Compromise). 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
TypeExamplesWhere you match it
NetworkAttacker server IP/domain, C2 URLFirewall / proxy / DNS logs
FileMalware SHA-256 hash, distinctive filenameEDR / antivirus / file listing
HostSuspicious registry key, unfamiliar resident processOS logs, process list
BehaviorLogin at an unusual time/country, sudden bulk trafficAuth 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.

1

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.
2

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).
3

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.
4

Record your own IOCs and fan out the check

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

This site's view: an IOC is a 'scorch mark after the fire' — the real goal is not burning

IOC matching matters, but it's inspecting the scorch marks after a fire. 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 doesn't burn: 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. The power to "notice" via traces and the power to "prevent" traces from existing are two wheels you want together.

FAQ

QWhat is an IOC?
A

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

A CVE is 'where the hole 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: close the hole via the CVE, then inspect for traces via IOCs.

QCan I defend with IOCs alone?
A

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 real defense is a design that doesn't burn (least privilege, prompt patching, phishing-resistant MFA) plus monitoring the harder-to-change 'behavior.'