What Are Indicators of Compromise?

What are indicators of compromise?

Indicators of compromise, often shortened to IoCs, are observable signs that a security incident may have happened or may still be in progress. They are not proof by themselves. They are clues that need context: a strange login, an unexpected file hash, an outbound connection to a known command-and-control host, a request pattern that does not match normal use, or a burst of blocked WAF events against one sensitive endpoint.

For website and application teams, useful IoCs usually come from the systems already handling production traffic. Access logs, firewall events, authentication records, API gateway telemetry, DNS logs, endpoint alerts, cloud audit trails, and SIEM detections all provide fragments. The operational job is to connect those fragments without overreacting to noise or missing a real breach because each signal looked small in isolation.

An IoC should answer a practical question: what might have been touched, by whom or what, through which path, and when? If it cannot support that kind of investigation, it is closer to a weak suspicion than a useful indicator.

Common places IoCs appear

Network and request-path indicators are common on public applications. A login endpoint may show credential-stuffing volume from many networks. A checkout path may receive repeated malformed payloads. An admin URL may be probed from hosting providers and anonymising networks. An API route may suddenly return more 401, 403, or 500 responses than its baseline. None of these automatically proves compromise, but each gives the team a place to look.

Account and identity indicators are often more direct. Examples include successful logins from an unusual geography, a new device immediately after a password reset, MFA prompts accepted at odd times, impossible travel patterns, repeated token creation, or privilege changes that do not match a ticket or deployment window. The strongest identity indicators combine the account event with device, network, session, and business context.

Host and application indicators still matter even for teams focused on web traffic. Unexpected processes, changed configuration files, unknown scheduled tasks, new outbound destinations, abnormal database queries, and unexplained changes to static assets can all indicate that an attacker has moved beyond probing and into persistence or data access.

Why context matters

Many IoCs are shared by harmless activity and hostile activity. VPN use can be normal for a remote employee. A sudden traffic spike can be a marketing campaign. A vulnerability scanner may belong to an approved vendor. A failed login burst may come from a real user stuck behind a corporate proxy. Blocking every odd signal without context creates false positives and trains teams to distrust their controls.

The opposite mistake is treating a weak signal as meaningless because it is common. A single suspicious request may not matter. The same request tied to a known exploit path, a new admin login, a changed API key, and unusual outbound traffic deserves immediate attention. Mature incident response depends on correlation, not drama.

Good IoC handling therefore starts with baselines. Teams should know which routes are sensitive, which systems normally talk to each other, which networks are expected, what successful and failed authentication look like, and which periods are naturally noisy. Baselines do not need to be perfect; they need to be good enough to make unusual activity visible.

How teams use IoCs during an incident

During an investigation, IoCs help scope the incident. If one account shows suspicious login activity, related indicators can show whether the event stayed at the account layer or reached internal systems. If one API route was abused, logs can show whether the same source touched other routes, whether payloads were accepted, and whether downstream services changed state.

IoCs also support containment. A confirmed malicious IP, token, credential, file hash, user agent pattern, or destination domain can be blocked, revoked, quarantined, or monitored. The safest containment actions are specific enough to reduce the active risk without disrupting unrelated users. For example, revoking an exposed token is usually cleaner than blocking an entire region because one request came from there.

After containment, IoCs feed recovery and lessons learned. Teams can search historical logs to identify first seen activity, confirm whether similar events occurred earlier, and decide whether new detections or controls are needed. This is where weak indicators can become useful: not as proof, but as pivots for a broader search.

Limits of IoCs

IoCs are often reactive. They show traces of known or observed activity, which means they can lag behind new tactics. Attackers can change infrastructure, rotate credentials, use residential proxies, alter headers, or mimic normal clients. A detection program that relies only on static indicators will miss behaviour that looks new or blends into legitimate traffic.

IoCs also decay. An IP address that was malicious yesterday may be reassigned. A hash may be replaced. A domain may be taken down. A user agent string may be copied by benign tools. Teams should attach age, source, confidence, and expiry to indicators where possible. Stale indicators can cause just as much operational pain as missing indicators.

This is why IoCs should sit beside behaviour-based detection, threat hunting, vulnerability management, and access review. They are a strong way to describe evidence, but they are not a complete security program.

Practical handling for website operators

Start by preserving the evidence you already generate. Keep request logs, WAF events, authentication logs, API gateway records, and deployment history long enough to investigate incidents after the first alert. Tag important events with route, account, action, source network, device or client signal, response status, and policy decision.

Define who can add a new indicator to a blocklist, watchlist, or SIEM rule, and how that indicator is reviewed. A rushed block rule may be appropriate during an active incident, but it should not live forever without an owner. Give emergency indicators a review date.

Finally, write incident notes in plain language. "Blocked IP range" is less useful than "blocked source networks used in confirmed admin-login abuse between 10:20 and 10:46 UTC; no successful admin session found after token revocation." The second version lets another operator understand the evidence, the decision, and the remaining uncertainty.