Indicators of compromise, or IOCs, are technical artifacts that suggest an attack is underway or has already happened. Examples include a malicious file hash, a command and control domain, or an unusual login. NIST defines them as observables that point to a possible compromise. Use them to search your logs, then confirm before you act.
What counts as an indicator?
NIST SP 800-150, the guide to cyber threat information sharing, lists indicators of compromise next to attacker tactics, techniques and procedures, and suggested actions. So an IOC is one kind of threat information, not the whole thing.
Common types:
- File hashes of known malware.
- IP addresses and domain names tied to attacker infrastructure.
- URLs used for payload delivery or credential theft.
- Registry keys, scheduled tasks or file paths a threat creates on a host.
- Odd account behavior, such as a login from a new country followed by mailbox rule changes.
The CISA alert on the 2025 npm worm is a good real example. It told defenders to block outbound connections to webhook.site domains and to look for a public repository named Shai-Hulud created through the GitHub API. Both are indicators a team can search for today.
Why do indicators go stale?
Attackers change infrastructure faster than defenders update lists. A hash changes with a one-byte edit to a file. An IP address that served malware last week may belong to an innocent hosting customer now. That is why an indicator without a date and a source is close to useless.
Behavior lasts longer than artifacts. A hash is easy to change. A pattern, such as an installer script that reads cloud credentials and then makes an outbound web request, is harder for the attacker to hide. Good detection leans on both.
What is the difference between an IOC and a TTP?
An IOC says what you might find. A tactic, technique or procedure says how the attacker works. Finding one IOC tells you little. Finding it alongside a known technique tells you a lot more. MITRE ATT&CK is the common vocabulary for techniques, and mapping alerts to it helps teams compare notes.
A constructed example
Your team receives a feed entry: a domain, a first-seen date of three days ago, and a note that it hosts a credential stealer. You search DNS logs and find one workstation resolved it twice yesterday. That is a lead, not a verdict. You check the process that made the request, find it was a build tool run by a developer, and look at what packages that build installed. Only then do you decide whether to isolate the machine and rotate the developer's tokens.
What is the pyramid of pain?
Security practitioners often describe indicators by how much it hurts an attacker when you block them. Hashes and addresses are cheap for the attacker to change. Tools are harder. Behaviors, the way an attacker actually works, are costliest to change. So when you write detections, aim for the behavior and use the cheap indicators as a quick first sweep after a fresh report.
A second habit helps: keep context with each indicator. A domain labeled "seen in a phishing kit, high confidence, expires in 30 days" is usable. A bare domain in a spreadsheet is not.
How to check or apply this
- Record the source, date and confidence of every indicator you ingest.
- Search back through logs, not only forward, because the compromise may be older than the feed entry.
- Prefer indicators tied to behavior over single hashes when you can.
- Expire indicators on a schedule so old IP addresses do not keep generating false alerts.
- When you get a hit, find the process, account and time before you act.
- Treat a confirmed hit as a reason to rotate any credentials that machine could reach.
- Share what you learn with the group you trust, following your information sharing rules.
Quick check
Is an IOC the same as a vulnerability?
No. A vulnerability is a weakness. An indicator is evidence that something may have happened. Being vulnerable does not mean you were compromised.
If no indicators match, am I clean?
No. Indicators only cover what is already known. A clean search means no known trace turned up, which is useful but not proof.
Sources
- NIST SP 800-150, Guide to Cyber Threat Information Sharing
- NIST Computer Security Resource Center glossary, indicator of compromise
- CISA alert, Widespread Supply Chain Compromise Impacting npm Ecosystem
Last reviewed: 18 October 2026.
