Breaking Down S3 Ransomware: Variants, Attack Paths and Trend Vision One™ Defenses

In this blog entry, Trend™ Research explores how ransomware actors are shifting their focus to cloud-based assets, including the tactics used to compromise business-critical data in AWS environments.

By: Yash Verma Nov 18, 2025 Read time: ( words)

Ransomware has long been a persistent threat, traditionally targeting on-premises environments through tactics such as network intrusions, phishing emails, malicious attachments, and exploitation of outdated or vulnerable software.

However, as organizations shift to the cloud, ransomware tactics are adapting: In cloud environments, attackers are increasingly exploiting customer misconfigured storage resources and stolen credentials. Unlike traditional ransomware that relies heavily on encryption malware, cloud-focused variants often leverage native cloud features to delete or overwrite data, suspend access, or extract sensitive content – all while staying under the radar of traditional security tools.

In this blog entry, Trend™ Research examines how ransomware actors are increasingly targeting cloud-native assets, what makes these resources appealing targets for attackers, and detail different kinds of ransomware attacks that could affect AWS environments by discovering access keys that provide permissions to call various S3 APIs.

Ransomware actors increasingly focus on cloud-native assets that hold or enable quick recovery of critical business data and infrastructure. The following Amazon Web Services (AWS) resources are prime targets due to their high value and potential to disrupt operations:

Compute snapshots – point-in-time copies of virtual machine disks or volumes – like Amazon Elastic Block Store (EBS) snapshots could be targeted, as organizations rely on them for rapid recovery of EC2 instances after failure or compromise. Without snapshots, rebuilding systems from scratch could take days. Mission-critical applications hosted on EC2 may remain offline, causing prolonged disruption and potential data loss unless the ransom is paid.

If an attacker gains access to snapshot management permissions, they can encrypt the original EC2 volumes and delete the snapshots, leaving no recovery option. Attackers could also delete both EC2 instances and snapshots after copying it in their own environment, ensuring compute environments can’t be restored.

Cloud static storage such as Amazon Simple Storage Service (S3) Buckets are also a potential target, because S3 is often used to store backup files, logs and analytics data, static website content, application assets, or infrastructure configs like Terraform state files.

If access is misconfigured or credentials are leaked, attackers could encrypt existing data and upload ransom notes, delete original data or overwrite it with corrupted files. This would impact business operations and services relying on that data. If the S3 bucket contained backups or historical logs, the victim loses both operational and forensic recovery options.

Another potential target are cloud databases like Amazon RDS (PostgreSQL, MySQL, etc.), Aurora, and DynamoDB . Cloud databases often contain the most sensitive and valuable data such as customer information, transactions, credentials, and telemetry. If an attacker compromises access, they can exfiltrate, encrypt, or delete database records. They may also delete automated backups and snapshots to block recovery.

Such an attack impacts the functionality of applications, compromise user data, and bring regulatory consequences (like GDPR violations). Recovery without a functioning backup can be near-impossible, increasing pressure on victims to pay the ransom.

Container images and registries

The likes of Amazon Elastic Container Registry (ECR) and other container images and registries could also be targeted, as containerized workloads (including microservices and apps) rely on container images stored in ECR. Attackers targeting ECR can delete images, halting application deployment pipelines, or replace images with malicious or broken versions. Compromised container images and registries could lead to the failure of CI/CD pipelines, app crashes upon redeployment, and difficulties in applying auto-scaling or container replacement strategies. Even if code is safe, without the image, it can't be redeployed, potentially crippling production environments.

Cloud backups and disaster recovery systems

Backups are the final safety net in any ransomware scenario, so backups in S3, Glacier, or managed via AWS Backup may be an attractive target. Smart attackers know that eliminating backups ensures leverage. If they get access to backup vaults or the buckets storing backup files, they can permanently delete backups, encrypt or corrupt backup files, and modify retention settings to expire backups prematurely. Even if primary systems are restored, without clean backups, businesses can’t guarantee data integrity. In many real-world cases, companies with no backup resorted to ransom payments as their only recovery path.

Among all targets in AWS, Amazon S3 stands out as the most widely used and business critical. It serves as the backbone for storing everything from application data and media files to backups and infrastructure assets. Given its central role in data storage, S3 is also a high-value target for ransomware actors. In the sections ahead, we'll explore why S3 is so attractive to attackers and how ransomware campaigns can compromise S3 data to demand ransom.

Amazon S3 offers several options for encrypting data at rest:

Target selection – Finding the ideal S3 bucket

Before executing the attack, the adversary evaluates potential S3 buckets based on the following criteria:

Attacker’s goal – Achieve complete and irreversible lockout

Once a suitable S3 target is identified and accessible, the attacker’s goal is to render the data unreadable and unrecoverable . They may do so through various means, such as:

Variant 1 (Using default AWS KMS keys – SSE-KMS)

A public proof-of-concept (PoC) was released in 2019 describing how S3 ransomware attacks can be simulated in AWS environment using default AWS KMS key option. The procedure (Figure 1) is as follows:

1. The attacker gains write-level access to the victim’s S3 bucket/s (for example, via leaked IAM role credentials from public source code on GitHub or by compromising the AWS account).

2. They create a customer-managed symmetric Customer Master Key (CMK) using KMS in their own AWS account, configured to be world-readable (Figures 2 and 3).

This policy enables any AWS account to use the KMS key for performing encryption, aka, world-readable.

3. S3 access allows the attacker to enumerate and pinpoint vulnerable buckets (Figure 4).

4. Then, they proceed to encrypt the objects in the vulnerable bucket using the KMS key (Figure 5). AWS KMS requires scheduling a key deletion with a minimum of seven days’ advanced notice.

5. The attacker schedules the deletion of the KMS key used in the attack, giving the victim a seven-day deadline before the key – and access to the data – is permanently lost.

6. After encryption is completed, a file named 'ransom-note.txt' is uploaded, and the KMS key is scheduled for deletion in seven days. Once the CMK is deleted, the encrypted data becomes permanently inaccessible.

This variant is most likely to occur as a cross-account attack, since executing it from within the victim's AWS account could grant the victim’s privileged users access to the key. This variant i s unlikely to occur in real world because it takes minimum of seven days to delete the key, and there is good chance that AWS support might intervene by that time and recover the key.

Variant 2 (Using server-side encryption using customer provided keys – SSE-C)

Early this year, security researchers published a blog entry detailing how a threat actor called Codefinger leveraged SSE-C to carry out ransomware activity on S3 buckets. The process, shown below in Figure 6, is as follows:

1. The attacker gains write-level access to the victim’s S3 bucket/s (via leaked IAM role credentials from public source code on GitHub or by compromising the AWS account, for example).

2. Attacker enumerates S3 buckets to find an ideal target.

3. The attacker initiates server-side encryption by providing a locally stored AES-256 key using the x-amz-server-side-encryption-customer-algorithm header via REST API, HTTP requests, or AWS SDKs. Note: users don't directly set headers when using the SDK or CLI tools.

4. AWS uses the key for encryption but does not store it; only the key’s hashed-based message authentication code (HMAC) is logged in CloudTrail, which cannot be used to recover the original key or decrypt the data.

5. After encryption is completed, the ransom note is deposited in the bucket.

This variant is more likely to occur than others because the attacker controls the encryption key when using SSE-C, leaving both the customer and AWS with no way to recover the encrypted data. The combined policy for SSE-C and KMS ImportKeyMaterial and External Key Store vectors is as follows:

Customers can prevent this by adding this policy to their RCP:

Customers can also add the following to their bucket policies:

Customers who do not use AWS Organizations can apply the bucket policy statement below to their buckets to deny all upload and copy requests with SSE-C (Please note that the sample bucket ARN in the following policy should be updated with the actual bucket ARN):

Variant 3 (S3 exfiltration and deletion)

Last year, it was reported that the threat actor Bling Libra used stolen AWS credentials to access and delete data from S3 buckets, then extorted victims by threatening data destruction or leaks. The procedure is as follows (Figure 7):

1. The attacker gains write-level access to the victim’s S3 bucket/s, either through leaked IAM role credentials or by compromising the AWS account.

2. Attacker enumerates S3 buckets for an ideal target.

3. The attacker exfiltrates all data from the S3 bucket into their own environment to use as ransom leverage.

4. The attacker deletes all object data from the S3 bucket or deletes the bucket entirely.

5. The attacker leaves ransom notes in the original bucket (if it still exists) or creates new buckets with ransom-related names, as seen in the Bling Libra case.

This variant is also more likely to occur as it’s a simple two-step process of exfiltration and deletion, and it makes data irrecoverable by customer or AWS support.

Variant 4 (Using AWS KMS External Key Material)

The security community has become increasingly aware of the risks associated with SSE-C following Codefinger’s S3 ransomware attack leveraging SSE-C , and many organizations have since restricted or blocked its use. However, there are other potential vectors that attackers could exploit to achieve similar outcomes that may not be as well known.

One of these lesser-known attack variants is the use of KMS external key material. Users can create a KMS key in AWS using their own key material in a process called Bring Your Own Key (BYOK). Instead of letting AWS generate the key material, users can import it themselves, which would allow them to maintain control over the key's origin, durability, and lifecycle while AWS KMS manages its usage within AWS services.

In imported external key material, expiration can be set to any duration, making it an attractive feature for attackers in ransomware scenarios, in which they could deliberately set a short expiration to render the key (and encrypted data) inaccessible to both customers and AWS.

The process, as shown in Figure 8, is as follows:

1. The attacker gains write-level access to the victim’s S3 bucket(s), either through leaked IAM role credentials or by compromising the AWS account.

2. Attacker enumerates S3 buckets for an ideal target.

3. Attacker tries SSE-C encryption, but it fails as it was blocked, so they tried another option in KMS using external key material.

4. They create a customer-managed symmetric CMK using the KMS option “External (Import Key Material)” in their own AWS account that is configured to be world-readable (Figures 9 and 10).

5. They select the wrapping key and algorithm, as shown in Figure 11.

6. They download a wrapping public key and import a token on a local machine and wrap their own newly created key with the wrapper public key:

7. Now, the attackers upload the final key and import token (Figure 12). They also set the expiration time to 24 hours or less, as attackers tend to keep the expiration window as small as possible to destroy the key and keep it out of reach of AWS.

8. The newly created KMS key’s Amazon Resource Name (ARN) is used by attacker to encrypt the targeted AWS account’s S3 bucket and finally delete it to keep it out of reach of AWS and the customer.

Customers can apply the policy statement below to their identity policies to deny the use of the AWS KMS Import Key Material and AWS KMS External Key Store features. Please note that the sample kms:ViaService condition in the following policy should be updated with the relevant AWS Region for Amazon S3:

This variant could also be carried out from the victim’s AWS account. This means that if attackers have sufficient access, they can create a KMS and import their key material in victim’s environment itself. This variant hasn't happened in the real world, but it is a potential vector for S3 ransomware attacks as the key is not accessible to customers or AWS.

Variant 5 (using External Key Store - XKS)

The KMS External Key Store (XKS) is an AWS KMS feature that lets customers use cryptographic keys stored entirely outside of AWS, such as in an on-premises hardware security module (HSM) or third-party key management system, while still performing cryptographic operations through AWS KMS. Unlike traditional imported key material-where AWS holds a copy, the key in XKS never leaves your environment and is never visible to AWS. To enable this, AWS KMS communicates with a customer’s external key management system via an XKS proxy, a component customers must deploy and manage. The XKS proxy acts as a bridge between AWS KMS and your external key infrastructure, securely forwarding cryptographic requests from AWS to your key store and returning the results.

In 2024, a PoC was released related to exploiting AWS KMS and XKS to potentially bypass encryption and access sensitive data during a ransomware attack. However, this attack variant depends on discovering leaked IAM role credentials or by compromising the AWS account. To carry out AWS XKS encryption with Amazon S3, the attacker would follow these steps (Figure 13):

1. Clones the AWS XKS proxy reference implementation. AWS provides a sample implementation of the XKS proxy GitHub clone . This proxy acts as an intermediary between AWS KMS and the external key manager.

2. Changes the config file:

aws-kms-xks-proxy/xks-axum/configuration/settings_docker.toml

Uri prefix, access (start with AKIA), secret, xks_key_id can be anything, just note it somewhere.

Note that if a user is using a region other than us-east-1 , the file must also be updated near the top here:

3. Builds and runs the XKS proxy on attacker’s environment.

The repository includes a Docker file to build the proxy:

They verify that the proxy is running:

curl

They should receive a response like:

pong from xks-proxy v3.1.2-unknown

4. AWS will ask customers for their key stores’ HTTPS link. However, creating a domain would be costly for an attacker and risks exposing them, so they instead use ngrok to tunnel the local host to a temporary HTTPS public site. Then, they log in using their Google account to ngrok and copy the ngrok authentication token to their Linux machine (Figure 14).

5. They connect to ngrok with a local host port on which the docker is running:

ngrok http

6. Copies the domain name generated after that and saves it, as this will be the XKS proxy link.

7. The attacker goes to their AWS account and creates a key store:

KMS CMK > Symmetric > Encrypt & Decrypt > Adv option > External Key Store

8. After connecting to the key store, the attacker enters all the details which they noted, like the URI domain endpoint created by ngrok, and other information in the config file like the URI path (Figure 15).

9. They fill out all prescribed fields, including external key ID. (This is ‘foo’ unless they changed it in earlier steps.)

10. They change the key policy as in variants to make it world-readable or edit it to add a principal AWS account, which is the target account with the target S3.

11. They copy the key ARN created and use it to encrypt the target AWS account’s S3 bucket.

Customers can prevent this by creating the policy below to protect against Scenarios 4 and 5:

This variant could also be carried out from the victim’s AWS account. This means that if attackers have sufficient access, they could create the XKS proxy in victim’s environment itself. This variant also hasn't happened in the real world, but it is a potential vector for S3 ransomware attacks, as the key is not accessible to either customers or AWS.

Trend Vision One™ is the only AI-powered enterprise cybersecurity platform that centralizes cyber risk exposure management and security operations, delivering robust layered protection across on-premises, hybrid, and multi-cloud environments.

Detecting S3 ransomware requires deep visibility into AWS CloudTrail events, where every access, modification, and encryption action is logged.

Trend Vision One leverages these logs to identify these behaviors, identify suspicious encryption patterns, and surface high-fidelity workbench detections that map to different ransomware variants.

Below are categorized detections observed across multiple ransomware stages, from reconnaissance and privilege escalation to encryption and ransom note placement.

Variant-specific workbench detections

The following workbench detections highlight specific attack patterns attributed to the different ransomware variants described in this blog entry, allowing organizations to act quickly against distinct attack methods:

AWS Possible S3 Ransomware Activity Detected (Variants 1, 4, 5) Detected possible ransomware activity on a S3 bucket which can lead to important data encryption, loss or corruption, operational disruption, financial losses and much more.

AWS S3 Object Upload Using Custom Encryption (Variant 2) This detection identifies objects uploaded to S3 with non-standard encryption settings. Custom encryption methods may indicate security-conscious operations or an attempt to bypass default AWS encryption mechanisms. If unauthorized, this could lead to data obfuscation, making monitoring and access control more challenging.

AWS S3 Data Encrypted with Imported Key and Key Material Deleted (Variant 4) Detects encryption of S3 data using an imported KMS key, followed by deletion of the key material, which can lead to permanent data loss and might indicate a possible S3 ransomware activity.

AWS S3 Potential Ransomware Activity via Bulk Download and Deletion (Variant 3) Identifies potential ransomware behavior involving bulk download and subsequent deletion of S3 objects, indicating possible data exfiltration and destruction.

Generic workbench detections (pre- and post-attack phases)

While the above detections tie to specific ransomware variants, several generic detections help identify precursor and aftermath activities that often accompany ransomware campaigns:

AWS S3 Successful Resource Enumeration Attempt Detected possible successful enumeration of AWS S3 bucket which can lead to information exposure, unauthorized access, data leakage, account compromise, and operational disruption.

AWS S3 Unsuccessful Resource Enumeration Attempt Detected possible unsuccessful enumeration of AWS S3 bucket which can lead to information exposure, unauthorized access, data leakage, account compromise, and operational disruption.

AWS S3 Bucket Potential Ransomware Note Uploaded This detection identifies potential ransomware indicators in an AWS S3 bucket by monitoring for uploaded files resembling ransom notes. Attackers often place ransom notes in compromised buckets to inform victims of data encryption and extortion demand.

AWS S3 Bucket Discovery and Access Validation Monitors and attempts to discover and validate access to S3 buckets within an AWS account, which could indicate legitimate storage management activities or reconnaissance attempts by adversaries to identify accessible data repositories for potential data exfiltration attacks.

AWS S3 Bucket Encryption Configuration Modified Modification of an S3 bucket's encryption settings was detected, which may impact data security. Improper changes can disable encryption or weaken protection, increasing the risk of data exposure. Reviewing such modifications helps ensure sensitive information remains securely protected.

AWS S3 Bucket Policy Successfully Applied This model detects successful modification of S3 bucket policy, potentially by an authorized user or attacker. Impacts data security and access control settings of S3 buckets, potentially altering access permissions or data integrity.

AWS S3 Bucket Public Access Granted Identifies when a policy change grants public access to an S3 bucket. The alert indicates that the bucket is now accessible to anyone, increasing the risk of unauthorized access and potential data exposure.

AWS S3 Bucket Deletion This model detects the use of the S3 Delete Object or Delete Bucket API calls, which indicate attempts to delete individual objects or entire buckets from S3 storage. These actions are critical as they can lead to data loss, disruption of operations, or unauthorized removal of resources.

AWS S3 Server Access Logging Disabled For A Bucket Detects instances where server access logging is disabled for an Amazon S3 bucket. Indicates a potential security misconfiguration or an attempt to conceal access activities. Attacker can compromise visibility into S3 bucket access, hindering audit trails and accountability for data interactions.

AWS S3 Suspicious Public Access Block Removal Detected Deletion of Public Access Block for a bucket to expose the bucket publicly, leading to Confidential data leak.

AWS S3 Possible Credential Files Download Detected possible credential file download from a AWS S3 bucket which can lead to account breaches, data breaches, financial loss, identity theft, system disruption, and reputational damage.

Important IAM workbench detections that could lead to S3 ransomware attacks

Before ransomware activity begins, adversaries often perform identity- and access-related manipulations to gain or expand control over AWS resources. The following detections highlight suspicious IAM operations that might lead up to or enable S3 ransomware attacks if exploited by a malicious actor:

AWS IAM Policy Attached To User Or Role Or Group An attachment of an AWS IAM policy to user or group or role was detected which might indicate an attacker trying to escalate his privileges to compromise the AWS account.

AWS IAM Administrator Access Policy Attached To A Role The attachment of AdministratorAccess AWS managed policy to a role, giving full administrator access to the AWS environment, was observed.

AWS IAM Administrator Access Policy Attached To A User Detected the attachment of Administrator Access AWS managed policy to a user, giving full administrator access to the AWS environment.

AWS IAM Administrator Access Policy Attached To A Group The attachment of AdministratorAccess AWS managed policy to a group, giving full administrator access to the AWS environment, was observed.

AWS IAM Create/Update Full Administrative Privileged Inline Policy For a Group The creation or an update of a policy with full administrative privilege attached to a group, giving full administrator access to the AWS environment, was observed.

AWS IAM Create/Update Full Administrative Privileged Inline Policy For a User The creation or an update of a policy with full administrative privilege attached to a user, giving full administrator access to the AWS environment, was observed.

AWS IAM Create/Update Full Administrative Privileged Inline Policy For a Role The creation or an update of a policy with full administrative privilege attached to a role, giving full administrator access to the AWS environment, was observed.

AWS IAM Login MFA Deactivated For A User This model detects the deactivation of MFA linked to a user which might be an indication of AWS user compromise.

AWS IAM Role Over Privileged Trust Policy Created Detected the creation of an excessively permissive trust policy for a role, which might indicate the installation of a backdoor by an attacker to assume that role from any external AWS account later and potentially compromise the target AWS account further.

AWS IAM Create New Access Key for User Detected the creation of new access key for an IAM user which might indicate an attacker trying to persist in the AWS environment and use this key to further carry out other attacks in the account.

Trend Vision One Cloud Risk Management includes over 28 dedicated S3 security rules (S3-001 through S3-028) that help detect misconfigurations attackers exploit in ransomware attacks. Key rules directly aligned with S3 ransomware prevention include:

These rules support real-time posture monitoring , providing immediate alerts when configurations change. For the complete rule catalog and detailed remediation guidance, refer to Cloud Risk Management Knowledge Base in your Trend Vision One console.

As ransomware rapidly evolves to exploit the complexities of cloud environments, defending cloud-based resources demands proactive and adaptive security strategies. Organizations must move beyond legacy perimeter defenses and adopt layered controls tailored to cloud infrastructure if they are to counter such threats. To effectively safeguard cloud assets against modern ransomware campaigns, defenders can apply the following security best practices:

In a public statement, AWS said, "AWS services and infrastructure are operating as expected. AWS helps customers secure their cloud resources through a shared responsibility model. 1 We thoroughly investigate all reports of exposed keys and quickly take any necessary actions, such as applying quarantine policies 2 to minimize risk for affected customers without disrupting their IT environment. We encourage all customers to follow security, identity, and compliance best practices. Customers who suspect a credential disclosure should begin by consulting the steps outlined in our post. 3 For customers who want to disable AWS KMS Import Key Material, External Key Store, or S3’s SSE-C encryption entirely, we offer organization-level policies that can apply to all or a subset of accounts within the AWS Organization. 4 We also offer resource and identity-level policies that can be applied to specific resources and identities. For more information on preventing unintended encryption of Amazon S3 objects, please refer to our "Preventing unintended encryption of Amazon S3 objects" AWS Security Blog. 5 We encourage our customers to AWS Support 6 for any questions or concerns the security of their account.” 1 2 3 4 5 6