Home / Knowledge hub / Indicators of compromise
Knowledge hub
Indicators of compromise
Traces, such as addresses or file hashes, that suggest a system has been breached.
What it means
Indicators of compromise, usually shortened to IOCs, are pieces of evidence that a system may have been breached. Typical examples are an IP address an attacker used, the hash of a malicious file, a domain that malware contacts, or an unusual registry entry.
They work like fingerprints left at a scene. If you know what a particular intruder or tool tends to leave behind, you can search your logs and machines for the same marks, even long after the event. Search first, then ask what the matches mean.
Why it matters
IOCs shorten the time between hearing about an attack and knowing whether it touched you. When a vendor or agency publishes a list for a campaign, a team can search its own logs within hours and answer the question every customer will ask: were we affected?
They also have limits that are easy to forget. Attackers change addresses and rebuild files cheaply, so an old indicator may match nothing. A clean search is not proof of safety. It only shows that this attacker, using these traces, was not seen.
How it shows up
You meet IOCs in threat reports, in alerts from endpoint detection tools, and in your SIEM where rules match incoming logs against feeds. They matter most in the first hours of an incident, to size the damage. Each one should come with a source and a date.
Common mistakes: loading huge unvetted feeds that bury analysts in false matches, ignoring how old an indicator is, and blocking shared addresses that legitimate users also use. Keep the source and date with each one. Pair them with behaviour-based detection, because behaviour is harder for an attacker to change than an address.
Questions people ask
Indicators of compromise, answered
What is the difference between an IOC and an IOA?
An indicator of compromise points to evidence that a breach has already happened. An indicator of attack points to behaviour that suggests an attack is under way, such as a process spawning a shell.
Both are useful. IOCs look back, and attack indicators help you act sooner.
Where do IOCs come from?
From your own investigations, from security vendors, from government bodies and from industry sharing groups. Reports often list them in an appendix.
Check the source and the date before you trust a list, as stale indicators cause false alarms.
Can an IOC be a false alarm?
Yes. A shared hosting address, a reused domain or a common file name can match harmless activity. Matches need a person to look at the context.
This is why low-quality feeds lead to alert fatigue.
Do IOCs help prevent an attack?
Partly. Blocking known bad addresses can stop some commodity attacks. But a determined attacker can change them quickly.
They are stronger for detection and investigation than for prevention.
How long should we keep IOC data?
Keep the indicators with their dates, and keep the logs you search them against long enough to look back. Many incidents are found months after they begin.
Your log retention period sets how far back you can check.
Related
Terms that sit next to this one
Threat hunting
Searching your systems for attackers that alerts have not yet caught.
SIEM
A system that gathers logs from everywhere and raises alerts on suspicious patterns.
EDR
Software on laptops and servers that records activity and spots attacks.
Log retention
How long you keep logs, which decides whether you can investigate old incidents.
MITRE ATT&CK
A public catalogue of the tactics and techniques real attackers use.
Which flaw let them in?
Indicators tell you who was there. They rarely tell you how they got in. We find the weaknesses in your web app and APIs and prove them with a request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.