Indicators of Compromise

What Is an Indicator of Compromise?

An Indicator of Compromise (IoC) is observable evidence that strongly suggests a security breach has occurred or is actively unfolding. Unlike a general anomaly or a threat indicator, an IoC carries high confidence — it is not just a warning sign but evidence that an attacker may already have access to a system.

The defining phrase used in incident response: "He's calling from inside the house." When you observe an IoC, the attacker is likely already inside the perimeter. The appropriate response is investigation and containment, not just alerting.

Common IoC categories surveyed in this chapter:

• Unusual amounts of network activity or file read spikes
• Changes to file hash values (modified files)
• Irregular international traffic patterns
• Unauthorized DNS configuration changes
• Uncommon login patterns (time, location, frequency)
• Log anomalies — out-of-cycle entries or missing logs
• Organizational data suddenly published online

Indicator 1 — Account Lockout

An account lockout occurs when the number of failed login attempts exceeds a configured threshold. Most authentication systems automatically lock the account and require manual or time-delayed unlocking. When a legitimate user discovers their account is locked but did not cause the lockouts themselves, the event is an IoC with high confidence of unauthorized access attempts.

Two lockout scenarios exist with different severity:

• Threshold-based lockout: Automated — account locked after N failed attempts. Indicates an active brute force attempt against the account.
• Administrative disablement: Someone with management system access explicitly disabled the account. This is a higher-severity event — it implies an insider threat or a compromised administrator account.

Account lockout as a stepping stone to a larger attack:

Defense: Enforce identity verification procedures for any help desk password reset — shared secret, in-person verification, manager approval, or out-of-band callback to a known-good phone number. Never reset a password based solely on a caller knowing basic identity information.

Indicator 2 — Impossible Travel

Authentication logs record the source IP address (and associated geolocation) of every successful login. When the same account logs in from two geographically distant locations within a timeframe that is physically impossible to traverse — the event is called an impossible travel detection and is a strong IoC.

Classic example: User account authenticates from Omaha, Nebraska at 09:14 AM. Three minutes later, the same account authenticates from Melbourne, Australia. The distance is approximately 14,000 km. Commercial flight time exceeds 20 hours. This combination is physically impossible — one of the two sessions must belong to an unauthorized party.

Impossible travel is one of the most automatable IoCs. SIEM systems and identity providers (Azure AD, Okta) implement impossible travel detection as a built-in alert rule, comparing login timestamps against geolocation data and flagging sessions where the implied travel velocity exceeds human capability.

Detection approach: For each pair of consecutive logins on the same account, calculate the distance between source IPs and divide by the time delta. If implied velocity exceeds ~900 km/h (commercial aviation maximum), the event is flagged. If it exceeds ~1,200 km/h, the confidence is near-certain.

Indicator 3 — Concurrent Session Usage

Concurrent session usage refers to simultaneous active logins to the same account from multiple distinct locations. Unlike impossible travel (which involves sequential logins with an impossible time gap), concurrent sessions are active at the same time.

This IoC is more difficult to assess definitively because legitimate concurrent sessions exist in normal operations:

• A user with a desktop at work, a personal laptop at home, and a mobile device may have three active sessions across three locations simultaneously.
• Service accounts run automated processes and may show sessions from multiple hosts.
• VPN connections can make a remote worker appear to be at the corporate IP while their physical location is elsewhere.

The investigation approach: cross-correlate concurrent session data against expected device inventory and known user behavior. An administrative account showing simultaneous interactive sessions from two different continents with no known business reason is high-confidence credential compromise. A user account showing three sessions across known corporate IP ranges is likely benign.

Indicator 4 — Blocked Content

Once an attacker establishes a foothold on a system, their primary operational goal is maintaining access for as long as possible. The most direct threat to persistence is a security update that patches the vulnerability used for entry. Attackers therefore commonly modify the compromised system to block connections to security resources.

Categories of blocked content used as a persistence mechanism:

• Auto-update connections: Windows Update, macOS Software Update, Linux package manager endpoints — blocking these prevents OS patches from arriving.
• Antivirus signature updates: Blocking connections to AV vendor update servers (Symantec, CrowdStrike, Defender) prevents detection signature updates that would identify the malware.
• Third-party anti-malware sites: Malwarebytes, HijackThis, removal tool download sites — blocked to prevent the user from obtaining removal utilities.
• Security patch repositories: Vendor-specific patch distribution sites, WSUS servers, and similar — preventing the user from manually downloading fixes.

Detection: Monitor for DNS resolution failures or connection timeouts to known security update endpoints. Any system that cannot reach Windows Update or its antivirus vendor's update server but can reach general internet sites should be investigated immediately.

Indicator 5 — Resource Consumption

Every attacker action on a compromised system produces a corresponding observable effect — increased bandwidth, CPU, memory, disk I/O, or network flow volume. This is sometimes described as Newton's third law applied to security: every attacker action has an equal and opposite reaction in resource utilization.

The most operationally significant resource consumption IoC is unexplained network bandwidth spikes, particularly during off-hours:

• An attacker exfiltrating data transfers files from internal systems to external C2 servers. A 50 GB database exfiltration at 3:00 AM is immediately visible in network flow data as an anomalous spike with no corresponding business activity.
• Firewall logs record the outbound transfer with source IP, destination IP, port, protocol, and timestamps — providing both detection and forensic evidence of the exfiltration event.
• Many breaches are not detected by sophisticated security tools. They are detected because a network administrator notices an unusually busy interface at an unusual hour — or because an alert on an anomalous flow fires based on a simple threshold rule.

Critical operational note: Resource consumption IoCs often surface long after the initial intrusion. An attacker may reside inside a network for weeks or months before initiating exfiltration. The consumption spike may be the first visible IoC even though the compromise began much earlier. This is why forensic analysis after a resource spike should reconstruct the full timeline backwards from the detection event.

Additional resource consumption signals:

• Elevated CPU on a server not running any known high-load jobs — may indicate cryptomining malware or active exploitation tooling.
• Excessive read requests to a sensitive file or directory — attackers staging data for exfiltration will access the same files repeatedly.
• Unusual process memory usage — malware loaded in memory (fileless malware) may show as unexplained RAM consumption by a known-good process.

Indicator 6 — Resource Inaccessibility

When a system or service becomes unavailable, the cause is not always operational failure. Resource inaccessibility can be a direct IoC in several distinct scenarios:

The distraction pattern: Sophisticated attackers deliberately cause a visible disruption in one area of the network to draw incident response attention away from the actual compromise occurring elsewhere. A network outage in one office segment may be intentional misdirection while data is exfiltrated from a different segment. Simultaneous anomalies in different network areas should be investigated in parallel, not sequentially.

Indicator 7 — Out-of-Cycle Logging

Log entries that occur outside expected operational windows are called out-of-cycle log entries. In a well-managed environment, many administrative activities occur on predictable schedules: patch deployment happens every second Tuesday, backups run at 02:00, user provisioning follows business hours. When log entries for these activities appear at unexpected times, it may indicate that an attacker is performing the same actions as an administrator — but on their own schedule.

The most telling examples:

• Patch log entries outside maintenance windows: An attacker who has compromised a system and wants to protect their own access may patch the vulnerability they used to get in, preventing competing attackers (or administrators) from using the same entry point. A patch installation log entry at 4:30 AM on a Monday (when maintenance windows run Saturday nights) is anomalous.
• Firewall logs showing traffic at unusual hours: Firewalls record every traffic flow with a timestamp. An outbound connection to an external IP on port 443 at 03:15 AM from a server that has no business running outbound HTTPS connections should trigger investigation.
• User account creation or privilege changes outside of HR processes: A new admin account appearing in Active Directory on a Sunday evening with no associated change request is a high-confidence IoC.

Detection: SIEM rules should baseline the expected timing of administrative activities and alert on any matching log entry that occurs outside the expected window. Temporal correlation is one of the most reliable automated IoC detection mechanisms.

Indicator 8 — Missing Logs

Log files are forensic evidence. An attacker who has performed unauthorized actions knows that the logs record those actions. Deleting or altering logs is therefore a standard attacker cleanup step — and the absence of logs that should exist is itself a high-confidence IoC.

Log sources that should be continuously monitored for completeness:

• Authentication logs: Every login and logout should produce a record. A gap in authentication logs for a domain controller during a window when data was exfiltrated means the attacker deleted evidence of their login sessions.
• Firewall logs: High-volume, continuous records. A missing time window in firewall logs when network anomalies occurred upstream is suspicious.
• File access logs: If a file system audit is enabled, every access to sensitive files should be logged. Missing entries around the time of a suspected data theft are significant.
• Proxy logs: All outbound HTTP/HTTPS traffic routed through a proxy should produce entries. Gaps may indicate direct connections that bypassed the proxy.
• Server application logs: Web servers, database servers, and application servers all generate logs. Gaps or truncated log files on a database server during a suspected SQL injection timeframe are forensically significant.

Defensive architecture: Logs should never be stored only on the system that generated them. A compromised host with local-only logs allows the attacker to delete the evidence. The standard defensive approach is to forward logs in real time to a centralized, write-protected log management system (SIEM) where the compromised host has no write access. The attacker can delete local logs but cannot reach the remote copy.

Missing logs as notification trigger: Configure alerts to fire when expected log volume drops below a threshold — a server that generates 10,000 events per hour dropping to zero should generate an immediate alert, whether the cause is a service failure or an attacker deleting evidence.

Indicator 9 — Published / Documented Data Exposure

In many breaches, the compromised organization has no internal awareness that data was stolen until they receive external notification — because the attacker's internal activity generated no observed IoC, or the IoCs were not being monitored. The first indication of the breach is when the stolen data appears publicly on the internet.

How published data disclosures occur:

• Ransomware double extortion: Before encrypting files on victim systems, the attacker first exfiltrates a copy to their own servers. They then encrypt the victim's files and demand payment for a decryption key. If payment is not made, they threaten to publish the exfiltrated data. The victim faces both operational disruption (encrypted files) and data exposure (stolen copy released online).
• Direct publication for impact: The attacker publishes credentials, intellectual property, or sensitive communications to a public site or paste service. The goal may be reputational damage, coercion, or ideological exposure rather than financial gain.
• Dark web sale before public release: Stolen data is first sold in underground markets. When the buyer publishes or the seller leaks, it surfaces publicly. This may occur months after the original breach.

External detection: Researchers and threat intelligence services (e.g., Have I Been Pwned, dark web monitoring services) scan for newly published organizational data and match it against known credential or domain patterns. Organizations can subscribe to these services to receive notification when their data appears in breach databases or paste sites — often before their own incident response team has detected the breach internally.

Response implication: When published data is the first IoC, assume the breach began long before the publication date. The forensic timeline should work backward from the publication event to identify the initial access point, the lateral movement, and the exfiltration channel — which may involve reviewing months of historical logs.

IoC Detection Infrastructure

Reliable IoC detection requires automated infrastructure — human review of raw logs at scale is not operationally viable. Key components: