What Are Indicators of Compromise (IOC)?

A SOC analyst pulls a firewall log and finds a workstation beaconing to 185.220.101.47 every 60 seconds, at 3 a.m., long after the user went home. The IP belongs to no business service. That single artifact, an outbound connection to a known-bad address, is an indicator of compromise. It does not prove what happened. It tells the analyst where to start digging.

An indicator of compromise (IOC) is a piece of forensic evidence that suggests an endpoint or network has been breached. A malicious file hash, a callback domain, a suspicious registry key, a spike in failed logins. Each one is a clue left behind by activity that already occurred. Investigators collect these clues to confirm an intrusion, scope it, and hunt for the same attacker elsewhere.

This guide covers what an IOC is, the indicators worth watching, how teams collect and operationalize them, how IOCs differ from indicators of attack (IOA), why the Pyramid of Pain decides which indicators actually hurt an attacker, and how IOCs fit into detection and response. It is written for blue teamers who need to use indicators, not just recognize the acronym.

What is an indicator of compromise?

An indicator of compromise is digital forensic evidence that points to a breach. Think of it as the cyber equivalent of a fingerprint at a crime scene: it does not commit the crime, it reveals that one took place and helps identify who was there.

IOCs are reactive by definition. They describe something that has already happened. The attacker has already sent the phishing email, already dropped the payload, already opened the command-and-control channel. The indicator is the residue. That is the strength and the limit of an IOC at the same time: it gives defenders concrete, matchable evidence, but it surfaces after the action, not during it.

Indicators come in a few families:

• Network indicators. IP addresses, domains, URLs, and traffic patterns tied to malicious infrastructure. The beaconing IP above is a network indicator.
• Host indicators. File hashes (MD5, SHA-1, SHA-256), file names and paths, registry keys, mutexes, and service names left on an endpoint by malware.
• Behavioral indicators. Patterns rather than static values: a privileged account logging in from a new country, an unusual volume of database queries, large compressed archives appearing where none should be.

A single weak indicator rarely justifies an alert on its own. A blocked IP could be a typo in a config. The value comes from correlation: an unknown hash plus an outbound connection to a flagged domain plus a new admin account is a pattern, and a pattern is an investigation.

Common examples of indicators of compromise

The following are the warning signs SOC teams watch for most often. None is proof by itself. Several together usually are.

• Unusual outbound network traffic. Often the clearest sign. Data leaving the network on odd ports, to odd destinations, at odd hours points to data exfiltration or active command-and-control.
• Anomalies in privileged account activity. A service or admin account doing something it never does, logging in at strange times, or escalating its own rights, is a high-value indicator because attackers prize those accounts.
• Geographic irregularities. Connections to or from countries the organization has no business in, or a single account authenticating from two distant locations minutes apart.
• A surge in failed logins or access requests. Repeated failures against one account or across many suggest brute forcing or credential stuffing in progress.
• Spikes in database read volume. A sudden jump in records read can mean an attacker is pulling the database toward the door.
• Unexpected software or processes. Unknown applications, services, or scheduled tasks on a host, especially ones that survive reboot.
• Suspicious registry or system file changes. Edits to autorun keys, system binaries, or boot configuration, a common persistence move.
• Anomalous DNS requests. Beaconing patterns, requests to algorithmically generated domains, or high-entropy subdomains used to tunnel data.
• Large, unexplained compressed files. Staged archives in temp folders or odd directories often mean data was bundled for theft.
• Mismatched or unexpected configuration changes. Altered firewall rules, new mobile device profiles, or disabled logging, frequently the attacker covering tracks.

These map cleanly onto the kill chain. Failed logins and new processes show up early; large archives and outbound spikes show up late, near exfiltration. Where an indicator sits tells you how far the intrusion has progressed.

How teams collect and use IOCs

Indicators are only useful if they are gathered, shared, and acted on. The workflow runs in a loop, not a straight line.

Collect. IOCs come from many places: endpoint detection and response (EDR) and antivirus telemetry, security information and event management (SIEM) logs, network sensors, firewall and DNS logs, and external threat intelligence feeds that publish indicators tied to known campaigns. Incident responders also extract fresh indicators directly from a compromised host during analysis.

Standardize and share. Raw indicators are formatted so tools and teams can exchange them. STIX (Structured Threat Information Expression) describes the indicator and its context; TAXII is the protocol that moves it between platforms. Detection logic is commonly written as YARA rules for files and Sigma rules for logs. Standard formats are what let one team's discovery become another team's blocklist within hours.

Operationalize. Confirmed indicators are pushed back into the controls: block the IP at the firewall, deny the hash at the endpoint, alert on the domain in the SIEM, and sweep historical logs to find every host that already touched it. This last step, retrospective hunting, is where a single new indicator can uncover an intrusion that started weeks earlier.

Learn. Every investigation produces new indicators and a clearer picture of the adversary's tools and habits. That feeds back into detection rules, response playbooks, and the next hunt. IOCs are both an output of cyber threat intelligence and a fuel for it.

IOC vs IOA: evidence versus intent

The most useful distinction in this topic is between an indicator of compromise and an indicator of attack (IOA). They are not competitors. They answer different questions at different times.

An IOC is reactive. It is forensic evidence of something that already happened: this hash ran, this domain was contacted, this file appeared. You match against IOCs to confirm and scope a breach after the fact.

An IOA is proactive. It describes attacker behavior and intent in progress: a process reading credential memory, a script disabling security tooling, an account moving laterally. An IOA fires on what the adversary is trying to do, regardless of which specific tool or file they use.

The practical difference is durability. An attacker can recompile malware to change its hash, register a new domain, or switch IP addresses in minutes, which makes static IOCs go stale fast. The underlying behavior, steal credentials, establish persistence, exfiltrate data, is far harder to change because it is the goal itself. That is why mature detection leans on IOAs for early warning and uses IOCs to confirm, scope, and block.

Use both. IOAs catch the attack you have never seen; IOCs make sure you find every place the one you have seen has already been.

The Pyramid of Pain: not all indicators hurt equally

Security researcher David J. Bianco introduced the Pyramid of Pain in 2013 to answer a question IOC lists ignore: when you deny an indicator, how much does it cost the attacker to recover? The pyramid ranks indicator types by the pain inflicted, from trivial at the bottom to severe at the top.

• Hash values (trivial). Blocking a file hash is precise but worthless for long. The attacker changes one byte and the hash is new.
• IP addresses (easy). Blocking an IP helps briefly. Attackers rotate addresses and proxies constantly.
• Domain names (simple). Slightly harder to change than an IP, but new domains are cheap and fast to register.
• Network and host artifacts (annoying). User-agent strings, file paths, registry patterns, and C2 URI structures force the attacker to rework tooling.
• Tools (challenging). Detecting and denying the attacker's actual toolset, their malware family or framework, makes them find or build a replacement.
• TTPs (tough). Tactics, techniques, and procedures, the behaviors at the top, are the attacker's habits. Detect those and you force them to relearn how they operate, which is the hardest thing of all to change.

The lesson for a defender: blocking hashes and IPs is necessary but low-value, because the attacker shrugs it off. Detection that targets tools and TTPs, which is where IOAs live, is what actually disrupts a campaign. The pyramid is the reason "we blocked the IOCs" is not the same as "we stopped the adversary."

How IOCs fit into detection and response

IOCs touch nearly every part of the security workflow.

In monitoring, indicators feed the SIEM and EDR as detection content. Known-bad hashes, domains, and IPs become rules that fire when a match appears in live telemetry. This is the cheapest, fastest detection a team has, and also the most easily evaded.

In incident response, IOCs are how you scope. Once responders confirm one indicator on one host, they sweep the environment for it everywhere, turning a single alert into a full map of affected systems. The DFIR process leans heavily on this: extract indicators from the first compromised machine, then hunt for them across the fleet.

In threat hunting, indicators are starting hypotheses. A hunter takes an IOC from a fresh intelligence report on an active campaign and searches historical data for it, looking for an intrusion that slipped past real-time detection. Found nothing? That is a result too. Found a hit weeks old? That is an incident.

The limit is worth restating. Because IOCs are reactive and easy for an attacker to change, a program that relies on indicator matching alone is always one step behind. Indicators are essential for confirmation, scoping, and blocking known threats. They are not sufficient for catching the threats no one has documented yet. That is the job of behavior-based detection, and the two work best together.

Frequently asked questions

What is an indicator of compromise in simple terms?

An indicator of compromise is a piece of forensic evidence that suggests a system or network has been breached. Common examples are a malicious file hash, a connection to a known-bad IP address or domain, a suspicious registry change, or a spike in failed logins. It is a clue that an attack happened, used to confirm and investigate the breach.

What are the most common types of IOCs?

The most common are network indicators (malicious IP addresses, domains, URLs, and unusual traffic), host indicators (file hashes, file names and paths, registry keys, and mutexes), and behavioral indicators (privileged-account anomalies, geographic irregularities, failed-login surges, and large unexplained data transfers). Analysts correlate several together rather than alerting on one.

What is the difference between an IOC and an IOA?

An IOC is reactive, it is evidence of an attack that already happened, such as a file hash or callback domain. An IOA is proactive, it describes attacker behavior and intent in progress, such as credential dumping or lateral movement. IOCs are easy for attackers to change, while the behavior an IOA detects is much harder to change, so the two are used together.

What is the Pyramid of Pain?

The Pyramid of Pain, created by David J. Bianco in 2013, ranks indicator types by how much pain denying them causes an attacker. Hashes and IP addresses sit at the bottom because they are trivial to change. Tools and TTPs (tactics, techniques, and procedures) sit at the top because changing them forces the attacker to relearn how they operate.

How do security teams use indicators of compromise?

Teams collect IOCs from EDR, SIEM, network logs, and threat intelligence feeds, then standardize them in formats like STIX and TAXII and write detection as YARA or Sigma rules. Confirmed indicators are pushed into firewalls, endpoints, and SIEM rules to block and alert, and used to sweep historical logs to find every host an attacker already touched.

Are IOCs enough to stop an attacker?

No. Because IOCs are reactive and easy for an attacker to change, indicator matching alone leaves a program one step behind. IOCs are essential for confirming, scoping, and blocking known threats, but catching novel or in-progress attacks requires behavior-based detection (IOAs). The two approaches complement each other.

The bottom line

An indicator of compromise is forensic evidence that a breach occurred: a hash, an IP, a domain, a registry change, a behavioral anomaly. Individually weak, correlated they are an investigation. Teams collect indicators from telemetry and intelligence feeds, standardize them with STIX, TAXII, YARA, and Sigma, and push them into controls to block known threats and sweep for every host already touched. But IOCs are reactive and cheap to change, which the Pyramid of Pain makes plain: blocking hashes and IPs barely inconveniences an attacker, while detecting tools and TTPs hurts. Use IOCs to confirm and scope what you have seen, and behavior-based detection to catch what you have not. Together they close the gap that either leaves open alone.