Indicators of Compromise
What they are and how blue teams use them
Indicators of Compromise — IOCs — are artifacts observed on a system or network that suggest malicious activity has occurred or is underway. They are the most operationally immediate form of threat intelligence: specific, actionable, and directly applicable to detection and response workflows.
Despite being one of the most frequently cited concepts in security operations, IOCs are often used loosely. Understanding what they are, what types exist, and where they fall short is foundational for any analyst working in detection or incident response.
Types of IOCs
IOCs span several categories, each with different detection use cases and different rates of decay:
- File hashes (MD5, SHA-1, SHA-256) — the most precise IOC type. A hash uniquely identifies a specific file. If a known malicious binary matches a hash in your environment, the match is high confidence. The limitation: recompiling or trivially modifying the file produces a different hash entirely, making this indicator trivial for attackers to evade.
- IP addresses and domains — infrastructure indicators. A known C2 IP or a domain registered for phishing can be blocked or alerted on. These age out quickly — attackers rotate infrastructure regularly, and shared hosting means a malicious IP may also serve legitimate traffic.
- URLs and URI patterns — more specific than domains alone. A particular URL path associated with a web shell or a malware download location is a narrower, more actionable signal than the root domain.
- Email artifacts — sender addresses, subject line patterns, header fields, and attachment names associated with phishing campaigns. Useful in email gateway rules but prone to impersonation and variation across campaigns.
- Registry keys, file paths, and mutex names — host-based persistence indicators. Malware often creates predictable artifacts at known locations. These are more durable than network indicators but require endpoint visibility to detect.
How Blue Teams Operationalize IOCs
Raw IOCs have no operational value until they are ingested into systems that can act on them. The typical pipeline:
- Ingestion into a SIEM or threat intel platform. IOCs from threat feeds, incident reports, and vendor bulletins are imported and enriched with context — source, confidence level, expiry date, and associated campaign or actor if known.
- Matching against log data. SIEM rules query ingested logs for matches against IOC lists — known malicious IPs in firewall or proxy logs, file hashes in endpoint telemetry, domains in DNS query logs. A match generates an alert.
- Blocklisting at enforcement points. High-confidence IOCs — particularly domains and IPs — can be pushed to DNS sinkholes, firewall blocklists, or proxy deny lists for automated prevention rather than just detection.
- Retrospective hunting. Newly published IOCs associated with a campaign can be run against historical log data to determine whether the activity occurred in the environment before the indicator was known.
The Limitations That Matter
IOC-based detection is necessary but not sufficient. Two limitations consistently affect its reliability in practice:
IOCs go stale. An IP address active in a campaign last month may be reassigned or abandoned today. File hashes from a sample published six months ago may not match the variant in current circulation. Without expiry dates and active curation, IOC lists accumulate noise and eventually produce more false positives than detections.
Sophisticated actors change indicators deliberately. Nation-state groups and mature criminal operations regularly rotate domains, regenerate binaries, and change infrastructure specifically to defeat IOC-based detection. Relying on IOCs alone against these actors means detecting the previous campaign, not the current one.
This is why behavioral detection — identifying attacker techniques and patterns rather than specific artifacts — is more durable. IOCs answer the question has this specific thing appeared in my environment; behavioral rules answer has something behaved in a way consistent with this technique. Both have a place. Neither replaces the other.
Defensive Takeaways
Enrich IOCs with context before acting on them
A bare IP or hash with no source, confidence level, or expiry date is difficult to triage. Prioritize feeds and platforms that provide context alongside the indicator — campaign association, first/last seen dates, and confidence scoring all inform whether a match is worth investigating.
Set expiry policies on IOC feeds
Indicators without expiry accumulate indefinitely. Old, stale IOCs generate false positives and erode analyst confidence in the detection pipeline. Most threat intel platforms support TTL settings per feed; use them.
Use IOCs as one layer, not the whole program
IOC matching is reactive by nature — it detects known artifacts from past activity. Pair it with behavioral detection rules and ATT&CK-mapped coverage to maintain visibility against threats that do not match any known indicator.