An Indicator of Compromise (IoC) is forensic evidence — a file hash, IP address, domain, registry key, or behavioral pattern — that shows a system has been or is currently being compromised. IoCs are the artifacts an attacker leaves behind: a malicious executable's SHA-256 hash, a command-and-control server's IP, a persistence mechanism in the registry, a process quietly encrypting thousands of files. Security teams collect them from threat intelligence feeds and internal detections, then search across their environment to find every system touched by the same attack.
That's the summary an AI overview gives you. It's also where most explanations stop — before the part that actually matters operationally: which IoC types are worth trusting, how they differ from Indicators of Attack (IoA), and why an indicator that's gold today can be worthless in a week. That's what this article covers.
The four IoC categories, and where each one gets caught
Every IoC falls into one of four categories, and each tends to get caught by a different layer of your stack. Mapping category to detection source is what turns "we have a feed of indicators" into "we have a pipeline that actually fires alerts."
<rect x="410" y="55" width="200" height="60" rx="8" fill="#2813e8"/>
<text x="510" y="80" font-size="13" font-weight="bold" fill="#ffffff">Network-Based</text>
<text x="510" y="98" font-size="10" fill="#c7d2fe">IPs, domains, URLs</text>
<rect x="30" y="285" width="200" height="60" rx="8" fill="#2813e8"/>
<text x="130" y="310" font-size="13" font-weight="bold" fill="#ffffff">Host-Based</text>
<text x="130" y="328" font-size="10" fill="#c7d2fe">registry keys, processes</text>
<rect x="410" y="285" width="200" height="60" rx="8" fill="#2813e8"/>
<text x="510" y="310" font-size="13" font-weight="bold" fill="#ffffff">Behavioral</text>
<text x="510" y="328" font-size="10" fill="#c7d2fe">traffic & process anomalies</text>
<rect x="250" y="170" width="140" height="60" rx="8" fill="#0f766e"/>
<text x="320" y="195" font-size="13" font-weight="bold" fill="#ffffff">Detection</text>
<text x="320" y="211" font-size="13" font-weight="bold" fill="#ffffff">Pipeline</text>
| IoC Type | Examples | Typical Detection Source |
|---|---|---|
| File hash | MD5/SHA-256 of a known-malicious binary | EDR / antivirus |
| File path or name | C:\AppData\Roaming\svchost.exe masquerading as a system process | EDR / forensic imaging |
| Malicious IP address | Command-and-control server at 203.0.113.45:8080 | Firewall / network monitoring |
| Malicious domain or URL | Phishing kit host or malware download link | DNS logs / secure web gateway |
| Registry key | Persistence entry added to Run or RunOnce keys | Host forensics / EDR |
| Process or DLL name | Injected library loaded into explorer.exe | EDR / memory forensics |
| Scheduled task | New task re-launching a payload hourly | Host forensics / SIEM |
| User-agent string | Malformed or scripted UA hitting login endpoints | WAF / web server logs |
| Behavioral pattern | Mass file rewrite consistent with ransomware encryption | EDR / anomaly detection |
File-based and host-based IoCs are cheap to detect and hard for attackers to fake — a hash either matches a binary or it doesn't. Network-based IoCs are the easiest to collect and the fastest to go stale, which is the subject of the next section.
Pulling these out of a raw log dump, email header, or incident report by hand is tedious and error-prone — the extractor above parses hashes, IPs, domains, and file paths out of pasted text automatically, entirely client-side.
IoC vs. IoA: reactive evidence vs. proactive intent
The distinction that separates a mature detection program from a feed-matching exercise is IoC vs. IoA. They aren't competitors — they answer different questions at different points in the attack timeline.
| IoC (Indicator of Compromise) | IoA (Indicator of Attack) | |
|---|---|---|
| Answers | "Did this happen?" | "Is this happening?" |
| Timing | Reactive — found after (or during) compromise | Proactive — observed as the attack unfolds |
| Focus | Technical artifacts left behind | Attacker behavior and intent |
| Example | A known-bad file hash on disk | A process attempting credential dumping via LSASS access |
| Maps to | A static signature or blocklist entry | MITRE ATT&CK tactics and techniques |
| Detected by | AV/EDR signature match, SIEM correlation on a known bad value | Behavioral analytics, EDR heuristics, UEBA |
| Which matters more | Confirms scope after the fact — essential for closing an incident and hunting related compromise | Stops an attack mid-execution — essential for catching damage before it happens |
Neither wins alone. A useful shorthand: an IoC tells you a burglar was in the house; an IoA is the sound of the window breaking. You want to hear the window — but once it's broken, you still need to know exactly what was taken. Programs that only match IoCs are permanently one step behind; programs that only watch behavior have no fast, cheap way to triage a known threat. Use both.
Why network IoCs decay and file hashes don't
Not every IoC ages the same way, and treating a six-month-old IP address feed as current is one of the more common — and preventable — mistakes in threat intel operations. Attackers rotate infrastructure specifically because it's cheap for them and expensive for defenders who don't re-verify.
A hash requires the attacker to recompile or repack the payload to evade it, which takes real effort. An IP or domain requires nothing more than switching to the next box in a bulletproof-hosting rotation — something commodity crimeware kits automate. Treat network-based IoCs as perishable inventory, not permanent records: re-verify age and last-seen date before you act on one, and prefer feeds that report a decay or confidence score over static lists.
How analysts turn IoCs into a closed incident
- Detect — malware, a phishing report, or an alert surfaces the initial evidence.
- Extract — pull every hash, file path, domain, IP, and registry artifact tied to the incident.
- Search — sweep the environment (EDR, SIEM, firewall logs, DNS logs) for every one of those IoCs.
- Scope — build the list of every system that matched at least one indicator.
- Pivot — investigate what else those systems did: lateral movement, data staging, additional persistence.
- Contain and remediate — isolate affected hosts, remove persistence, address any credential compromise by rotating exposed passwords and tokens, and restore from clean backups where needed.
- Harden — turn the confirmed IoCs into blocklist entries and detection rules so the same artifacts trigger automatically next time.
Worked example: one ransomware alert becomes a full sweep
Scenario: EDR flags ransomware behavior on a single workstation.
IoCs extracted from that host:
- File hash:
5a7f6b8d9c2e1f4a... - File path:
C:\AppData\Roaming\malware.exe - C2 domain:
malicious-domain[.]com - Process name:
svchost.exerunning fromAppData(a location the realsvchost.exenever runs from)
Sweep across the fleet:
- Every system with a file matching that hash → likely already compromised.
- Every system that resolved or connected to that C2 domain → likely compromised or targeted.
- Every system running a process named
svchost.exefromAppData→ same masquerading technique, possibly a different payload.
A single-host alert becomes a fleet-wide scope determination in minutes — which is the entire value proposition of collecting IoCs systematically instead of remediating one machine at a time.
Where IoCs actually come from
External threat intelligence:
- CISA and other government/CERT advisories
- Vendor threat reports (EDR, AV, and threat intel vendors)
- Commercial and open-source threat intel feeds
- Dark web and criminal-forum monitoring
- ISAC/ISAO industry sharing groups
Internal detection:
- Antivirus and EDR alerts
- SIEM correlation and log analysis
- Network and DNS monitoring
- Digital forensics from a confirmed incident
- User-reported phishing or suspicious activity
Internally-generated IoCs are usually higher-confidence than a third-party feed, because you already know they matched something real in your own environment.
Managing IoCs without drowning in stale data
Practices that actually hold up at scale:
- Centralize collection in one platform instead of scattered spreadsheets and Slack messages.
- Tag every indicator with source, first-seen date, and confidence — undated IoCs are the ones that cause false-positive blocking months later.
- Automate the boring part: feed validated IoCs into detection rules and blocklists instead of manual entry.
- Expire or re-verify network-based IoCs on a schedule; don't let a two-year-old IP sit in an active blocklist.
- Archive retired IoCs rather than deleting them — they're valuable for retrospective hunts when a new campaign resembles an old one.
Formats and platforms:
- STIX (Structured Threat Information eXpression) — the standard structured format for describing an indicator and its context.
- TAXII (Trusted Automated Exchange of Intelligence Information) — the transport protocol used to exchange STIX data between organizations and platforms.
- MISP (Malware Information Sharing Platform) — the most widely deployed open-source platform for collecting, correlating, and sharing IoCs with your team or community.
- OpenIOC — an earlier XML-based schema from Mandiant, largely superseded by STIX but still seen in older tooling.
- Commercial threat intel platforms that layer confidence scoring, decay tracking, and automated enrichment on top of these formats.
The bottom line
An IoC is forensic evidence, not a crystal ball — it tells you what already happened or is happening right now, using an artifact an attacker left behind. That makes it essential for scoping and closing an incident, and useless for catching something genuinely new; that's what Indicators of Attack and behavioral detection are for. File hashes and registry keys are durable evidence; IPs and domains are perishable and need re-verification before you trust them. Collect IoCs systematically, tag them with age and confidence, retire the stale ones, and pair them with behavior-based detection instead of leaning on either one alone.