Indicators of Compromise: Identification and Use

IOCs are not a single category of evidence. They range from cryptographic file hashes that precisely identify a single file, through network addresses and domain names, to behavioural patterns that describe what an attacker does rather than which specific tool they used. The pyramid of pain provides a practical way to think about this range: it orders IOC types from the base (easiest for an attacker to change) to the apex (hardest to change).

In practice, investigators collect all IOC types. Hash values and IP addresses are operationally useful for immediate blocking even if their long-term value is low. Host artefacts and TTPs feed longer-lived detection rules and threat actor attribution. A forensic report that provides only hashes and IPs has limited intelligence value; one that maps findings to the MITRE ATT&CK framework provides defenders with detection logic that outlasts the specific incident.

IOC identification during an active forensic investigation follows a structured sequence. The investigator begins with triage: identifying the affected systems, preserving volatile evidence (running processes, network connections, memory), and establishing a timeline. IOC candidates emerge from this triage before the full forensic image is collected.

Network-layer IOCs are typically the first to surface. Firewall logs and NetFlow records show external connections. A connection to an IP address that has no business justification, particularly on unusual ports or at unusual hours, is an IOC candidate. DNS query logs show which domains a host has resolved. A domain that resembles a legitimate service but uses a different registrar, a recently registered date, or a non-standard TLD is a candidate for further investigation. Tools such as Zeek (formerly Bro) and Suricata produce structured logs that can be searched automatically against known-bad IOC feeds.

Host-layer IOCs require examination of the file system, registry, process list, and system logs. Key artefact sources include: the Windows registry (autorun keys such as HKCU\Software\Microsoft\Windows\CurrentVersion\Run are common persistence locations), scheduled tasks and services (malware commonly installs a service or scheduled task with a name designed to blend in with legitimate Windows processes), prefetch files (show execution history for processes on Windows systems), and the Windows Event Log (logon events, process creation events when Sysmon is installed, and PowerShell logging capture much of what attackers do on a Windows host).

A raw IOC candidate is not yet intelligence. Validation determines whether the artefact is genuinely malicious or a false positive. Contextualisation adds the information that makes the IOC actionable: what threat actor or malware family it is associated with, how recently it was active, and how confident the attribution is.

For file hashes, validation is straightforward: submit the hash to VirusTotal or a similar multi-engine service. A hash with detections from multiple reputable engines is confirmed malicious. A hash with zero detections may be a novel sample, a legitimate file, or a targeted tool not yet seen in the wild. Novel samples with zero detections require manual or sandbox analysis before they can be treated as malicious IOCs. For IP addresses and domains, passive DNS services, BGP routing history, and WHOIS records provide context: registration date, registrar, autonomous system, and historical resolution records can confirm or contradict the initial suspicion.

Threat intelligence platforms enrich IOCs automatically by cross-referencing them against known campaigns and threat actors. A C2 IP address that appears in three previously reported APT28 campaigns is a much higher confidence IOC than one seen only once. Enrichment also flags IOCs that are no longer active: a C2 server that was taken down twelve months ago is not worth spending detection resources on, though it remains relevant for historical attribution.

False positive management is an underrated part of IOC validation. A shared IP address used by a major CDN, a domain used by a legitimate SaaS product, or a common DLL hash can generate enormous alert noise if added to a blocklist without validation. Every IOC should carry a confidence score and a source rating before it is operationalised. The Traffic Light Protocol (TLP) provides a standard for marking the permitted distribution of sensitive IOC data: TLP:RED restricts sharing to the named recipients; TLP:AMBER permits sharing within an organisation and with trusted partners; TLP:GREEN permits sharing within a community; TLP:CLEAR permits unrestricted sharing.

IOC sharing between organisations is the mechanism that converts a single organisation's painful incident into a community-wide detection capability. The main technical standards for structured sharing are STIX 2.1 and TAXII 2.1, both maintained by OASIS. STIX defines the data model: a Threat Actor object, an Indicator object, a Malware object, and a Relationship that connects them. TAXII defines the API that allows clients to query a STIX server for new intelligence objects and push their own findings to the server.

MISP (Malware Information Sharing Platform) is the most widely deployed open-source implementation. National CERTs across Europe, sectoral ISACs in finance, energy, and healthcare, and many large enterprises run MISP instances and connect them into sharing communities. CERT-In in India, NCSC in the UK, CISA in the US, and ENISA at the EU level all operate or participate in structured IOC sharing programmes. The EU Network and Information Security 2 Directive (NIS2, 2022) places explicit obligations on operators of essential services in EU member states to share threat intelligence with national CERTs.

Legal constraints on IOC sharing vary by jurisdiction. In the US, the Cybersecurity Information Sharing Act 2015 (CISA 2015) provides liability protection for private entities that share cyber threat indicators with the federal government and with each other, provided the sharing follows the Act's procedures. In the UK, sharing under the NCSC's Cyber Security Information Sharing Partnership (CiSP) is covered by specific government guidance on liability. In India, the Information Technology Act 2000 and its 2008 amendment, together with the Digital Personal Data Protection Act 2023, govern what information about a breach may be disclosed and to whom. IOC data that includes personal information (such as email addresses of phishing targets) attracts data protection obligations in all jurisdictions.

Sophisticated attackers treat IOC exposure as an operational risk and build their tooling and infrastructure to minimise the useful life of any indicator. Understanding these evasion techniques helps investigators prioritise higher-durability IOC types and adjust their detection strategy accordingly.

At the file hash level, attackers use polymorphic packers that repack the same underlying payload each time it is compiled, changing the hash with every build. They also add junk bytes or modify metadata to change the hash without altering functionality. Fuzzy hashing with SSDEEP or TLSH partially counters this by identifying structural similarity even when the exact hash differs, and YARA rules that match on byte sequences within the file rather than the whole-file hash are more durable than hash-only detection.

At the network level, IP rotation is cheap. Bulletproof hosting providers in jurisdictions with limited law enforcement cooperation allow rapid redeployment of C2 infrastructure. Fast-flux DNS changes the IP address a domain resolves to every few minutes, so blocklisting the IP is ineffective even if the domain itself is identified. Domain generation algorithms generate thousands of candidate C2 domains from a seed value (often the current date), so the malware can find an active C2 even if most of the generated domains have been blocklisted. Defenders counter DGAs by reverse-engineering the generation algorithm and pre-registering or pre-sinkholing the generated domains.

Living-off-the-land (LotL) techniques represent a deeper form of IOC evasion. Instead of deploying custom malware, the attacker uses tools already present on the victim system: PowerShell, WMI, certutil, and other built-in Windows utilities. These tools have legitimate uses and are not themselves IOCs. Detection requires behavioural analysis of how the tool is being used: certutil downloading a file from an external domain, or PowerShell executing a base64-encoded command, are suspicious patterns even though both binaries are legitimate system files.

IOCs collected during a forensic investigation may form part of the evidence in a criminal prosecution or a civil proceeding. Their admissibility depends on the same requirements that apply to any digital evidence: the collection process must be documented, the chain of custody must be maintained, and the investigator must be able to demonstrate that the evidence has not been altered since collection.

In India, the Bharatiya Sakshya Adhiniyam 2023 (which replaced the Indian Evidence Act 1872) governs the admissibility of electronic records. Section 63 requires that electronic records be accompanied by a certificate from a person responsible for the device, attesting to the conditions of the device and the manner in which the record was produced. For IOC evidence such as network log exports or memory captures, this certificate must describe how the log was generated, what tools were used to collect it, and whether any filtering or transformation was applied before the export was preserved. In the US, the Federal Rules of Evidence (Rule 901 and Rule 902(13)/(14)) require authentication of electronic records; expert testimony from the forensic examiner who collected the IOC data satisfies this requirement. In the UK, the Police and Criminal Evidence Act 1984 and the Criminal Procedure Rules govern digital evidence handling.

Attribution is the most contested aspect of IOC use in legal proceedings. An IOC places a particular tool or infrastructure at the scene of a crime; it does not by itself identify the human being who controlled that infrastructure. Threat actor attribution relies on clustering multiple IOCs across multiple incidents to identify consistent patterns that point to a specific group, and then correlating those technical findings with other intelligence. Courts in multiple jurisdictions have accepted such technical attribution evidence, but it is typically presented alongside other forms of evidence rather than standing alone.