What is an indicator of compromise (IoC)?

An indicator of compromise (IoC) is a piece of forensic evidence, an observable artifact on a network or system, that indicates with high confidence that a security breach has occurred or is underway. Common IoCs include file hashes of known malware, malicious IP addresses and domains, command-and-control (C2) infrastructure, suspicious registry keys, and anomalous login or traffic patterns. Think of IoCs as the digital fingerprints an attacker leaves behind. Security teams use them in two ways: reactively, to investigate a suspected incident, trace an attacker's path, and scope the damage; and proactively, by feeding known IoCs into detection tools so an alert fires automatically if the same artifact reappears. That second use is what makes threat intelligence feeds and IoC sharing so valuable. IoCs are a foundational element of cyber threat intelligence (CTI), detection engineering, and incident response.

Key takeaways

IoCs are forensic evidence of a breach. Artifacts like file hashes, IPs, and domains that signal a system has been, or is being, compromised.
They're used reactively and proactively. To investigate incidents after the fact, and to feed detection tools that alert on known-bad artifacts.
IoC is not the same as IOA. An IoC is a static artifact (the "what"); an indicator of attack (IOA) is behavior in real time (the "how"). Mature teams use both.
An observable is not automatically an IoC. Raw technical data becomes an IoC only once it's qualified and given context; otherwise it generates false positives.
Sharing multiplies their value. Standardized formats like STIX and TAXII let a breach detected in one organization protect many others.

Observable vs indicator of compromise: A crucial distinction

A raw piece of technical data, an IP address, a hash, a domain, on its own is only an observable. It becomes an indicator of compromise only once it has been analyzed, qualified, and given context: who used it, in what campaign, with what confidence, and for how long it stays relevant. Treating a bare observable as an IoC is one of the most common mistakes in threat intelligence, and it leads to a flood of false positives.

For example, a single IP address means little by itself. The same IP, qualified by researchers as attacker infrastructure used for command-and-control in a specific campaign, and enriched with context and an expiry, is a genuine IoC. Context is what turns data into intelligence.

IoC vs IOA: What is the difference?

IoCs are frequently confused with indicators of attack (IOAs), but they answer different questions and serve different detection goals.

	Indicator of Compromise (IoC)	Indicator of Attack (IOA)
Focus	Artifacts left behind (the "what")	Behavior and techniques (the "how")
Timing	Mostly retrospective: something already happened	Real time: an attack in progress
Nature	Specific and static (a hash, an IP address)	Broader and behavioral (a technique)
Evasion	Easily evaded: change the file, change the hash	More resilient: behavior persists even if tools change
Best for	Fast detection of known threats	Catching novel and sophisticated attacks

The relationship is complementary, not competitive. IoCs detect known threats quickly and power blocklists and retrospective threat hunting; IOAs catch new attacks and threat actors who deliberately craft tools to avoid matching known IoC databases. A useful illustration: an IP address seen in a past attack becomes an IoC; when that same IP is later observed connecting to your network, that live event is effectively an indicator of attack. Mature security operations run both together.

Types of indicators of compromise

IoCs are usually grouped by where they're observed in the environment.

Network-based IoCs

Artifacts seen in network traffic: malicious IP addresses, domains, and URLs; connections to known C2 servers; unusual outbound traffic or data-exfiltration patterns; anomalous port activity; and DNS anomalies such as high-volume requests to a single domain or queries to algorithmically generated domains (DGAs). Detected largely by SIEM and intrusion detection systems (IDS).

Host-based IoCs

Evidence on an individual workstation or server: suspicious processes, registry key changes, unauthorized new user accounts, modified system configurations, and unexpected scheduled tasks. Often surfaced by EDR.

File-based IoCs

Artifacts tied to files: hashes (MD5, SHA-256) matching known malware, malicious scripts or droppers, unexpected file modifications, and suspicious file names or paths. Detected with EDR and sandboxing tools.

Behavioral IoCs

Deviations from normal patterns: repeated failed logins (a sign of brute force), logins at unusual times or from unexpected geographies, privilege escalation, unusual admin-account activity, and spikes in database read volume. User and entity behavior analytics (UEBA) is key to spotting these.

Common examples of IoCs

Unusual outbound network traffic or connections to known-malicious IPs and domains.
File hashes matching known malware, or suspicious files in unusual locations.
Geographic irregularities, such as logins from countries where the organization has no presence.
A surge in failed logins or access requests, suggesting brute-force attempts.
Unusual privileged-account activity or requests for additional permissions.
Suspicious registry changes, new admin accounts, or disabled security software.
Anomalous spikes in database read volume, hinting at data exfiltration.

How IoCs are used: detection, investigation, response

IoCs run through the security lifecycle. In detection, known IoCs are loaded into SIEM, EDR, and threat intelligence platforms so that matching artifacts trigger automatic alerts. In investigation, once a suspicious event is flagged, analysts hunt for related IoCs to understand what happened, trace the attacker's movement, and determine the scope of the incident. In response, IoCs guide containment and remediation, blocking malicious IPs, quarantining files, and hunting for the same artifacts elsewhere in the estate.

A vital companion practice is retrospective hunting (retro-hunting): when a new IoC is identified, teams search historical logs and telemetry to find earlier, missed instances of the threat, shrinking attacker dwell time.

Sharing IoCs: STIX, TAXII, and TLP

IoCs become far more powerful when shared, because a breach detected in one organization can protect many others. It's standard practice across the industry to disclose and exchange IoCs, and standardized formats make this automatic and machine-readable. STIX structures the intelligence, TAXII transports it, and the Traffic Light Protocol (TLP) governs how shared information may be redistributed. IoCs are exchanged this way within ISACs, CERTs, and commercial and community threat intelligence feeds, so defenders collectively stay ahead of shared adversary infrastructure.

Limitations and challenges of IoCs

IoCs are essential but have real limits, and honest security programs plan around them. IoC-based detection is inherently reactive: by the time an IoC is found, a compromise has usually already happened, so the goal is to shrink the gap between breach and detection. IoCs are also ephemeral and easily evaded: threat actors rotate IPs, recompile malware to change hashes, and register new domains constantly, so IoC lists go stale quickly and miss novel threats. And sheer volume can overwhelm teams: the number of IoCs generated daily is significant, and poorly qualified observables produce noise. These limits are exactly why IoCs are paired with behavioral detection (IOAs) and why context and qualification matter so much.

Expert insight: Context is what turns an observable into intelligence

The value of an IoC is not the artifact itself; it's the context wrapped around it. An unqualified list of IP addresses and hashes is not threat intelligence: it's a false-positive generator. A raw IP address is merely an observable, and treating that bare technical data as an indicator is a common mistake that floods analysts with noise. What makes an IoC actionable is the analysis behind it: which actor or campaign it belongs to, at what confidence, mapped to which technique, and with what shelf life, plus the ability to act on it across your environment, including retrospectively.

This is central to how Sekoia approaches detection. IoCs on the Sekoia AI SOC platform are not raw observables but qualified, contextualized intelligence: the in-house TDR team analyzes attacker traces and qualifies indicators, so each one carries the context (actor, campaign, kill-chain phase, confidence) that keeps false positives down. That intelligence lives natively in Sekoia Intelligence, modeled in STIX 2.1 and shareable over TAXII, and it powers detection through YARA and SIGMA rules rather than bare blocklists. Because the platform also supports importing external IoC collections and applying them in detection, teams can blend Sekoia's own research with community and commercial feeds, and every new indicator can be retro-hunted across historical events to catch what was previously missed. As a European vendor with a data-sovereignty posture, Sekoia pairs qualified CTI with the operational tooling to act on it. Qualified, contextualized indicators and the ability to operationalize them beat raw IoC volume every time.

‍