What Are Indicators of Compromise (IOCs)?

Last verified on Nov 8, 2026.

An indicator of compromise (IOC) is a technical artifact that suggests an attack is imminent or underway, or that a compromise may already have happened. That is NIST's definition. In practice an IOC is something you can search for: an address, a name, a hash.

Examples of IOCs

NIST SP 800-150 lists the usual forms: the IP address of a suspected command and control server, a suspicious DNS domain name, a URL that references malicious content, a file hash for a malicious executable, or the subject line of a malicious email.

Here is where each one shows up in logs you already have:

All values above are documentation examples, not real indicators.

IOCs vs TTPs

SP 800-150 separates indicators from TTPs. Indicators are artifacts. Tactics, techniques, and procedures describe an actor's behavior, from high-level goals down to specific tools and order of operations.

The difference matters because artifacts are easy to rotate: an attacker can move to a new IP address or domain between campaigns. Behavior is harder to change. A list of IOCs finds yesterday's attack. A check for behavior, such as a service account suddenly reading every object in a bucket, may find tomorrow's. The ATT&CK framework catalogs behaviors, and the guides on unusual data egress and novel events work at that level.

Two Uses

NIST SP 800-150 describes how organizations use indicators:

1. Forward: add rules to firewalls, intrusion detection, or other controls to block or alert on matching activity, for example connections involving an IP address on a blocklist.
2. Backward: scan security logs and systems, using indicators as search keys, to identify systems that may already be compromised.

The backward use is the one that surprises people. A new indicator can implicate activity from weeks ago, so how far back you can search is bounded by your log retention.

A simple backward search over exported logs:

grep -F -f iocs.txt /var/log/nginx/access.log* | head

Match on exact strings, and check the time range before concluding anything either way.

Handling Quality and Age

Not every IOC deserves a blocklist entry. During Log4Shell response, the joint government advisory AA21-356a pointed to community-maintained indicator lists, noted the agencies had not yet validated them, and quoted one list's own warning that its indicators were low-to-medium confidence and should not be added to a blocklist.

SP 800-150 offers the discipline to apply. Tag indicators with source and confidence. Record when each was collected and how long it should be considered valid. Take a risk-based approach, because an indicator may be useful in one situation and not another. Some hits are noise: a shared hosting IP or a CDN address may be both attacker and innocent traffic.

When a match comes back, treat it as a lead and not a verdict. Ask what else the same host or account did in the same window.

Searching for an IOC in Sazabi

Sazabi, an AI-native observability and security platform, lets you ask questions of stored logs in plain language from the CLI, a thread, MCP, or the API, so a question about when a given address first appeared in your logs and what it touched is a log search. Its VirusTotal connector gives the agent tools to check file hashes, URLs, domains, and IP addresses against VirusTotal reports while investigating a security signal. For reading advisories that ship indicators with them, see new advisories and the security issues guide.