Ransomware
Breaking Down S3 Ransomware: Variants, Attack Paths and Trend Vision One™ Defences
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.
Save to Folio
Key takeaways
- Ransomware is shifting from traditional systems to cloud environments, redefining its impact on cloud-native data.
- Cloud storage services like Amazon Simple Storage Service (S3) remain attractive targets due to potential customer misconfigurations on bucket settings and access controls.
- This blog entry explores five S3 ransomware variants, combining both observed attack techniques and potential future vectors.
- Trend Vision One™ detections provide visibility into AWS CloudTrail events to detect and respond to active ransomware activity.
Old threat, new terrain: ransomware’s move to the cloudRansomware 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 organisations 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.
Potential cloud ransomware targets
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
Compute snapshots – point-in-time copies of virtual machine disks or volumes – like Amazon Elastic Block Store (EBS) snapshots could be targeted, as organisations 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
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.
Cloud databases
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, compromises user data, and brings about 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 containerised 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.
Server-side encryptions in Amazon S3
Amazon S3 offers several options for encrypting data at rest:
- SSE-S3: AWS handles all encryption key management on your behalf.
- SSE-KMS: Encryption keys are managed using AWS Key Management Service (KMS), providing enhanced control through customisable key policies and access permissions.
- SSE-C: Customers supply their own encryption keys, granting them full control over key management. This approach is typically chosen to meet strict compliance or security requirements but comes with added complexity, such as the need to securely store and manage keys. Notably, AWS does not retain SSE-C keys; instead, it logs a key’s HMAC (Hash-based Message Authentication Code) to verify access requests.
S3 ransomware blueprint: Understanding the attacker’s mindset
Target selection – Finding the ideal S3 bucket
Before executing the attack, the adversary evaluates potential S3 buckets based on the following criteria:
- No versioning enabled - Without versioning, there’s no way to recover previous versions of overwritten files, making encryption irreversible.
- No object lock - Buckets without object lock settings allow data to be overwritten or deleted freely, which is essential for successful ransomware execution.
- No MFA Delete enabled - If MFA Delete is disabled, attackers can permanently delete objects or bucket version history without requiring multi-factor authentication - simplifying cleanup or further damage.
- Improper write permissions - The attacker needs s3:PutObject or s3:PutObjectAcl access to re-upload or overwrite files, and often kms:Encrypt if SSE-KMS is used. These permissions might be exposed via:
- Overly broad customer-defined IAM policies (* on resources or actions)
- Misconfigured cross-account roles
- Leaked or compromised credentials
- Contains high-value data - Buckets storing critical assets – including backups, configuration files, database dumps, or proprietary code – are prime targets. Clues can come from file names (backup.sql, prod.env) or bucket names (company-archive, db-backup).
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:
- Make or use encryption keys that are inaccessible to target users. The attacker uses encryption keys technically inaccessible to the target AWS users to encrypt S3 objects. This prevents the victim, including the root user, from decrypting any S3 files.
- Make or use encryption keys that are inaccessible to AWS. The attacker uses encryption keys technically inaccessible to the AWS as well. This way, the victim cannot decrypt the data even with AWS support, as the key no longer exists within any AWS-managed scope or SLA.
- Trigger a ransom demand. With the victim locked out, the attacker may demand payment in exchange for re-enabling or sharing the decryption key or making data accessible again to target users, in the form of a note.
S3 ransomware: Past breaches and exploits, future playbooks
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 is unlikely to occur in the real world because it takes a minimum of seven days to delete the key, and there is a 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:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySSECEncryptionForNewWrites",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Principal": "*",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
]
}
Customers can prevent this by adding this policy to their RCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
Customers can also add the following to their bucket policies:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<your-bucket-name>/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
Customers who do not use AWS Organisations 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):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySSECEncryptionForNewWrites",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your_bucket_arn_here/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
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 organisations 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:
openssl rand -out mycustomkeymaterial.bin 32 <Created new key>
openssl pkeyutl \ <Wrapped the new key with downloaded wrapping key>
-encrypt \
-in mycustomkeymaterial.bin \
-out MyCustomKeyNowEncrypted.bin \
-inkey WrappingPublicKey.bin \
-keyform DER \
-pubin \
-pkeyopt rsa_padding_mode:oaep \
-pkeyopt rsa_oaep_md:sha256 \
-pkeyopt rsa_mgf1_md:sha256 \
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 the 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:
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
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.
[[external_key_stores]]
uri_path_prefix = "/[CENSORED]/secure"
# Access key ID must have between 20 and 30 characters. Valid characters are uppercase A-Z and 2-7
sigv4_access_key_id = “[CENSORED]"
# Secret access key must have between 43 and 64 characters. Valid characters are a-z, A-Z, 0-9, /, +, and =
sigv4_secret_access_key = "[CENSORED]"
xks_key_id_set = ["foo"]
Note that if a user is using a region other than us-east-1, the file must also be updated near the top here:
# This is a sample xks-proxy configuration file of using SoftHSMv2 with pkcs11-logger disabled in a Docker environment.
[server]
region = "eu-west-1"
3. Builds and runs the XKS proxy on attacker’s environment.
The repository includes a Docker file to build the proxy:
docker build -t xks-proxy:latest .
docker run --rm --name xks-proxy -d -p 80:80 xks-proxy:latest
They verify that the proxy is running:
curl http://localhost/ping
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 http://localhost:80
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 previous 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:
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
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 the 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.
Proactive security with Trend Vision One™
Trend Vision One™ is the only AI-powered enterprise cybersecurity platform that centralises cyber risk exposure management and security operations, delivering robust layered protection across on-premises, hybrid, and multi-cloud environments.
CloudTrail-based workbenches for S3 ransomware activity
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 behaviours, identify suspicious encryption patterns, and surface high-fidelity workbench detections that map to different ransomware variants.
Below are categorised 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 organisations to act quickly against distinct attack methods:
AWS Possible S3 Ransomware Activity Detected (Variants 1, 4, 5)
Detected possible ransomware activity on an 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 unauthorised, 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 behaviour 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, unauthorised 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, unauthorised 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 authorised 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 unauthorised 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 unauthorised 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 an 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 their 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 posture checks S3 ransomware activity
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:
- S3-013: Ensures MFA Delete is enabled to prevent unauthorised deletion
- S3-023: Verifies Object Lock configuration to prevent overwrites
- S3-025: Detects use of customer-provided encryption keys (SSE-C), a known ransomware vector
- S3-026: Ensures S3 Block Public Access is enabled
- S3-015: Detect suspicious cross-account access patterns
These rules support real-time posture monitoring, providing immediate alerts when configurations change. For the complete rule catalogue and detailed remediation guidance, refer to Cloud Risk Management Knowledge Base in your Trend Vision One console.
Proactive strategies to defend S3 from ransomware
As ransomware rapidly evolves to exploit the complexities of cloud environments, defending cloud-based resources demands proactive and adaptive security strategies. Organisations must move beyond legacy perimeter defences 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:
- Enforce least-privilege access. Limit s3:PutObject, s3:DeleteObject, and KMS operations to specific roles. Use IAM conditions, multi-factor authentication (MFA), and separation of duties to block unauthorised activity.
- Harden KMS governance. Restrict cross-account KMS grants, disable unused imported key material or XKS connections, and separate key administrators from data owners.
- Enable Object Immutability. Turn on S3 Object Lock and versioning to prevent overwrites or encryption of existing data and ensure fast recovery.
- Enforce MFA Delete on critical buckets. Enable MFA Delete to require a second authentication factor before object version deletions or versioning changes, a strong final safeguard against ransomware-triggered wipes.
- Block public and untrusted access. Enforce S3 Block Public Access at both account and bucket level. Route access through VPC endpoints or private access points only.
- Avoid weak encryption practices. Restrict or disable SSE-C usage; preferably, use SSE-KMS with monitored customer-managed keys. Regularly review any external or imported key material.
- Detect anomalous activity early with unified monitoring. Continuously monitor CloudTrail, S3 Data Events, and KMS logs for unusual encryption, cross-account activity, or bulk write/delete patterns.
- Isolate and protect backups. Maintain cross-account replication to a separate AWS account with its own CMKs and deletion protections to ensure clean recovery options.
- Validate recovery regularly. Periodically test restoration from versioned objects or replicas, and audit IAM/KMS policies for privilege creep or misconfigurations.
- Automate response actions. Configure automated alerts and response playbooks to revoke compromised credentials, disable suspicious KMS keys, and quarantine affected resources quickly.