IOC vs IOA: Indicators of Compromise Explained

The difference between an indicator of compromise (IOC) and an indicator of attack (IOA) is one of the most useful distinctions in threat intelligence: an IOC is the forensic trace left by an attack that has already happened (a hash, a C2 IP, a malicious domain), whereas an IOA describes the adversary's behaviour while the attack is under way (their intent and their technique), regardless of the specific malware in use.

This guide opens with the IOC vs IOA comparison to settle it in a single sentence, then defines what an indicator of compromise is and which concrete artifacts it covers, explains indicators of attack and their link to TTPs and MITRE ATT&CK, addresses the shelf-life of IOCs, reviews the formats and feeds used to share them (MISP, OTX, STIX/TAXII) and closes by showing how a SOC operationalises both.

IOC vs IOA: the difference in one sentence

An IOC (Indicator of Compromise) is forensic evidence that a system has already been breached: it answers "what happened?". An IOA (Indicator of Attack) describes the sequence of actions an attacker performs to reach an objective: it answers "what are they trying to do?". The IOC is reactive and looks to the past; the IOA is proactive and detects intent in real time, before the damage is done.

What an indicator of compromise (IOC) is

An indicator of compromise is an observable artifact on a network or endpoint that, with reasonable confidence, points to malicious activity. IOCs are atomic data points, easy to search and to share, which is why they are the currency of tactical intelligence. The most common types fall into two families.

File artifacts

• Hashes: MD5, SHA-1 and above all SHA-256 of a malicious binary. An EDR can block an executable by its SHA-256 in seconds.
• Names and paths: a dropper that always writes to C:\Users\Public\svchost.exe, for instance.
• Registry keys: persistence under HKCU\Software\Microsoft\Windows\CurrentVersion\Run or a newly created service.
• Mutexes: mutex names a family uses to avoid infecting the same machine twice.

Network artifacts

• C2 IP: the address of the command and control server.
• Domains and URLs: the domain that serves the second stage or that the implant beacons to.
• TLS fingerprints: JA3/JA3S fingerprints of the client and the server during the handshake.

A useful mental model for classifying IOCs is David J. Bianco's Pyramid of Pain (2013), which ranks indicators by how painful it is for the attacker when you burn them: hashes sit at the base (trivial to change), then IPs, domains and network or host artifacts, and at the top the tools and TTPs (the most expensive to change). The higher you detect, the more you force the adversary to rebuild their operation.

What an indicator of attack (IOA) is

An indicator of attack describes the adversary's behaviour, not the artifact left behind. It does not matter which binary they use or which IP they come from: what gets detected is the logical sequence of actions. Some concrete examples:

• An Office document that launches powershell.exe with a base64-encoded command to download a payload (maps to MITRE ATT&CK T1059.001).
• A process accessing the memory of lsass.exe to dump credentials (T1003.001), whether it uses Mimikatz, comsvcs.dll or a bespoke tool.
• A scheduled task created by a non-administrative account (T1053.005) followed by periodic outbound connections.

An IOA is essentially a TTP (tactic, technique and procedure) expressed as a detection rule. That is why it survives infrastructure changes: even if the attacker rotates the C2 and recompiles the malware to alter the hash, the technique of dumping LSASS stays the same. This is the logic behind TTP-driven threat hunting as opposed to IoC-driven hunting.

IOC vs IOA: comparison

• Nature: an IOC is a static data point (hash, IP, domain); an IOA is a behavioural pattern.
• Timing: the IOC confirms a compromise that already happened; the IOA detects the attack in progress.
• Resilience: IOCs burn quickly; IOAs survive the attacker's infrastructure changes.
• Detection cost: IOCs are cheap to search and automate; IOAs demand detection engineering and context.
• False positives: well-curated IOCs generate few; IOAs, being behaviour-based, need more tuning.

The two are complementary. A mature programme blocks the known with IOCs and hunts the unknown with IOAs.

The shelf-life of IOCs

The Achilles heel of the IOC is its short useful life. An attacker recompiles the binary and the SHA-256 changes; rotates infrastructure and the C2 IP is useless within hours; registers a fresh domain for a few dollars. Feeds age: an IP that is C2 today may be a legitimately reassigned server tomorrow, and keeping a stale indicator generates false positives and noise. That is why IOCs carry confidence and expiration metadata, and platforms decay them automatically over time (the so-called decaying models in MISP). The Pyramid of Pain explains why: the lower the indicator sits, the more ephemeral it is. This is the central argument for investing in behavioural detection too, rather than depending on blocklists alone.

Formats and feeds for sharing intelligence

For an IOC to be useful to the wider community you need a common format and a distribution channel:

• STIX 2.1: a structured language (JSON) for describing indicators, campaigns, actors and relationships. It is the OASIS de facto standard.
• TAXII 2.1: the transport protocol that serves STIX collections over HTTPS (a subscription model).
• MISP: an open sharing platform with its own format, sector communities and decaying models; it exports to IDS (Suricata/Snort), Sigma and STIX.
• OpenIOC: Mandiant's legacy XML schema, still found in older reports.
• Public feeds: AlienVault OTX, the abuse.ch family (URLhaus, ThreatFox, Feodo Tracker, SSLBL), Spamhaus and CISA's AIS programme.

On the detection side, IOCs translate into concrete rules: Snort/Suricata signatures for the network, YARA rules for files and memory, and Sigma rules as a common detection format for the SIEM.

How a SOC operationalises IOC and IOA

The typical workflow in an operations centre follows five steps:

1. Ingestion: feeds arrive at a threat intelligence platform (TIP) such as MISP or OpenCTI, which deduplicates, scores and enriches each indicator.
2. Distribution: the TIP pushes high-confidence IOCs to the SIEM watchlists and to the EDR blocklists.
3. Retro-hunting: every new IOC is also searched across historical logs, in case the compromise predates the indicator's publication.
4. IOA detection: in parallel, the detection engineering team writes behavioural rules (Sigma, EDR rules) mapped to MITRE ATT&CK that do not depend on specific indicators.
5. Sightings and feedback: when an IOC is observed in the environment a sighting is recorded, which adjusts its confidence and feeds back to the community.

One example ties both worlds together: in the exploitation of Log4Shell (CVE-2021-44228), the IOC is the JNDI string in a log or the malicious LDAP IP, while the IOA is the Java process spawning a child shell, anomalous behaviour that is detected even if the attacker changes their infrastructure entirely. Early visibility of indicators in closed sources is reinforced by dark web monitoring and by tracking families such as infostealers.

Frequently asked questions

What is the difference between IOC and IOA?

An IOC is evidence that a compromise already happened (a hash, an IP, a domain). An IOA describes the attacker's behaviour and intent while the attack is under way, regardless of the malware or infrastructure used. The IOC looks to the past; the IOA detects in real time.

Why do indicators of compromise expire?

Because the attacker changes them easily: recompiling the binary (new hash), rotating the C2 (new IP) or registering fresh domains. On top of that, an old indicator can be reassigned to a legitimate resource and trigger false positives, so it is given an expiration date.

Which formats are used to share IOCs?

The most common are STIX 2.1 (description) over TAXII 2.1 (transport), the MISP platform with its own format, the legacy OpenIOC, and feeds such as AlienVault OTX or abuse.ch. For detection they translate into Snort/Suricata, YARA and Sigma rules.

Is it better to detect with IOCs or IOAs?

It is not an either/or choice. IOCs are cheap and block known threats immediately; IOAs resist infrastructure changes and detect techniques rather than artifacts. A mature programme combines both.

What is the Pyramid of Pain?

It is a model by David J. Bianco (2013) that ranks indicators by how costly it is for the attacker when you detect them: hashes and IPs at the base (easy to change) and tools and TTPs at the top (very expensive to change). Detecting higher up causes the adversary more pain.

Related resources

• What is the Cyber Kill Chain: where indicators fit within the phases of an intrusion.
• What is threat hunting: IoC-driven versus TTP-driven hunting.
• What is YARA: how file-based IOCs become detection rules.
• What is a SIEM and what is an EDR: where indicators are operationalised.

IOC and IOA at Secra

At Secra we embed tactical intelligence into our clients' operations: we curate feeds, deploy and tune MISP and OpenCTI platforms and turn indicators and behaviours into actionable detection rules for the SIEM and the EDR. If you want to enrich your SOC with useful threat intelligence and a low false-positive rate, get in touch through contact or check our threat intelligence service.