---
{
  "title": "Indicators of compromise",
  "summary": "A technical clue becomes useful when its context and confidence are known.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "MITRE ATT&CK: Get started",
      "url": "https://attack.mitre.org/resources/"
    },
    {
      "title": "NIST SP 800-150: Guide to Cyber Threat Information Sharing",
      "url": "https://csrc.nist.gov/pubs/sp/800/150/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## A clue needs context

An indicator of compromise is an observable artifact or pattern associated with potentially malicious activity. Examples include a file hash, domain, address, suspicious account change, or characteristic process behavior. Its usefulness depends on the relationship to the activity, the source's reliability, and whether the indicator is meaningful in the environment being examined.

An indicator is not a verdict. A shared hosting address may serve many unrelated customers. A filename can be changed. A hash identifies specific bytes but does not explain why a file is present or whether it executed. Analysts should preserve the difference between matching a clue and confirming a compromise.

## Work through a domain match

A fictional organization receives a report naming a domain associated with a malicious campaign. Its DNS logs show that a workstation queried the domain. The analyst checks the report's publication date, the domain's role in the reported activity, and whether the report provides evidence or merely repeats another source.

The DNS event establishes a query visible to that resolver, subject to the log's meaning. It does not by itself establish a successful connection, a file download, or execution. Endpoint and network records may show what happened next. The queried name might also appear because a security tool inspected a message or an analyst investigated the report.

Those alternative explanations do not make the match irrelevant. They determine the next questions and prevent an unnecessary declaration of compromise.

## Consider specificity and lifetime

A strong indicator may be highly specific to one malicious artifact yet have a short useful lifetime because the actor changes it. A broad behavioral pattern may remain useful longer but require more context to distinguish abuse from legitimate work. Use both where they support the investigation.

Record first-seen and last-seen context when available, confidence, source, intended use, and any handling restrictions. A stale indicator copied into a permanent blocklist can cause disruption when infrastructure changes ownership or purpose.

[[threat-intelligence]] turns these observables into assessments relevant to decisions. [[detection-engineering]] determines how to apply them to available records, including which matches need immediate action and which need investigation first.

## Practice a cautious assessment

Choose a fictional file hash and create three cases: the file was blocked before execution, the file executed on an endpoint, and the file exists only in a controlled malware-analysis collection. The same hash has different operational meaning in each case.

Write what each match establishes, what additional evidence is needed, and the appropriate next action. Avoid assuming that a lack of matching indicators proves safety; the available list and telemetry may cover only a small part of the possible activity. [[alert-triage]] helps convert a match into a reasoned case decision.

## Related concepts

- [[mitre-attack]]
- [[log-correlation]]