An IOC (indicator of compromise) is an observable artifact on a network or host, such as a file hash, an IP address, a domain name, a registry key or a specific log pattern, that indicates with reasonable confidence that a system has been breached or that malicious activity has taken place. In incident response within cybersecurity, IOCs are the forensic fingerprints that let responders scope an intrusion, search other systems for the same activity and share detections with partners.
IOCs are inherently retrospective: they describe what an attacker already left behind. They are fast to use and easy to share, but attackers can change many of them cheaply, so experienced teams treat IOCs as one input among several rather than as a complete detection strategy.
Types of IOCs and where they are found
IOCs fall into network, host and behavioral categories depending on where the evidence appears. Each type requires a different data source, and a mature incident response team collects all of them.
| IOC type | Example | Typical data source |
|---|---|---|
| File hash | SHA-256 of a malware sample | EDR telemetry, file scanning |
| IP address | Command-and-control server address | Firewall, proxy and flow logs |
| Domain or URL | Phishing or payload download domain | DNS logs, proxy logs, email gateway |
| Email artifact | Sender address, subject, attachment name | Mail gateway and mailbox logs |
| Host artifact | Registry run key, scheduled task, service name | EDR, forensic images, event logs |
| Network artifact | Unusual user agent, JA3 or JA4 fingerprint | Proxy logs, network sensors |
Hashes should use SHA-256; MD5 and SHA-1 values still circulate in older reports but are weaker identifiers. A single changed byte in a file produces a completely different hash, which is why file hashes identify one exact sample, not a malware family.
IOC durability and the pyramid of pain
Not all IOCs are equally valuable. The widely used pyramid of pain model ranks indicators by how much effort an attacker must spend to change them once defenders detect them. Low levels are trivial to evade; higher levels force the attacker to change tools or methods.
| Level | Example | Effort for attacker to change | Typical shelf life |
|---|---|---|---|
| Hash values | Malware sample hash | Trivial, recompile or repack | Hours to days |
| IP addresses | Hosting server address | Easy, rent another server | Days |
| Domain names | Command-and-control domain | Simple, register a new domain | Days to weeks |
| Network and host artifacts | Distinctive URI pattern, mutex name | Moderate, modify tooling | Weeks to months |
| Tools | A specific remote access trojan | Significant, develop or buy new tools | Months |
| TTPs | Credential dumping from LSASS memory | Hard, change tradecraft | Long-lived |
Atomic IOCs at the bottom of the pyramid expire quickly, and stale indicators generate false positives when infrastructure such as cloud IP addresses is reassigned to legitimate tenants. Indicator feeds therefore need expiry dates and confidence scores.
IOC compared with IOA and TTP
An IOC is often contrasted with an indicator of attack (IOA) and with tactics, techniques and procedures (TTPs). The difference lies in timing and abstraction: IOCs are concrete evidence that something happened, while IOAs and TTPs describe what an attacker is doing or tends to do.
| Concept | Focus | Timing | Example |
|---|---|---|---|
| IOC | Artifacts left by an intrusion | During or after the compromise | Known malicious file hash |
| IOA | Actions in progress | As the attack unfolds | Office application spawning a shell |
| TTP | Adversary behavior patterns | Independent of a single incident | A technique mapped in MITRE ATT&CK |
In threat hunting, analysts usually start from TTP-based hypotheses and use IOCs to confirm or expand findings. During incident triage, IOCs extracted from a confirmed case provide the fastest way to answer the question “where else is this attacker present?”.
Using IOCs during an investigation
In an active incident, IOCs drive scoping and containment. Responders extract indicators from the first compromised host, search all available telemetry for matches, and add newly discovered indicators to the next search round. This iterative pivoting continues until no new affected systems appear.
- Collect artifacts from the initial host: files, network connections, persistence entries.
- Normalize them into indicators with context, confidence and first-seen time.
- Sweep EDR, SIEM, DNS and proxy data across the environment for matches.
- Pivot on new findings, such as other domains resolving to the same address.
- Block confirmed indicators at firewalls, DNS resolvers and endpoints during containment.
Sharing usually relies on STIX for structured description and TAXII for transport, alongside platforms such as MISP. Shared indicators should carry context, including the related campaign, the role of the indicator and whether it was observed or only suspected.
Pitfalls when working with IOCs
The most common failure is blocking without context. An IP address belonging to a shared hosting or content delivery service may serve thousands of legitimate sites, and blocking it can disrupt business while barely affecting the attacker.
- Absence of IOC matches is not proof of safety; targeted attackers often use unique infrastructure per victim.
- Unvalidated feeds import false indicators, including common system file hashes.
- Retention gaps in logs make historical IOC sweeps impossible beyond a few days.
- Tipping off the attacker by blocking indicators too early can prompt them to change tools before scoping is complete.
A non-technical view
An IOC is like the evidence a burglar leaves behind: a footprint, a broken lock, a car seen outside the house. Investigators use these clues to confirm that a break-in happened and to check whether neighboring houses were visited too.
Some clues are easy for a burglar to change, such as the car, while others, such as how they break in, are much harder. Good investigators collect both, but rely more on habits that are hard to change.
A concrete example
A finance employee reports a strange pop-up after opening an invoice attachment. The security team isolates the laptop and finds a malicious script that downloaded a remote access tool and connected to an external domain every few minutes.
The responders extract five IOCs: the attachment’s SHA-256 hash, the payload hash, the command-and-control domain, its current IP address and a scheduled task name used for persistence. Searching 30 days of DNS and EDR data reveals two more laptops that contacted the same domain, one of which had the same scheduled task.
All three machines are isolated and rebuilt, the domain is blocked at the DNS resolver, and the indicators are shared with partner organizations through the team’s threat intelligence platform. The IOC sweep turned one alert into a fully scoped incident within a single working day.