What is an IOC (Indicator of Compromise)?
An IOC (Indicator of Compromise) is an observable technical trace, such as a hash value, IP address, domain name or file path, that indicates that a system or network has been or is being attacked. IOCs emerge from the analysis of an incident or a malware sample and are then shared, so that other organisations can recognise the same attack in their own environment. Security teams such as a CSIRT, CERT or SOC use IOCs to detect attacks, stop their spread, determine the root cause and clean up affected systems. In both IT and OT environments, they form the first and most concrete layer of threat intelligence.
🎯 Why do you use IOCs?
An IOC answers one simple question: has this attacker been in our network too? That makes IOCs useful in every phase of incident handling:
- Detection - automatically searching logs, network traffic and endpoints for known malicious hashes, IP addresses and domains
- Prevention - blocking malicious addresses and domains in a firewall, proxy or DNS filter
- Investigation - establishing during forensic analysis which systems were affected and since when
- Retrospective searching - using new IOCs to search back through old log data, the starting point of much threat hunting
- Sharing - turning the knowledge of one victim into protection for a whole sector
The IETF described this role in August 2023 in RFC 9424: IOCs are cheap, scalable and support multiple layers of defence in depth. That is exactly why organisations with limited capacity benefit so much from them.
🧱 What types of IOCs are there?
IOCs are usually divided into three groups: atomic indicators (a single data point), computed indicators (derived from data, such as a hash) and behavioural indicators (a combination of events).
| IOC type | Group | Example |
|---|---|---|
| IP address | Atomic | Traffic to a suspicious address (e.g. 198.51.100.42) |
| Domain name / URL | Atomic | Connection to malicious-update[.]net |
| Hash value | Computed | SHA-256 (64 hexadecimal characters) of a malicious file or script |
| File path | Atomic | C:\Users\Public\svchost.exe (a legitimate name in the wrong place) |
| Registry entry | Atomic | Suspicious autorun key in the Windows Registry |
| Email indicator | Atomic | Sender, subject or attachment of a phishing campaign |
| User behaviour | Behavioural | Login outside working hours from an unknown location |
| SCADA/OT-specific | Behavioural | Unexpected change of a setpoint, communication with an unknown PLC |
Reports often write domain names defanged ([.] instead of ., hxxp instead of http), so that nobody clicks a malicious link by accident. The IP
address in the example comes from a range reserved specifically for documentation.
🧠 How does an IOC work in practice?
RFC 9424 describes the lifecycle of an IOC in seven stages: discovery, assessment, sharing, deployment, detection, reaction and end of life. According to the RFC, an IOC without context is of little use: you need to know which attacker, campaign and period it belongs to, and how reliable the source is.
Established standards and conventions exist for exchanging and detecting them:
| Standard | Role | Characteristic |
|---|---|---|
| STIX 2.1 | Language and JSON format for threat information (OASIS) |
Standard since 10 June 2021; the Indicator object requires a pattern, pattern_type and valid_from
|
| TAXII 2.1 | Protocol for exchanging STIX data over HTTPS | Collections from which systems fetch new indicators automatically |
| MISP | Open-source platform for storing and sharing IOCs | Started in 2011 at the Belgian Defence, development now led by CIRCL (Luxembourg) |
| TLP 2.0 | Agreement on how far you may pass information on | Labels RED, AMBER, AMBER+STRICT, GREEN and CLEAR (FIRST, since August 2022) |
| YARA / Sigma / Snort | Detection rules | YARA for files, Sigma for logs, Snort and Suricata for network traffic |
A STIX indicator for a malicious file looks like this, for example: [file:hashes.'SHA-256' =
'4bac…f877']. An expiry date (valid_until) allows an IOC to lapse automatically.
That prevents a SIEM from raising alarms for years
on an IP address that has since been reassigned to an innocent party.
🔄 How does an IOC relate to IOAs and TTPs?
An IOC tells you what has been left behind; an IOA (Indicator of Attack) tells you what an attacker is trying to do right now. The term IOA is mainly used by vendors of EDR solutions. Above both sit the TTPs: an attacker’s consistent way of working, as captured in MITRE ATT&CK for ICS.
| Characteristic | IOC | IOA | TTP |
|---|---|---|---|
| Question | Which traces are there? | What is happening now? | How does this attacker operate? |
| Example | Hash of a malware file | Attempted privilege escalation | Credential dumping followed by lateral movement |
| Timing | Often after the fact, or as a blocklist beforehand | During the attack | Across multiple attacks |
| Shelf life | Short: easy to change | Medium | Long: hard to change |
David Bianco’s Pyramid of Pain (2013) makes that difference visible. Changing a single bit in a file changes its hash, and an IP address or domain is quickly replaced, but adopting a different way of working costs an attacker a lot of effort. RFC 9424 stresses, however, that fragile IOCs are not worthless: they are cheap to deploy and force an attacker to keep changing their tooling.
🏭 What do IOCs look like in OT environments?
Classic IOCs work less well in industrial networks. Little endpoint software runs there, many systems are outdated, and attackers increasingly use legitimate tools. Volt Typhoon, for example, hardly uses malware and works by living off the land, leaving few hashes or files to search for. OT detection therefore relies more on behaviour compared with a known baseline:
- Traffic between SCADA and unknown external IP addresses
- A change to a setpoint outside an authorised session
- A PLC that has been silent for years suddenly communicating, or a new program download to a PLC
- Firmware updates without planning or change documentation
- Newly created users on HMI systems or an engineering station
- Write commands over Modbus TCP from an address that never sent them before, the pattern of FrostyGoop (Lviv, January 2024)
🔧 In combination with SIEM, IDS, passive network monitoring or asset monitoring tools, IOCs and anomalous behaviour can be detected and investigated automatically.
Network-based IOCs are especially valuable in OT. RFC 9424 notes that they protect devices that cannot run endpoint software, such as IoT. With DNS monitoring and network sensors at the edge of the OT zone, you can check traffic without installing anything on the PLCs.
🔐 How do you use IOCs responsibly?
A practical approach for an industrial organisation in the Netherlands or elsewhere in the EU:
- Choose reliable sources - the Dutch NCSC, your sector ISAC, CERT-WM for the Dutch water boards, CISA advisories and reports from OT security vendors such as Dragos.
- Automate the intake - let IOCs arrive via TAXII or MISP and connect them to the SIEM, firewall and NDR, instead of copying lists by hand.
-
Add context and an expiry date - record the source, confidence, TLP label and a
valid_untilfor each IOC. - Test passively first - in OT, never start by blocking automatically: a false positive on a process connection can stop production. Start with alerting.
- Search back as well - keep enough log data to check new IOCs against months of history.
- Supply IOCs when reporting an incident - under NIS2 (Article 23), the incident notification within 72 hours includes the IOCs where available. The same applies to incident reporting under the Dutch Cybersecurity Act, in force since 15 August 2026.
This links IOCs to the incident response process, which NIST described anew in April 2025 in SP 800-61 Revision 3.
❓ Frequently asked questions
What is the difference between an IOC and an IOA?
An IOC is a trace left behind after or during an attack, such as a malicious hash or an IP address. An IOA describes attacker behaviour that is still in progress, such as an attempt to escalate privileges. IOAs help detect an attack earlier, while IOCs are more concrete and easier to share.
How long does an IOC remain useful?
How long an IOC remains useful depends on its type. Hashes and IP addresses often age quickly because attackers can easily replace them, while behavioural indicators and TTPs last much longer. Give every IOC an expiry date and remove expired indicators.
Where can I find reliable IOCs for OT?
Reliable IOCs for OT come from the NCSC, sector ISACs, CERT-WM for the Dutch water boards, CISA advisories and reports from specialised OT security firms. Choose sources that supply context, such as the attacker and the time period, and that use a TLP label.
What is STIX and how does it relate to IOCs?
STIX is a standardised JSON language from OASIS for exchanging threat information, with version 2.1 a standard since June 2021. An IOC is recorded in STIX as an Indicator object with a detection pattern and a validity period. Using the TAXII protocol, systems can fetch those indicators automatically.
Can I block IOCs automatically in an OT network?
Blocking automatically on IOCs is risky in an OT network, because a false positive can break a process connection. The usual approach is to alert and assess first, and only block at the edge of the OT zone, such as in the DMZ. Within the process networks themselves, passive detection remains the norm.
Do I have to report IOCs after a cyber incident?
Yes, under NIS2 and the Dutch Cybersecurity Act, the incident notification within 72 hours should include the IOCs where available. The CSIRT can then share those indicators with other organisations in the sector, under the appropriate TLP label.
📌 In summary
An IOC is a concrete technical trace, such as a hash, IP address or domain, that points to a possible cyberattack or breach. IOCs are the basis for detection, analysis and response in both IT and OT environments, but they are short-lived: combine them with context, an expiry date and behaviour-based detection of TTPs within a defence-in-depth strategy.