5 Indicators of Compromise
Learn how to identify host, network, and behavior-based indicators of compromise, validate them with contextual evidence, and interpret their limits during an investigation.
What an indicator can show
An is a technical artifact or observable that suggests an attack may be underway or that a system may have been compromised. It can be a single value, such as a file hash, or a combination of events.
An IOC is evidence to investigate, not automatic proof that an incident occurred or proof of who caused it. Its meaning depends on the quality and context of the evidence around it.
come from endpoints, servers, or their logs. Examples include:
An unexpected executable, suspicious file hash, or file created in an unusual directory.
An unfamiliar service, scheduled task, registry autorun entry, or other persistence mechanism.
An unusual process tree, such as an office application launching a command shell that then starts an unfamiliar program.
Logins at unusual times, unexpected privilege changes, or a service account used interactively.
Host evidence can help show what ran, which account was involved, and whether changes persisted. Its usefulness depends on available telemetry: logs may be missing, incomplete, or altered. A legitimate file or administrative tool can also be misused.
come from DNS, firewall, proxy, flow, email, or packet records. Examples include:
Connections to a domain or IP address associated with malicious activity.
Repeated, regular outbound connections from a host, potentially indicating .
Unusual data transfers, protocols, ports, or traffic between systems that normally do not communicate.
Suspicious DNS queries or email links and attachment-delivery infrastructure.
A network match needs context. A shared hosting address, cloud service, VPN, content-delivery network, or compromised legitimate website may serve both benign and malicious activity. Encryption can also limit visibility into traffic contents.
describe actions or relationships among events rather than a fixed artifact. Examples include unusual account behavior, a sequence of discovery commands followed by lateral movement, or a new persistence change followed by outbound connections. A behavior may be suspicious even when the tools and files involved are legitimate.
Behavioral detection usually depends on comparison with a suitable baseline and correlation of multiple events. A single unusual action may have a routine explanation, such as an administrator performing maintenance. Several related actions across one account or device may warrant investigation.
Identify and validate an indicator
Use a repeatable process to identify and validate an indicator:
Record the observation. Capture the exact value or behavior, source system, relevant account or asset, event time and time zone, data source, and detection method. Preserve relevant logs or evidence according to incident-handling procedures.
Check the indicator’s context. For shared or published intelligence, record its source, when it was observed, its stated confidence, the activity it is associated with, and any expiration or review guidance. A reputation label alone does not establish that a local match is malicious.
Confirm the match. Verify that the observed value is an exact match and that the event occurred on the reported asset and within the relevant time period. For a file, compare its hash and examine its path, signer, creation time, and associated process where available.
Correlate independent evidence. Look for related host, network, identity, and application events. Check whether the same account or device shows additional suspicious behavior and whether the sequence fits a plausible attack path.
Test benign explanations. Compare the event with known maintenance, approved software, scheduled jobs, security scans, and normal activity for that user or system. If key data is unavailable, record the uncertainty rather than treating absence of evidence as proof of safety.
Assess scope and act. Determine which other assets, accounts, and time periods to examine. Escalate or contain according to the organization’s response procedures when the evidence and potential impact justify it.
Correlate evidence across events
An alert for an unusual outbound connection is a lead, not a verdict. An analyst can check the destination’s context, identify the process and user responsible, compare the connection with the host’s normal activity, and search for related DNS, login, and process events.
A suspicious process that repeatedly connects to the destination and follows unexpected credential or persistence activity provides stronger evidence than the destination match alone.
Interpret indicators with care
Indicators differ in specificity. A unique file hash may precisely identify one file but will not detect a changed version. A broad behavior may detect more variations, but it can also alert on legitimate activity.
Indicators can become stale: domains, IP addresses, files, and attacker infrastructure can change or be reused, so an old match may no longer describe current malicious activity. A match may connect an event to a known campaign or tool, but it does not by itself prove which actor operated it; infrastructure and tools can be shared or copied.
A non-match does not rule out compromise. Attackers can change artifacts, use legitimate tools, or operate where relevant logging is absent. Known-indicator searches should therefore be combined with analysis of anomalies and behavior.
Preserve evidence and document the reasoning: record what was observed, what was checked, confidence and limitations, and why an event was classified as malicious, benign, or unresolved. This supports consistent decisions and later reassessment.