Indicators of compromise are observable traces, such as a file hash or a suspicious domain, that suggest a system was breached.
They are clues for a hunt or a detector, and they are not the response plan that decides who isolates the machine.
How it works
A hash, a mutex name, a registry key, a source address, or a domain used only by a known intrusion can all serve as indicators when they are specific enough.
Too broad a clue, such as a popular cloud address, creates noise and can make analysts ignore the queue.
Indicators age quickly because attackers change infrastructure, so a list from last year may describe a campaign that no longer looks the same.
Sharing them helps other teams search, yet each team still has to judge context before treating a match as proof of compromise.
Concrete examples
- A file hash from a confirmed case is searched across laptops and finds the same file on two machines that share a department file share.
- A domain that appeared in a phishing mail is blocked at the resolver after analysts confirm it is not used by any business partner.
- A scheduled task name seen in one incident is added to endpoint alerts so a repeat of that exact task is noticed the same day.
Protective measures
- Record where each indicator came from, how specific it is, and the date after which it should be reviewed or retired.
- Prefer precise traces over very common addresses that will match half of normal business traffic.
- Search new indicators in logs you already keep before you assume the environment is clean.
- Treat a match as a lead that still needs context, not as an automatic verdict that a system is lost.