What Are Indicators of Compromise (IOCs)? The Complete Guide

What IOCs Are and How They Are Used

Indicators of Compromise are forensic artifacts that, when observed in a system or network, provide evidence that unauthorized access or malicious activity has occurred. They are the digital equivalent of physical evidence at a crime scene — the traces left by attacker activity that investigators use to determine what happened, what was accessed, and how the attack progressed.

IOCs fall into several technical categories. File-based IOCs are hashes of malicious files — the unique cryptographic fingerprints of known malware samples that can be checked against files found in an environment. If a file's SHA-256 hash matches a known ransomware payload, that file is a confirmed indicator of malicious activity. Network-based IOCs include IP addresses, domain names, and URLs associated with attacker command-and-control infrastructure, malware distribution, or exfiltration endpoints. Email-based IOCs include sender addresses, subject lines, and header patterns associated with phishing campaigns. And behavioral IOCs — sometimes called Indicators of Behavior or IOBs — are patterns of activity that indicate malicious behavior regardless of specific file or network artifacts: LSASS memory access by unexpected processes, execution of encoded PowerShell commands, or anomalous volume of file encryption operations.

IOCs vs. TTPs: The Pyramid of Pain

Security researcher David Bianco's Pyramid of Pain is the essential framework for understanding IOC value. The pyramid categorizes defensive indicators by how difficult it is for an attacker to change them after they are detected and blocked. Hash values are at the base — trivially easy for attackers to change by modifying a single byte of their malware. IP addresses are slightly harder to change but still straightforward. Domain names require more effort but remain easy with automated infrastructure. Tactics, Techniques, and Procedures — TTPs, the behavioral patterns of an attacker — are at the apex. Forcing an attacker to change their TTPs requires them to fundamentally change their operational approach, which is genuinely costly.

The practical implication is that IOC-based detection focused on file hashes and IP addresses is easily evaded — attackers routinely rotate infrastructure and recompile malware to change hash values. Detection focused on TTPs — behavioral patterns that remain consistent even as specific files and infrastructure change — is far more durable. This is the theoretical foundation of behavioral detection in modern EDR platforms.

How IOCs Are Used in Security Operations

IOCs are used in two primary ways: proactively, to detect threats before they cause damage, and reactively, to investigate and scope breaches after they are detected.

Proactive IOC use involves ingesting threat intelligence feeds containing known IOCs — malware hashes, C2 infrastructure IP addresses and domains, phishing infrastructure — into security tools that check observed activity against those indicators in real time. When a network connection attempt matches a known C2 IP address, the connection is blocked and an alert is generated. When a file hash matches a known malware sample, execution is blocked. This is how threat intelligence operationalizes into concrete detection and prevention.

Reactive IOC use involves hunting for IOCs in an environment after a breach is suspected or confirmed — searching log data, endpoint telemetry, and network records for file hashes, IP connections, and behavioral patterns associated with the suspected threat actor. This process — IOC-based threat hunting — determines the scope of a breach: which systems were touched, what data was accessed, how long the attacker was present, and what persistence mechanisms they may have left behind.

Where IOCs Come From: Threat Intelligence Sources

IOCs originate from multiple sources of varying quality and timeliness. Security vendors generate IOCs from their own telemetry — CrowdStrike, SentinelOne, and Microsoft all maintain proprietary threat intelligence that feeds into their platforms' detection capabilities. Government and ISAC sources — CISA's Known Exploited Vulnerabilities catalog, FBI flash alerts, sector-specific ISACs — publish IOCs from active investigations and incident response engagements. Open-source threat intelligence platforms like VirusTotal, MISP, and OTX aggregate community-contributed IOC data. And commercial threat intelligence providers offer curated, contextualized IOC feeds with attribution data and tactical guidance.

IOC quality varies enormously. Stale IOCs — indicators from infrastructure that attackers have long since abandoned — generate false positives without catching current threats. Uncontextualized IOCs — IP addresses without information about what threat actor uses them or what attack phase they represent — are difficult to triage effectively. High-quality threat intelligence provides IOCs with context: attribution, confidence level, associated campaign, and recommended response action.

IOCs in M&A Due Diligence and Incident Response

For PE operating partners, IOCs have a specific application in M&A due diligence that most diligence processes do not leverage. A proactive IOC hunt against an acquisition target's environment — searching endpoint telemetry and network logs for indicators associated with known threat actors, recent campaigns, and high-profile malware families — can identify evidence of pre-existing compromise before the deal closes.

Post-acquisition IOC hunts have found evidence of long-dwell intrusions that predated the deal by months, data exfiltration campaigns that were ongoing at deal close, and persistence mechanisms left by threat actors who had been evicted from the environment but had re-established access through backup channels. These findings are material to deal valuation, post-close integration planning, and the acquiring organization's own risk exposure through network connectivity to the newly acquired entity.

In incident response, IOCs are the forensic foundation of scope determination. The question "what did the attacker access?" is answered by tracing the attacker's activity through IOC evidence: which systems communicated with C2 infrastructure, which files matching known malware hashes were present and for how long, which accounts showed behavioral patterns matching the attacker's observed TTPs. Without this evidence, scope determination is guesswork, and the completeness of remediation cannot be verified.