What are indicators of compromise (IOCs)?
Indicators of compromise are forensic artifacts that prove a security breach has already happened. Think of IOCs as digital fingerprints left behind at a crime scene—they're specific pieces of evidence that confirm an attacker was in your system.
IOCs are reactive by nature. This means security teams use them after discovering a potential breach to understand what happened and how far the damage spread.
Common IOC examples include:
Malicious file hashes: Unique digital fingerprints that identify known malware files
Suspicious IP addresses: Connections to known command-and-control infrastructure, bulletproof hosting, tor exit nodes, or other high-risk endpoints
Registry modifications: Specific changes attackers make to Windows registry keys
Unusual network patterns: Traffic to known bad domains or unexpected data transfers
When you find an IOC in your environment, it validates a compromise and triggers an investigation to scope the blast radius and determine the full impact. Security teams then use these indicators to hunt for similar evidence across their entire infrastructure and to implement blocking rules for containment.
Cloud Attack Retrospective Reprt
In this report, we examine how threat actors target cloud environments and provide practical guidance on how Wiz helps detect and mitigate these threats.
What are indicators of attack (IOAs)?
Indicators of attack are behavioral patterns that show an attack is happening right now. IOAs focus on what an attacker is trying to do rather than what they've already done.
Unlike IOCs, which look for specific artifacts, IOAs analyze sequences of suspicious actions. This approach helps you catch attackers while they're still working, before they can complete their objectives.
IOAs detect Tactics, Techniques, and Procedures (TTPs)—the methods attackers use to achieve objectives. In MITRE ATT&CK terms:
Tactics are goals (privilege escalation, lateral movement)
Techniques are how attackers achieve those goals (T1068, T1021)
Procedures are specific implementations (using Mimikatz for credential dumping)
IOAs identify techniques and procedures in progress. IOCs are the artifacts left behind—the forensic evidence that confirms which procedures were used.
Common IOA examples include:
Privilege escalation attempts: A process trying to gain higher permissions than it should have
Lateral movement: Unusual connections between systems that don't normally communicate
Reconnaissance activity: Scanning for network resources or attempting to map your environment
Data staging: Collecting and organizing files in preparation for theft
IOAs are proactive because they detect attacks in progress by correlating sequences of suspicious behaviors that indicate malicious intent. This gives you a chance to stop the breach before attackers achieve their goals.
IOA vs IOC: 8 critical differences
Understanding how IOAs and IOCs differ helps you build better defenses. Here's how they compare across key areas:
| Aspect | IOAs | IOCs |
|---|---|---|
| Timing | Detect attacks in progress | Identify past/ongoing compromise |
| Detection Method | Behavioral sequence analysis | Signature/indicator matching |
| Response Type | Prevent or contain active threats | Investigate and scope impact |
| Coverage | Catches unknown and zero-day | Focused on known threats |
| False Positives | Lower via sequence correlation | Higher from single matches |
| Maintenance | Requires TTP awareness | Requires intel feed updates |
| Use Cases | Real-time prevention, hunting | Forensics, IR, compliance |
| Effectiveness | Strong vs. novel methods | Strong vs. known threats |
The key difference is timing. IOAs help you prevent breaches while IOCs help you understand what happened after a breach occurs.
Mapping IOAs and IOCs to MITRE ATT&CK
MITRE ATT&CK provides a common language for detection engineering. IOAs map to techniques and procedures—the 'how' of an attack—while IOCs represent artifacts left behind.
Common IOA-to-ATT&CK mappings:
Privilege escalation attempts → T1068 (Exploitation for Privilege Escalation), T1078 (Valid Accounts)
Lateral movement → T1021 (Remote Services), T1570 (Lateral Tool Transfer)
Reconnaissance → T1595 (Active Scanning), T1087 (Account Discovery)
Data staging → T1074 (Data Staged), T1560 (Archive Collected Data)
IOCs support ATT&CK-based investigations:
When you detect an IOA like lateral movement (T1021), you extract IOCs—file hashes, IP addresses, registry keys—to hunt for the same technique across your environment. This combination enables both real-time prevention and thorough post-incident scoping.
Why behavioral detection outperforms signature-based approaches
Signature-based detection has a fundamental weakness—it can only find threats it already knows about. This approach is like trying to catch criminals by only looking for people who match old mugshots.
Attackers know this limitation and exploit it in several ways:
Zero-day exploits: Brand new vulnerabilities with no existing signatures
Living off the land attacks: Using legitimate tools (PowerShell, curl, WMI) for malicious purposes. Industry reports show these attacks are rising because they blend with normal activity, making behavioral analytics essential for detection.
Custom malware: Unique code that doesn't match any known signatures
Polymorphic threats: Malware that changes its signature to avoid detection
Behavioral detection solves these problems by focusing on what attackers do, not what tools they use. Even if an attacker uses a completely new piece of malware, their actions still follow predictable patterns.
For example, many data theft attacks follow patterns mapped in MITRE ATT&CK: reconnaissance (T1595), privilege escalation (T1068), lateral movement (T1021), and data exfiltration (T1041). IOAs can detect these behavioral patterns regardless of the specific tools involved.
This approach reduces alert fatigue by correlating multiple behaviors into higher-fidelity alerts instead of triggering on every suspicious file or IP address.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
Implementing IOAs and IOCs in cloud-native environments
Cloud environments create unique challenges for traditional threat detection:
Ephemeral infrastructure: Containers and serverless functions exist for minutes or hours. By the time you generate an IOC from a compromised container, that container no longer exists. Traditional IOC scanning of persistent systems doesn't work.
Shared responsibility model: You can't inspect hypervisor or physical network layers. Detection must focus on control plane API calls and workload behavior you can observe.
Identity-centric attacks: Cloud breaches often exploit IAM misconfigurations and stolen credentials rather than malware. Traditional file-hash IOCs miss these attacks entirely.
API-driven operations: Attackers use cloud APIs (CreateAccessKey, AssumeRole, ModifySecurityGroup) rather than traditional malware. IOAs must detect malicious API sequences, not just malicious binaries.
In the cloud, you need to adapt both IOAs and IOCs to work with dynamic infrastructure:
Cloud-native IOA sources by provider:
AWS: CloudTrail API calls, GuardDuty behavioral findings, VPC Flow Logs, EKS audit logs
Azure: Activity Logs, Defender for Cloud alerts, NSG Flow Logs, AKS audit logs
GCP: Cloud Audit Logs, Security Command Center findings, VPC Flow Logs, GKE audit logs
Cloud-native IOAs focus on:
API calls and cloud service interactions (AssumeRole, CreateAccessKey, ModifyInstanceAttribute)
Identity and access management (IAM) role abuse and privilege escalation
Cross-service lateral movement (EC2 to RDS, compute to storage)
Unusual resource creation or modification patterns
Cloud-native IOCs include:
Suspicious cloud audit log entries (anomalous AssumeRole calls, unexpected key creation)
Malicious binaries or file hashes from workload images
Outbound connections to known C2 infrastructure
Domains or IPs associated with prior incidents
Using IOAs and IOCs together for comprehensive threat detection
IOAs and IOCs work best when used together as part of a layered security strategy. Each approach covers the other's blind spots and provides different types of value.
Here's how they complement each other in a typical security workflow:
IOA Detection Phase: Your monitoring systems detect suspicious behavior—perhaps a container making unusual network connections and then accessing sensitive files. This behavioral pattern triggers an IOA alert.
Investigation Phase: Security analysts investigate the alert and discover the suspicious activity came from a malicious binary. They extract the file hash (an IOC) and identify the external IP address it connected to (another IOC).
Containment Phase: Using the newly identified IOCs, the team scans their entire environment to find other instances of the same threat. They also use the behavioral patterns from the original IOA to hunt for similar attacks that might be using different tools.
Recovery Phase: The team removes all instances of the malicious software and blocks the associated IOCs. They also implement new behavioral detection rules based on the attack patterns they observed.
This integrated approach supports real-time containment and thorough post-incident scoping per NIST SP 800-61 (Computer Security Incident Handling Guide) phases: detection, analysis, containment, eradication, and recovery. IOAs provide the early warning system while IOCs give you the evidence needed for complete remediation.
Compliance and regulatory value:
IOA and IOC detection supports multiple compliance frameworks:
SOC 2 Type II: Demonstrates continuous monitoring (CC7.2) and incident response capabilities (CC7.3)
ISO 27001: Addresses Annex A controls A.12.4 (logging and monitoring), A.16.1 (incident management)
NIST CSF: Fulfills Detect (DE.AE, DE.CM) and Respond (RS.AN) functions
GDPR Article 32: Provides technical measures to detect and respond to personal data breaches
Document your IOA/IOC workflows and retention policies to demonstrate due diligence during audits.
How Wiz Defend integrates behavioral and signature-based detection for cloud security
Wiz Defend combines IOA and IOC detection in a single platform designed for cloud environments. The system uses a lightweight eBPF-based runtime sensor to monitor container and workload behavior with minimal overhead—typically under 2% CPU impact.
Wiz combines agentless scanning with runtime detection for comprehensive coverage. Agentless scanning identifies risk conditions that create attack paths. Runtime sensors detect IOAs when attackers exploit those paths.
The platform's strength comes from context. When Wiz detects an IOA or IOC, it automatically correlates the finding with your cloud infrastructure to understand the real risk. The Wiz Security Graph maps relationships across resources, identities, networks, and data to prioritize threats by real blast radius—enabling risk-based prioritization instead of just severity scores.
When incidents occur, Wiz correlates IOAs and IOCs on the Security Graph to show the full attack chain, reducing mean time to understand (MTTU) from hours to minutes. Most importantly, Wiz traces runtime threats back to their source in code or infrastructure templates, enabling one-click remediation tickets that fix the root cause permanently.
Request a demo to see how behavioral IOAs and forensic IOCs come together with graph context for faster, cloud-native detection and response.
