How an IcedID Loader Attack Unfolds: A Case Study in EDR Evasion

Cloud-Native Architectures Shift Ransomware Risk to Data Integrity While cloud platforms improve availability and durability through replication, immutability, and automated recovery, they do not ensure data integrity. In cloud-native environments, compute is ephemeral and identity-driven, but persistent storage is long-lived and highly automated. This shifts ransomware risk away from servers and toward data itself. Modern ransomware increasingly exploits compromised cloud credentials and native APIs to encrypt or corrupt data gradually, often without triggering traditional malware detection. As a result, immutable backups and replicas can faithfully preserve corrupted data, leaving organizations unable to confidently restore clean systems. Ransomware resilience in cloud-native architectures therefore requires data integrity validation: continuous verification that backups, snapshots, and storage objects are clean, recoverable, and provably safe to restore. Without integrity assurance, recovery decisions depend on manual forensics, increasing downtime, operational risk, and regulatory exposure. Executive Strategic Assessment We have successfully re-architected our enterprise for the cloud, adopting a model where compute is ephemeral and infrastructure is code. In this environment, we no longer repair compromised servers; we terminate them. This success has created a dangerous blind spot. By making compute disposable, we have migrated our risk entirely to the persistent storage layer (S3, EBS, FSx, RDS). Our current architectural controls—S3 Versioning, Cross-Region Replication, and Backup Vault Locks—are designed for Durability and Availability. They guarantee that data exists and cannot be deleted. They do not guarantee that the data is clean. In cloud-native security, data integrity means the ability to cryptographically and behaviorally verify that stored data has not been silently encrypted, corrupted, or altered before it is used for recovery. In a modern ransomware attack, the threat is rarely that you "lose" your backups; it is that your automated, immutable systems perfectly preserve the corrupted state. If we replicate an encrypted database to a compliance-mode vault, we have not preserved the business—we have simply "vaulted the virus."Under the shared responsibility model, cloud providers protect the availability of the platform, while customers retain responsibility for ensuring the correctness and integrity of the data they store and recover. This brief analyzes the Integrity Gap in cloud-native resilience. It details the architectural controls required to transition from assuming a clean recovery to algorithmically proving it, ensuring that when the Board asks, The New Risk Reality: Ephemeral Compute, Permanent Risk Our migration to cloud-native architectures on AWS has fundamentally shifted our risk profile. We have moved from "repairing servers" to "replacing them." Compute is now disposable (containers, serverless functions, auto-scaling groups) and identity is dynamic (short-lived IAM credentials). This is a security win for the compute layer because the "crime scene" effectively evaporates during an incident. Cloud changes where risk concentrates, not whether risk exists. Recent incident analysis shows stolen credentials as a leading initial access vector, with median attacker dwell time measured in days rather than months. This compression of time is what enables low-and-slow data corruption to outrun human-driven validation. Multiple industry investigations support this pattern, including Mandiant and Verizon DBIR reporting that credential abuse and identity compromise are now among the most common initial access vectors in cloud environments, with attackers often persisting long enough to corrupt data before detection. However, this architecture forces a massive migration of risk into the persistent storage layer. Modern ransomware attacks exploit this shift by targeting the integrity of the state itself. Attackers encrypt object stores, poison transaction logs, or utilize automation roles to mass-modify snapshots.Why aren’t cloud-native architectures inherently ransomware-safe? Because cloud controls prioritize availability and automation, not verification of data correctness at restore time. The Strategic Blind Spot: Immutability is Not Integrity Our current resilience strategy aligns with AWS Well-Architected frameworks. We rely heavily on Availability and Durability. We use S3 Versioning, AWS Backup Vault Locks, and Cross-Region Replication. These controls are excellent at ensuring data exists and cannot be deleted. However, they fail to ensure the data is clean. Integrity controls verify recoverability and correctness of restoration assets, not just retention. Operationally, this means validating data for encryption or corruption, proving restore usability, and recording a deterministic “last known clean” recovery point so restoration decisions do not depend on manual forensics. In a "Low and Slow" corruption attack, a threat actor uses valid, compromised credentials to overwrite data or generate new encrypted versions over weeks. In cloud environments, attackers increasingly encrypt or replace data using native storage APIs rather than custom malware. Once access is obtained, legitimate encryption and snapshot mechanisms can be abused to corrupt data while appearing operationally normal.This creates a failure mode unique to cloud-native architectures: attacks can succeed without malware, without infrastructure compromise, and without violating immutability controls. The "Immutable Poison" Problem: If an attacker encrypts a production database, Backups will dutifully snapshot that corruption. If Vault Lock is enabled, we effectively seal the corrupted state in a compliance-mode vault. We have preserved the attack rather than the business. Vault Locking prevents deletion and lifecycle modification of recovery points, including by privileged users. It does not validate the integrity or cleanliness of the data being ingested and retained.Replication Accelerates Blast Radius: Because replication is designed for speed (RPO), it immediately propagates the corrupted state to the DR region. The Missing Control: Recovery Assurance During a ransomware event, the most expensive resource is decision time. The Board will not ask "Do we have backups?" They will ask "Which recovery point is the last known good state?" Without a dedicated integrity control, answering this requires manual forensics. Teams must mount snapshots one by one, scan logs, and attempt trial-and-error restores. This process turns a 4-hour RTO into a multi-day forensic ordeal. Industry data shows that organizations take months to fully identify and contain breaches, and multi-environment incidents extend that timeline further. This gap is why recovery cannot depend on snapshot-by-snapshot investigation during an active crisis. Critically, integrity validation produces durable evidence, timestamps, scan results, and clean-point attestations that can be reviewed by executives, auditors, and regulators as part of post-incident assurance. Where Elastio Fits: The Integrity Assurance Layer Elastio fits into our architecture not as a backup tool, but as an Integrity Assurance Control (NIST CSF "Recover") that audits the quality of our persistence layer. Detection in Depth: Unlike EDR which monitors processes, Elastio watches the entropy and structure of the data itself. It scans S3 buckets and EBS snapshots for the mathematical signatures of encryption and corruption.Provable Recovery: Elastio indexes recovery points to algorithmically identify the "Last Known Clean" timestamp. This allows us to automate the selection of a clean restore point and decouple recovery time from forensic complexity. Platform Engineering Guide Architecture Context Elastio operates as an agentless sidecar. It utilizes scale-out worker fleets to mount and inspect storage via standard Cloud APIs (EBS Direct APIs, S3 GetObject, Azure APIs). It does not require modifying production workloads or installing agents on production nodes. Protection Capabilities by Asset Class 1. AWS S3 & Azure Blob Data Lakes Real-Time Inspection: The system scans objects in real-time as they are created. This ensures immediate detection of "infection by addition."Threat Hunting: If threats are found, automated threat hunts are performed on the existing objects/versions to identify the extent of the compromise.Recovery: The system identifies the last known clean version, allowing restores to be automated and precise. 2. Block Storage (EBS, EC2, Azure Disks, Azure VMs) Scale-Out Scanning: Automated scans of persistent storage are performed using ephemeral, scale-out clusters. This ensures that inspection does not impact the performance of the production workload.Policy Control: For long-lived workloads (e.g., self-hosted databases), policies control how frequently to scan (e.g., daily, hourly, or on snapshot creation) to balance assurance with cost. Integrity validation frequency must be faster than plausible time-to-impact. With ransomware dwell time measured in days, weekly validation leaves material integrity gaps. For critical, high-risk workloads, production data validation can be configured to run as frequently as hourly, based on policy and business criticality, while lower-risk assets can operate at longer intervals to balance assurance, cost, and operational impact. 3. AWS Backup Scan-on-Create: Automated scanning of backups occurs immediately as they are created.Asset Support: Supports EC2, EBS, AMI, EFS, FSx, and S3 backup types.Vault Integration: Fully integrated with AWS Backup Restore Testing and Logically Air-Gapped (LAG) Vaults, ensuring that data moving into high-security vaults is verified clean before locking. 4. Azure Backup Scan-on-Create: Automated scanning of backups occurs immediately as they are created.Asset Support: Supports Azure VM, Azure Managed Disks, and Azure Blobs. 5. Managed Databases (RDS / Azure Managed SQL) Status: Not Supported.Note: Direct integrity scanning inside managed database PaaS services is not currently supported. Table 1: Threat Manifestation & Control Fit Architecture ComponentThe "Native" Failure ModeProtection Available (Elastio)AWS S3 / Azure Blob"Infection by Addition"Ransomware writes new encrypted versions of objects. The bucket grows, and "current" versions are unusable.Real-Time Detection & HuntingScans real-time as objects are created. Automates threat hunts for last known clean versions. Automates restores.EC2 / Azure VMs(Self-Hosted DBs)The "Live Database" AttackAttackers encrypt database files (.mdf, .dbf) while the OS remains up. Standard snapshots capture the encrypted state.Automated Integrity ScansAutomated scans of persistent storage in scale-out clusters. Policies control scan frequency for long-lived workloads.AWS BackupVault PoisoningWe lock a backup that was already compromised (Time-to-detect > Backup Frequency).Scan-on-Create (Vault Gate)Automated scanning of backups (EC2, EBS, AMI, EFS, FSx, S3) as they are created. Integrated with AWS Restore Test and LAG Vaults.Azure BackupReplica CorruptionBackup vaults replicate corrupted recovery points to paired regions.Scan-on-CreateAutomated scanning of Azure VM, Managed Disk, and Blob backups as they are created.Managed DBs(RDS / Azure Managed SQL)Logical CorruptionValid SQL commands drop tables or scramble columns.Not SupportedIn these environments, integrity assurance must be addressed through complementary controls such as transaction log analysis, application-layer validation, and point-in-time recovery testing. Conclusion Adopting this control moves us from a posture of "We assume our immutable backups are valid" to "We have algorithmic proof of which recovery points are clean." In an era of compromised identities, this verification is the requisite check-and-balance for cloud storage. This control removes uncertainty from recovery decisions when time, trust, and data integrity matter most.In cloud-native environments, ransomware resilience is no longer defined by whether data exists, but by whether its integrity can be continuously proven before recovery.In practical terms, any cloud-native ransomware recovery strategy that cannot deterministically identify a last known clean recovery point before restoration should be considered operationally incomplete. This perspective reflects patterns we consistently see in enterprise incident response, including insights shared by Elastio advisors with deep experience leading ransomware investigations and cloud recovery efforts.

Elastio and AWS recently hosted a joint webinar, “Modern Ransomware Targets Recovery: Here’s What You Can Do to Stay Safe.” The session brought together experts to unpack how ransomware tactics are evolving and what organizations need to do differently to stay resilient. A clear theme emerged. Attackers are no longer focused on disruption alone. They are deliberately sabotaging recovery. Ransomware Has Shifted From Disruption to Recovery Sabotage Modern ransomware no longer relies on fast, obvious encryption of production systems. Instead, attackers often gain access months in advance. They quietly study the environment, including backup architectures, replication paths, and retention windows. Encryption happens slowly and deliberately, staying below detection thresholds while corrupted data propagates into snapshots, replicas, and backups. By the time the attack is triggered and ransom is demanded, recovery options are already compromised. This represents a fundamental shift in risk. Backups are no longer just a safety net. They are a primary target. Ransomware Risk Is Unquantifiable Without Proven Clean Recovery Points Ransomware risk becomes impossible to quantify when organizations cannot prove their recovery data is clean. Boards, regulators, and insurers are no longer reassured by the mere existence of backups. They want to know how quickly recovery can happen, which recovery point will be used, and how its integrity is verified. Most organizations cannot answer these questions with confidence because backup validation is not continuous. The consequences are real. Extended downtime, board-level exposure, insurance gaps, and growing regulatory pressure under frameworks such as DORA, NYDFS, and PRA. Without proven clean recovery points, ransomware becomes an unbounded business risk rather than a technical one. The Three Pillars of Ransomware Recovery Assurance The webinar emphasized that real ransomware resilience depends on three pillars working together. Immutability and isolation ensure backups are tamper-proof and stored separately, protected by independent encryption keys. AWS capabilities such as logically air-gapped vaults support this foundation.Availability focuses on whether recovery can happen fast enough to meet business expectations, particularly when identity systems are compromised. Clean-account restores and multi-party approval become critical.Integrity, the most overlooked pillar, ensures backups are continuously validated to detect encryption, corruption, malware, and fileless attacks, and to clearly identify the last known clean recovery point. If any pillar fails, recovery fails. For more information: Resilience by design: Building an effective ransomware recovery strategy | AWS Storage Blog Malware Scanning Is Not Ransomware Detection The speakers drew a clear distinction between traditional malware scanning and what is required to defend against modern ransomware. Signature-based tools look for known binaries, but today’s attacks often run in memory, use polymorphic techniques, and encrypt data without leaving a detectable payload. In these cases, the absence of malware does not mean the absence of damage. Effective ransomware defense requires detecting the impact on data itself, including encryption, corruption, and abnormal change patterns, not just the presence of malicious code. Validation Enables Faster, Safer Recovery Without Paying Ransom A real-world case study illustrated the value of recovery validation. Attackers encrypted data gradually over several days, allowing compromised data to flow into backups that appeared intact but were unsafe to restore. Through targeted threat hunting, Elastio identified a clean recovery point from roughly six days earlier, enabling the company to restore operations without paying the ransom. With downtime costs often reaching millions per day, even small reductions in recovery time have outsized financial impact. The takeaway was simple. Knowing where to recover from matters more than recovering quickly from the wrong place. Key Takeaways Ransomware now targets recovery, not just production.Attackers gain access early, encrypt data slowly, and ensure corruption spreads into replicas and backups before triggering an attack. By the time ransom is demanded, recovery paths are often already compromised.Backups alone are not proof of recoverability.Without continuous validation, organizations cannot confidently identify a clean recovery point, making ransomware risk impossible to quantify.True ransomware resilience depends on three pillars.Immutability and isolation protect backups from tampering, availability ensures recovery meets business expectations, and integrity validation confirms recovery data is usable. If integrity fails, recovery fails.Malware detection is not ransomware detection.Fileless and polymorphic attacks often evade signature-based tools. Detecting the impact on data, such as encryption and corruption, is critical.Provable recovery changes the economics of ransomware.Validated recovery points reduce downtime, avoid reinfection, and can eliminate the need to pay ransom, delivering measurable operational and financial impact. Additional Resources AWS ReInvent: How Motability Operations built a ransomware-ready backup strategy with AWS Backup & Elastio AWS re:Invent 2025 - Motability Operations' unified backup strategy: From fragmented to fortified

GuardDuty’s release of malware scanning on AWS Backup is an important enhancement to the AWS ecosystem, reflecting growing industry recognition that inspecting backup data has become a core pillar of cyber resilience. But real-world incidents show that ransomware often leaves no malware behind, making broader detection capabilities for encryption and zero-day attacks increasingly essential. Across industries, there are countless examples of enterprises with premium security stacks in place - EDR/XDR, antivirus scanners, IAM controls - still suffering extended downtime after an attack because teams couldn’t reliably identify an uncompromised recovery point when it mattered most. That’s because ransomware increasingly employs fileless techniques, polymorphic behavior, living-off-the-land tactics, and slow, stealthy encryption. These campaigns often reach backup andreplicated copies unnoticed, putting recovery at risk at the very moment organizations dependon it. As Gartner puts it: Modern ransomware tactics bypass traditional malware scanners, meaning backups may appear ‘clean’ during scans but prove unusable when restored. Equip your recovery environment with advanced capabilities that analyze backup data using content-level analytics and data integrity validation.”— Gartner, Enhance Ransomware Cyber Resilience With A Secure Recovery Environment, 2025 This is the visibility gap Elastio was designed to close. In this post, we walk through how Elastio’s data integrity validation works alongside AWS GuardDuty to support security and infrastructure teams through threat detection all the way to recovery confidence and why integrity validation has become essential in the age of identity-based and fileless attacks. What is AWS GuardDuty? AWS GuardDuty is a managed threat detection service that continuously monitors AWS environments for malicious or suspicious activity. It analyzes signals across AWS services, including CloudTrail, VPC Flow Logs, DNS logs, and malware protection scans, and produces structured security findings. GuardDuty integrates natively with Amazon EventBridge, which means every finding can be consumed programmatically and routed to downstream systems for automated response. For this integration, we focus on GuardDuty malware findings, including: Malicious file findings in S3Malware detections in EC2 environments These findings are high-confidence triggers that indicate potential compromise and warrant immediate validation of recovery data. Learn more about GuardDuty. Why a GuardDuty Finding Should Trigger Recovery Validation Malware detection is important, but it is no longer sufficient to validate data recoverability. Identity-based attacks dominate cloud breaches Today’s attackers increasingly rely on stolen credentials rather than exploits. With valid identities, they can: Use legitimate AWS APIsAccess data without dropping malwareBlend into normal operational behavior In these scenarios, there may be nothing malicious to scan, yet encryption or tampering can still occur. Fileless and polymorphic ransomware evade signatures Many ransomware families: Run entirely in memoryContinuously mutate their payloadsAvoid writing recognizable artifacts to disk Signature-based scanners may report “clean,” even as encryption spreads. Zero-day ransomware has no signatures By definition, zero-day ransomware cannot be detected by known signatures until after it has already caused damage - often widespread damage. The result is a dangerous failure mode: backups that scan clean but restore encrypted or corrupted data. Why Integrity Validation Changes the Outcome Elastio approaches ransomware from the impact side. Instead of asking only “is malware present?”, Elastio validates: Whether encryption has occurredWhat data was impactedWhen encryption startedWhich recovery points are still safe to restore The timeline above reflects a common real-world pattern: Initial access occurs quietlyEncryption begins days or weeks laterBackups continue, unknowingly capturing encrypted dataThe attack is only discovered at ransom time Without integrity validation, teams cannot know with confidence that their backups will work when they need them. This intelligence transforms a GuardDuty finding from an alert into an actionable recovery decision. Using GuardDuty as the Trigger for Recovery Validation Elastio’s new GuardDuty integration automatically initiates data integrity scans when GuardDuty detects suspicious or malicious activity. Instead of stopping at alerts, the integration immediately answers the implied next question: Did this incident affect our data, and can we recover safely? By validating backups and recovery assets in response to GuardDuty findings, Elastio reduces response time, limits attacker leverage, and enables faster, more confident recovery decisions. Architecture Overview At a high level: GuardDuty generates a malware findingThe finding is delivered to EventBridgeEventBridge routes the event into a trusted sender EventBusElastio’s receiver EventBus accepts events only from that senderElastio processes the finding and starts a targeted scanTeams receive recovery-grade intelligenceIncluding:Ransomware detection resultsFile- and asset-level impactLast known clean recovery pointOptional forwarding to SIEM or Security Hub The critical design constraint: trusted senders Each Elastio customer has a dedicated Receiver EventBus. For security reasons, that receiver only accepts events from a single allowlisted Sender EventBus ARN. This design ensures: Strong tenant isolationNo event spoofingClear security boundaries To support scale, customers can route many GuardDuty sources (multiple accounts, regions, or security setups) into that single sender bus. Elastio enforces trust at the receiver boundary. End-to-End Flow Step 1: GuardDuty detects malware GuardDuty identifies a malicious file or suspicious activity in S3 or EC2 and emits a finding. Step 2: EventBridge routes the finding Native EventBridge integration allows customers to filter and forward only relevant findings. Step 3: Sender EventBus enforces trust All GuardDuty findings flow through the designated sender EventBus, which represents the customer’s trusted identity. Step 4: Elastio receives and buffers events The Elastio Receiver EventBus routes events into an internal queue for resilience and burst handling. Step 5: Elastio validates recovery data Elastio maps the finding to impacted assets and initiates scans that analyze both malware indicators and ransomware encryption signals. Step 6: Recovery-grade results Teams receive actionable results: Ransomware detectionFile-level impactLast known clean recovery pointOptional forwarding to SIEM or Security Hub What This Enables for Security and Recovery Teams By combining GuardDuty and Elastio, organizations gain: Faster response triggered by high-signal findingsEarly detection of ransomware encryption inside backupsReduced downtime and data lossConfidence that restores will actually workAudit-ready evidence for regulators, insurers, and leadership Supported Today S3 malware findingsEC2 malware findings EBS-specific handling is in progress and will be added as it becomes available. Why This Matters in Practice In most ransomware incidents, the challenge isn’t identifying a security signal - it’s understanding whether that signal corresponds to meaningful data impact, and what it implies for recovery. Security and infrastructure teams often find themselves piecing together information across multiple tools to assess whether encryption or corruption has reached backups or replicated data. That assessment takes time, and during that window, recovery decisions are delayed or made conservatively. By using GuardDuty findings as a trigger for integrity validation, customers introduce earlier visibility into potential data impact. When suspicious activity is detected, Elastio provides additional context around whether recovery assets show signs of encryption or corruption, and which recovery points appear viable. This doesn’t replace incident response processes or recovery testing, but it helps teams make better-informed decisions sooner, particularly in environments where fileless techniques and identity-based attacks limit the effectiveness of traditional malware scanning. Extending GuardDuty From Detection Toward Recovery Readiness GuardDuty plays a critical role in surfacing high-confidence security findings. Elastio extends that signal into the recovery domain by validating the integrity of data organizations may ultimately depend on to restore operations. Together, they help teams bridge the gap between knowing an incident may have occurred and assessing recovery readiness, with supporting evidence that can be shared across security, infrastructure, and leadership teams. For organizations already using GuardDuty, this integration provides a practical way to connect detection workflows with recovery validation without changing existing security controls or response ownership. Watch our discussion: Understanding Elastio & AWS GuardDuty Malware Scanning for AWS Backup An open conversation designed to answer customer questions directly and help teams understand how these technologies work together to strengthen recovery posture. How signature-based malware detection compares to data integrity validationReal-world scenarios where behavioral and encryption-based detection mattersHow Elastio extends visibility, detection, and recovery assurance across AWS, Azure, and on-prem environmentsAn early look at Elastio’s new integration launching at AWS re:Invent