What it means
An indicator of compromise, often shortened to IOC, is an observable used as a clue to malicious activity. Examples include a file hash, a domain, an address, or a recognizable pattern of behavior. Its value depends on context: an address may host many unrelated services, while a hash can identify an exact file but miss a slightly changed version. Indicators have a lifecycle, including assessment, deployment, review, and retirement. They help guide searches and defenses but do not replace investigation of how an attack works.
The idea at a glance / Evidence
An exact file match does not prove execution.
Hold a scoped hash match beside its source, dates and missing execution evidence.
Fictional Lab A200 supplies a full SHA-256 file hash with an assumed malicious-attachment context. Its selected search policy is active September 30 20:00–23:00 UTC, with the end exclusive. At 21:00, local collection L200 records that exact file on D200 in quarantine. These are synthetic teaching records; the actual fixture bytes are harmless.
READ THE PICTURE
Match beside context
A200 matches L200’s full file hash in quarantine. Execution remains unobserved; after 23:00 this indicator leaves the selected active search while its history remains.
Keep in mindThe publisher’s assessment, trusted collection and device association are assumed. The exercise joins full SHA-256 values in one selected collected dataset, not every endpoint or attack variant. A stored quarantined file does not establish execution or compromise. This chosen indicator lifetime is not a universal IOC expiry. A different hash or no active match does not establish safety; shared infrastructure and other IOC types need their own context.
Read the complete example
- Match beside context. A200 matches L200’s full file hash in quarantine. Execution remains unobserved; after 23:00 this indicator leaves the selected active search while its history remains. A200’s full SHA-256 is 704fc1b0f9fd437e163ae6a376ea217c66aef0caabfd5b51ea25396a0535cfe7, computed over UTF-8 bytes training attachment 200 followed by one LF newline. This harmless fixture represents the assumed malicious-file classification; it is not an actual malware sample. A parameter-bound SQL join uses full digest equality, source A200 and L200’s 21:00 UTC observation. It finds the collected file on D200 in quarantine. No execution telemetry was supplied, so execution and compromise remain unknown. Changing the final 200 to 201 produces a different full digest and no match for this chosen indicator, without proving the changed file safe. At the exclusive 23:00 policy end, a new active-indicator search returns no A200 match while historical A200/L200 records remain. Source assessment, collection coverage, related behavior and the chosen search/alert/block action still require review.
The publisher’s assessment, trusted collection and device association are assumed. The exercise joins full SHA-256 values in one selected collected dataset, not every endpoint or attack variant. A stored quarantined file does not establish execution or compromise. This chosen indicator lifetime is not a universal IOC expiry. A different hash or no active match does not establish safety; shared infrastructure and other IOC types need their own context.
Diagram references: IETF RFC 9424: indicator context, lifecycle and limitations
AN ILLUSTRATIVE SCENARIO
An exact attachment hash is found in quarantine
Fictional A200’s full SHA-256 matches collected L200 on D200 in quarantine. The harmless fixture represents assumed malicious-file context; no execution telemetry was supplied. A changed file has a different digest. The chosen active-search lifetime ends at 23:00 UTC, while history remains. A match identifies this collected file; no match does not establish safety.
Put it to work
- Record each indicator’s type, source, confidence, first-seen time, and relevant context. Keep the reason it is considered suspicious alongside the value.
- Choose the action deliberately: search, alert, or block. Test possible collateral impact before blocking shared infrastructure, and ensure someone owns exceptions and expiration.
- Review matches using surrounding evidence. Retire or update indicators when infrastructure changes or their usefulness declines, while retaining the history needed to explain past decisions.
How to check your work
Test a safe indicator against known records. Confirm that the matching logic uses the correct field and format, preserves context in alerts, and stops enforcing the indicator when its approved lifetime ends.
Connect the ideas
- Alert
A notification that a rule or model wants a human to look at one or more records.
- Evidence
A record you are willing to cite in a decision, with enough provenance to explain what it can prove.
- Hashing
A one-way fingerprint of data used to detect change or store verifiers, not a reversible way to hide records you must later read.
- False positive
An alert that did not represent the harmful event the detector was meant to catch.