When an attacker moves through your environment, they leave traces. A file written to an unusual location. An outbound connection to an IP address no legitimate process should contact. A login from a country where you have no employees. These are indicators of compromise (IOCs): digital evidence that a system or network has been breached, or that a breach is actively in progress.
For security teams and MSPs, IOCs are one of the primary tools for detecting threats that have already made it past the perimeter. Tools like Datto EDR, Kaseya SIEM and Kaseya MDR are built around exactly this: detecting IOCs across your environment and turning them into coordinated responses before damage spreads.
What are indicators of compromise?
Indicators of compromise are pieces of digital forensic evidence that suggest a system, endpoint or network has been accessed without authorization, infected with malware or subjected to an attack. The term “compromise” is intentional: by the time most IOCs are identified, an intrusion has already occurred or is underway.
IOCs can be artifacts collected from logs, network traffic, file systems or endpoint telemetry. They include specific file hashes associated with known malware, IP addresses or domains used for command and control, registry key changes, unusual process behavior and authentication patterns that suggest credential theft.
Security teams use IOCs in two ways. Reactively, after a suspicious event is flagged, analysts look for IOCs to understand what happened, trace the attacker’s path and determine the scope of the incident. Proactively, teams feed known IOCs into detection tools so that if the same artifacts appear again, an alert fires automatically. This second use is what makes threat intelligence feeds and IOC sharing valuable.
It’s worth being clear about one limitation: IOC detection is inherently retrospective. If your tools have found an IOC, something has already gone wrong. The goal of good IOC monitoring is to shrink the gap between when a compromise occurs and when it is detected, because that gap is where attackers operate.
Indicators of compromise vs. indicators of attack (IOAs): What’s the difference?
An indicator of compromise is evidence that something bad has already happened. It is artifact-based: a file hash, a registry key, a domain name, an IP address. IOCs are specific and static.
An indicator of attack focuses on behavior rather than artifacts. IOAs describe the techniques and actions an attacker uses, regardless of the specific tools they deploy. A process spawning a child process that attempts a network connection is an IOA pattern. It might be triggered by known malware or by a brand-new threat that has never been cataloged. IOAs are broader and more resilient to evasion, because changing a file hash doesn’t change the underlying behavior.
In practice, mature security operations use both. IOCs detect known threats quickly. IOAs catch novel attacks and sophisticated adversaries who specifically craft tools to avoid matching known IOC databases.
Types of indicators of compromise
IOCs are grouped into four categories based on where they originate and what they describe.
Network-based IOCs
Network IOCs are artifacts associated with suspicious or malicious network activity. They include IP addresses tied to threat actor infrastructure, domains used for command and control (C2) communication, unusual outbound traffic patterns and DNS queries for domains that don’t correspond to legitimate services.
Because network IOCs often represent active communication with attacker-controlled infrastructure, detecting them quickly matters. An endpoint that has been compromised but hasn’t yet exfiltrated data can still be contained if the outbound C2 connection is caught first.
Host-based IOCs
Host-based IOCs exist on individual endpoints and devices. They include unexpected changes to registry keys or system files, new processes running under unusual parent processes, modifications to scheduled tasks or startup entries, files appearing in locations where no legitimate software writes data, and unauthorized changes to account permissions.
EDR tools are the primary mechanism for detecting host-based IOCs, because they have agent-level visibility into everything happening on the device — every process launch, every file write, every registry modification. This telemetry makes it possible to detect fileless malware and living-off-the-land attacks that leave no files on disk but still leave behavioral traces.
File-based IOCs
File-based IOCs are specific artifacts tied to known malicious files. The most common form is a cryptographic hash (MD5, SHA-1 or SHA-256) that uniquely identifies a file. If a hash matches one associated with known malware, it’s a strong signal that the file is malicious regardless of what it’s been renamed to.
Other file-based IOCs include filenames and paths that known malware families use and digital certificate details from signed malware. File-based IOCs are fast to check and easy to share, which is why they form the bulk of threat intelligence feed data. Their limitation is that they’re easily defeated by recompiling code, which changes the hash.
Behavioral IOCs
Behavioral IOCs describe patterns of activity that deviate from established baselines, regardless of the specific files or artifacts involved. Multiple failed logins across different accounts in a short window, a user account accessing file shares it has never touched before, or large volumes of data being read from a database by a single user are all behavioral IOCs.
Behavioral IOCs require an established baseline to be meaningful. SIEM platforms and user and entity behavior analytics (UEBA) tools build these baselines over time and flag deviations automatically, making them especially effective at catching threats that deliberately avoid matching known IOC signatures.
Common indicators of compromise examples
Knowing what IOCs look like in practice helps security teams know what to look for. The most common examples include:
- Unusual authentication activity: Multiple failed logins across several accounts from the same IP address, a successful login from an unexpected geographic location or a device that has never previously accessed the account, and logins at unusual hours all signal potential credential theft or unauthorized access.
- Abnormal outbound traffic: A device suddenly transferring large volumes of data to external destinations it has never communicated with, or traffic to known malicious IP ranges, indicates potential exfiltration. Traffic sent in regular, timed intervals often signals beaconing to C2 infrastructure.
- Unexpected processes or software: Processes running from temp directories, unsigned executables in locations where software doesn’t normally live and remote access tools that have no business being on production machines are all worth investigating. Scheduled tasks or startup entries that appeared without a corresponding change request may indicate attacker persistence.
- Suspicious registry modifications: Attackers modify registry keys to maintain persistence, disable security tools or change system behavior. Changes to autorun keys or service configurations without a supporting change ticket are strong host-based IOCs.
- DNS anomalies: High volumes of DNS requests to a single domain, requests for newly registered or algorithmically generated domains (a technique called domain generation algorithms, or DGA) and queries for known malicious domains all indicate potential network compromise.
- Unauthorized configuration changes: Firewall rules modified to open inbound ports, new administrative accounts created without authorization, and security software disabled or uninstalled all represent IOCs that warrant immediate investigation.
How IOCs are used in incident response
IOC detection is most valuable when it is connected to a response workflow. Finding an IOC without acting on it quickly is only marginally better than not finding it at all.
In practice, IOC-driven incident response follows a consistent pattern. An alert fires when a known IOC is matched or anomalous behavior crosses a threshold. An analyst validates whether it represents a genuine threat. If confirmed, the scope is assessed: which systems are affected, what data may have been accessed and how the attacker got in. Containment follows, isolating endpoints or blocking suspicious connections. Remediation removes malicious artifacts and closes the access vector. Finally, IOCs gathered during the investigation are added to detection rules, so the same pattern is caught faster next time.
Speed matters at every step. The 2026 Unit 42 Global Incident Response Report found that the fastest attacks now reach data exfiltration within 72 minutes of initial access. Organizations with automated IOC detection and containment consistently close incidents faster than those relying on manual review.
Threat correlation and IOC detection tools
Several categories of security technology are built specifically around IOC detection and response.
Security information and event management (SIEM)
SIEM is the primary tool for correlating IOCs across an environment. A SIEM ingests log and event data from across the IT stack, applies correlation rules to identify patterns matching known IOCs or suspicious behaviors, and generates prioritized alerts. Because a SIEM sees data from multiple sources simultaneously, it connects events that would look unremarkable in isolation: a failed login, followed by a successful login from a different IP, followed by that user accessing a file share they’ve never touched, becomes a correlated incident rather than three separate low-priority alerts.
Endpoint detection and response (EDR)
EDR tools monitor individual endpoints for host-based and behavioral IOCs in real time. They record granular telemetry, match behavior against threat libraries and IOC databases, and support automated or analyst-guided response including isolation, process termination and file quarantine.
Managed detection and response (MDR)
MDR services add the analyst layer on top of SIEM and EDR technology. Rather than leaving IOC triage and investigation to internal staff, MDR providers monitor continuously and respond to confirmed threats on the customer’s behalf. For organizations without 24/7 security operations coverage, MDR is what converts IOC detection into operational response.
Cloud detection and response (CDR)
As more business activity moves to platforms like Microsoft 365 and Google Workspace, cloud-based IOCs have become a significant part of the threat picture. CDR tools extend IOC detection into SaaS environments, flagging signals such as unusual OAuth app permissions, logins from impossible locations, bulk file downloads and unauthorized changes to cloud tenant configurations.
Threat intelligence platforms
Threat intelligence platforms aggregate IOC data from global feeds, government advisories, vendor research and community sharing. They enrich alerts with context about what a given IP address, domain or file hash has been associated with, which adversary groups use it and how recently it has been seen in active campaigns, helping analysts prioritize what to investigate first.
How Kaseya helps teams detect and respond to IOCs
Kaseya’s security platform is built around detecting IOCs across the full attack surface and connecting detection to fast, coordinated response, specifically for MSPs and lean IT teams without a large in-house security operation.
Kaseya SIEM ingests telemetry from 60+ data sources, correlates IOC matches and suspicious behavioral patterns across endpoint, identity, network and cloud, and retains logs for 400 days to support forensic investigation. Automated response rules can act immediately when IOCs are confirmed, blocking accounts, isolating devices and flagging expiring sessions without manual intervention.
Datto EDR monitors endpoints for host-based and behavioral IOCs in real time, maps detections to the MITRE ATT&CK framework for immediate analyst context and provides 65+ automated response actions including ransomware rollback.
Kaseya MDR provides US-based security analysts who monitor your environment around the clock, investigate IOC-triggered alerts and take containment action when threats are confirmed. For organizations that need IOC response coverage 24/7 without building a SOC, MDR is the practical solution.
SaaS Alerts extends IOC detection into Microsoft 365, Google Workspace and other cloud applications. Teams can define custom IOC rules using event triggers and filters, with community IOC templates covering common threat patterns available out of the box. SaaS Alerts connects directly to Kaseya SIEM for cross-surface correlation, giving analysts a unified view of endpoint and cloud IOC activity in one place. Together, these tools give MSPs and IT teams the visibility and response capability to act on IOCs across every layer of the environment, without needing a dedicated security operations center to make it work.
