Does an indicator of compromise prove compromise?¶

An indicator match does not automatically prove that compromise occurred.

Avoid the dangerous assumption¶

The dangerous assumption is that the phrase “indicator of compromise” means the indicator itself establishes compromise.

It does not.

The term describes an artefact associated with malicious activity. The evidential question is what happened in this case.

A device may contact an IP address that has been linked to malicious activity. That contact may be caused by malware, a user visiting a website, a background service, shared hosting, security research or another legitimate process.

A file hash may match known malware, but the file may have been quarantined before execution.

A suspicious domain may appear in DNS logs because it was queried, not because a connection was completed.

A registry entry may be associated with persistence, but it may have been created by legitimate software.

To assess the match, ask which system produced the record, what action occurred, whether the activity succeeded, which process or account was involved, whether the indicator was current at the time, whether there are corroborating endpoint, network or authentication records and whether a legitimate explanation exists.

A strong indicator may materially support a finding of compromise. Several independent indicators linked by time and behaviour may be more persuasive than one isolated match.

The absence of a known indicator also does not prove that the system was safe. Attackers may use new infrastructure, altered files or legitimate tools that do not appear on indicator lists.

Report the evidence precisely. “The device resolved a domain listed in threat intelligence” is different from “the device was compromised by that threat actor.”

Operational takeaway¶

Treat an indicator match as evidence requiring context and corroboration, not as automatic proof that compromise occurred.