What are indicators of compromise (IOCs) and how do you use them?

Indicators of compromise (IOCs) are technical artifacts or observations that suggest an attack is imminent or underway, or that a compromise may already have happened. Examples include a file hash, a domain, an IP address or an unusual login. They help you search for known threats, but attackers can change them cheaply.

What does the standard definition say?

NIST's glossary defines an indicator of compromise as technical artifacts or observables that suggest that an attack is imminent or is currently underway or that a compromise may have already occurred. The definition appears in several NIST publications, including SP 800-53 Revision 5 and SP 1800-8b, and NIST's incident response guide, SP 800-61 Revision 3, is the document to read for what to do next.

Two details of the wording matter. The word suggest means an IOC is a clue, not proof. And the span from imminent to already occurred means IOCs apply before, during and after an incident.

What types of IOC are there?

• File-based: hashes of known malicious files, file names or paths.
• Network-based: domains, IP addresses, URLs, unusual outbound connections.
• Host-based: new services, registry changes, scheduled tasks, unexpected processes.
• Account-based: logins from impossible locations, new multi-factor devices, mass downloads.
• Email-based: sender addresses, subject patterns, attachment types.

Why do IOCs go stale?

Some are cheap for an attacker to change. A hash changes if one byte changes, and a new domain can be registered in minutes.

CISA's joint guidance on living off the land techniques puts it more bluntly for one kind of attacker. It states that there is a general lack of conventional IOCs associated with that activity, and that defenders who depend on discrete IOCs, which attackers can alter or obfuscate, may miss it. So an IOC feed is useful but not enough.

A constructed example

A security team receives a list of 40 IP addresses and 12 file hashes tied to an intrusion campaign. They load them into their log search and look back 90 days. One IP shows up: a build server talked to it three weeks ago, for two minutes, at 3 a.m. No hash matches. The team does not stop there. They pull the build server's logs around that time, find a new scheduled task, and discover the IP was a staging server. The IOC was the starting point, and the behavior around it was the finding.

How should you handle an IOC feed?

1. Check the source and date. An indicator without a date and context is hard to trust.
2. Search back, not just forward. Look through stored logs for the past 30 to 90 days or as far as retention allows.
3. Block with care. Blocking an IP shared by many sites can cause outages, so test the effect first.
4. Record what you found, including negatives, so the next analyst knows the search was done.
5. Expire indicators. Remove or archive them on a schedule so lists do not grow forever.
6. Move up the stack. Convert recurring findings into detections of behavior, such as a build server making outbound connections at night.

How to check or apply this

1. Confirm you keep at least 90 days of DNS, proxy, firewall and authentication logs in one searchable place.
2. Write a short procedure for what happens when a new IOC list arrives, who searches and who decides on blocks.
3. Run one drill with a harmless fake indicator planted in a test log, and measure how long it takes to find.
4. Review which of your detections rely only on hashes or IPs, and plan a behavior-based replacement for the most important.
5. Tie your response steps to NIST SP 800-61 Revision 3 so IOC hits lead to a defined action.

Quick check

Sources

• NIST CSRC Glossary, Indicator of Compromise
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations
• CISA, Identifying and Mitigating Living Off the Land Techniques

Last reviewed: 18 October 2026.