Indicator of Compromise (IoC)

An Indicator of Compromise (IoC) is a technical artefact or observable that provides evidence of malicious activity or that a system has been compromised. IoCs are derived from incident analysis, threat intelligence research, and malware reverse engineering. Common IoC types include: file hashes (MD5, SHA-256) of known malicious files; IP addresses and domains associated with command-and-control infrastructure; URLs of malware distribution sites; registry keys created by malware; network traffic signatures; user agent strings used by exploit tools; and behavioural patterns such as unusual process spawning sequences. IoCs are shared between organisations via platforms like MISP (Malware Information Sharing Platform), OpenCTI, and commercial threat intelligence feeds, enabling broad-based detection of known threats.

For manufacturers subject to CRA Article 14, IoCs play a critical role in detecting whether a vulnerability in their product is being actively exploited — the trigger for the 24-hour notification obligation. Sources of product vulnerability IoCs:

• Honeypot telemetry: Organisations like Shadowserver and GreyNoise operate honeypots that detect active exploitation attempts and share IoCs publicly.
• CERT/CSIRT feeds: National CSIRTs share IoCs related to confirmed exploitation campaigns through member feeds and public advisories.
• Commercial threat intelligence: Vendors such as Recorded Future, Mandiant, and CrowdStrike publish IoCs for known exploitation campaigns.
• Researcher disclosure: Security researchers often share IoCs (e.g., proof-of-concept exploit hashes, attacker infrastructure) when disclosing vulnerabilities.

Manufacturers should monitor these sources for IoCs related to their product technology stack to minimise time-to-detection for active exploitation.

IoCs have a defined lifecycle in incident detection and response:

1. Collection: IoCs are gathered from threat intelligence sources, incident analysis, and community sharing platforms.
2. Ingestion: IoCs are ingested into the SIEM or threat intelligence platform, where they are matched against logs and telemetry.
3. Detection: When a match is found (e.g., a log entry contains a known-malicious IP address), an alert is generated.
4. Investigation: SOC analysts investigate the alert to confirm whether a genuine incident has occurred or whether it is a false positive.
5. Triage and escalation: Confirmed incidents involving product vulnerability exploitation are escalated to the PSIRT, which assesses whether a CRA Article 14 notification is required.
6. Response: Containment and remediation actions are taken; ENISA notification is submitted within 24 hours if active exploitation is confirmed.
7. IoC sharing: After the incident, new IoCs identified during investigation are shared with the threat intelligence community to benefit others.

IoCs have important limitations: they represent known attacker infrastructure and tools. Sophisticated attackers regularly change IP addresses, domains, and malware hashes to evade IoC-based detection. This is why the cybersecurity community has progressively moved from purely IoC-based detection to TTP (Tactics, Techniques, and Procedures) based detection using frameworks like MITRE ATT&CK. TTP-based detection identifies attacker behaviour patterns rather than specific artefacts — behaviour patterns are much harder for attackers to change. For CRA manufacturers, this means:

• IoC-based detection is a useful first layer but should not be the only detection mechanism.
• SIEM detection rules should include TTP-based behavioural detections alongside IoC signature matches.
• When a vulnerability in the product's technology stack is published, manufacturers should identify the likely exploitation TTPs and develop detection rules that would fire if those techniques were used against their infrastructure or products.