IOC (Indicator of Compromise)

What Are the Most Common Types of IOCs?

Most IOCs fall into a handful of recognizable categories, each pointing to a different stage or method of compromise.

• Malicious IP or domain connections, where a system communicates with infrastructure known to be associated with attackers.
• Malware signatures, files or hashes matching previously identified malicious software.
• Unusual DNS activity, queries that resemble a command-and-control channel rather than normal lookups.
• Anomalous outbound traffic, data transfers that don't match a system's established behavior pattern.
• Credentials in active use from unexpected locations, suggesting an account is being used by someone other than its owner.

Network-Based IOCs Are the Easiest to Observe Externally

A connection to a known-malicious IP, an unusual DNS query pattern, or an outbound traffic spike are all visible from outside an organization's own network, which is exactly why they're the category a third-party risk team can actually detect at a vendor without needing direct access to that vendor's internal systems.

Host-Based IOCs Need Access Third Parties Lack

A malware signature on a specific file or an unusual process running on an endpoint requires access to the system itself, something an outside party essentially never has inside a vendor's infrastructure. This is part of why vendor-facing IOC detection leans so heavily on network-based signals instead.

How Does an IOC Differ From a Vulnerability?

A vulnerability is a weakness that could be exploited. An IOC is evidence that exploitation may have already happened. A system can carry a critical, unpatched vulnerability for months with zero IOCs, meaning nobody has exploited it yet. The same system can also show a clear IOC with no vulnerability responsible for it at all, a stolen credential doesn't require a technical flaw to misuse. A vulnerability assessment answers what could go wrong; IOC detection answers what already might have.

Where Do IOCs Actually Come From?

IOCs come from watching what's actually happening on a network or system, not from theorizing about what could happen. Threat intelligence feeds, malware analysis, honeypots, and industry information-sharing groups all contribute known-bad indicators other organizations can check against. For a vendor specifically, an organization can't install detection tools on infrastructure it doesn't own, so vendor-facing IOC detection depends on what's externally observable through an outside-in assessment, network traffic patterns, DNS behavior, and infrastructure reputation, rather than the internal logging an organization has for its own systems.

Why Does an IOC at a Vendor Demand Faster Action Than a Regular Finding?

A finding describes a condition. An IOC describes an event already underway, and the second one doesn't wait for a normal review cycle. A misconfigured setting can sit in a remediation queue for weeks without getting materially worse. An active IOC at a critical vendor means an incident may already be unfolding, and treating it with the same triage timeline as a routine finding risks missing the window where a fast response actually limits the damage.

What Can Make an IOC Unreliable?

An IOC is a signal, not a verdict, and treating every one as a confirmed compromise leads to alert fatigue that makes the real ones easier to miss. Shared cloud infrastructure means a genuinely malicious IP address can be reassigned to an innocent tenant later, producing a stale match.

Attacker Infrastructure Rotates Faster Than Some Feeds Update

Attackers rotate infrastructure specifically to stay ahead of known-bad lists, which means an IOC feed is always describing yesterday's attacker infrastructure to some degree, not necessarily today's. Black Kite's 2026 Ransomware Report tracked 61 new ransomware groups joining the field within a single year, more than one a week, a reminder that any static list of known-bad indicators is incomplete the moment new actors show up.

A data exfiltration event, for example, often produces exactly this kind of IOC, unusual outbound traffic, but the same traffic pattern can occasionally have an innocent explanation, which is why corroboration matters before treating a single indicator as confirmed.

What Should a Risk Team Do When an IOC Surfaces at a Vendor?

The first move is confirming what the IOC actually indicates, not assuming the worst-case interpretation is automatically correct. A vendor inventory that already records each vendor's criticality tier makes the escalation decision faster, since a team doesn't have to research how much a given vendor matters in the middle of responding to a live signal.

• Corroborate with a second signal, since one IOC in isolation is weaker evidence than a pattern across several indicators.
• Contact the vendor with specifics, naming the exact indicator rather than a general request to "check your security."
• Escalate proportionally to vendor criticality, treating an IOC at a mission-critical vendor with more urgency than the same signal at a low-risk one.
• Watch for follow-on indicators, since a confirmed compromise often produces additional IOCs as it progresses, and may call for a full incident response process rather than a routine follow-up.

How Does Black Kite Detect IOCs Across a Vendor Ecosystem?

Black Kite's ThreatTrace™ analyzes more than 1T internet traffic flows to surface IOCs including botnet infection, active threat actor targeting, and geopolitical and service risk, feeding new controls into the IP Reputation category behind every vendor's rating. That detection runs continuously through the same monitoring that tracks a vendor's broader risk profile, so an emerging IOC surfaces as part of an ongoing picture rather than waiting for the next scheduled scan to notice it.

See also: How to Create an Effective Cyber Incident Response Plan