Cloud Security Wire
AWS Azure GCP RSS
AWS Hardening Guide high

S3 Ransomware: How Attackers Encrypt Cloud Storage and How to Stop Them

Ransomware actors have adapted their playbook to cloud storage — using compromised IAM credentials to enable S3 Object Encryption and delete snapshots, holding data hostage without deploying a single binary. This guide covers the attack chain, detection signals, and the hardening controls that break it.

By Cloud Security Wire · ·
#s3#ransomware#iam#kms#object-lock#versioning#cloud-ransomware#aws#data-destruction
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

Traditional ransomware deploys an executable that encrypts files in place. Cloud-native ransomware doesn’t need an executable. When an attacker holds AWS IAM credentials with sufficient S3 permissions, they can encrypt every object in a bucket using a KMS key they control, delete all existing versions, disable lifecycle policies, and leave the bucket intact but inaccessible — all via authenticated API calls that are indistinguishable from normal operations without specific controls in place.

This pattern has been documented in real intrusions. It’s distinct from data theft ransomware (exfiltrate-then-extort) — here the attacker destroys your access to data you’re still paying to store. The leverage is real, and the attack is possible in any AWS environment where S3 versioning and Object Lock aren’t configured for critical data.

How the Attack Works

Step 1: Credential Compromise

The entry point is almost always a compromised IAM credential — a long-lived access key from a developer machine, a CI/CD secret committed to a public repository, an overly permissive instance profile role, or an SSRF vulnerability exploiting IMDSv1 on an EC2 instance.

The attacker needs a subset of S3 and KMS permissions. A role with s3:* and kms:CreateKey or kms:PutKeyPolicy is sufficient to execute the full attack chain.

Step 2: KMS Key Creation and Policy Manipulation

The attacker creates a new KMS customer-managed key (CMK) or modifies the key policy on an existing CMK to remove the account owner’s kms:Decrypt permission. This is the lock — once objects are encrypted with this key and the decryption permission is removed, the data is inaccessible regardless of S3 permissions.

# Attacker creates a CMK they control
aws kms create-key --description "backup-key" --region us-east-1

# Modifies key policy to exclude account owner from Decrypt
aws kms put-key-policy --key-id <key-id> --policy-name default --policy '
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::<attacker-account>:root"},
    "Action": "kms:*",
    "Resource": "*"
  }]
}'

Step 3: Object Re-Encryption

The attacker uses aws s3 cp or the S3 API’s CopyObject operation with --sse aws:kms --sse-kms-key-id to copy each object over itself using the attacker-controlled KMS key. This effectively re-encrypts all data at rest with a key the account owner cannot use.

For a large bucket, this takes time — and CloudTrail will log every CopyObject call. But if monitoring is not configured to alert on bulk KMS re-encryption events, the operation completes undetected.

Step 4: Versioning Deletion

If S3 versioning is enabled, previous (unencrypted) versions of objects still exist. The attacker deletes all versions:

# Delete all non-current versions
aws s3api list-object-versions --bucket <target-bucket> \
  --query 'Versions[?IsLatest==`false`].[Key,VersionId]' \
  --output text | while read key version; do
    aws s3api delete-object --bucket <target-bucket> --key "$key" --version-id "$version"
  done

If MFA Delete is not enabled on the bucket, this completes without additional authentication.

Step 5: Ransom Note

The attacker uploads a text file to the bucket — the ransom note — and leaves. The data exists in S3 but is encrypted with a key outside the account owner’s control.

Why This Is Particularly Dangerous

No malware is deployed. The entire operation runs through authenticated AWS API calls. There’s no binary to detect with endpoint security tools, no network connection to a C2, no anomalous process.

Backup snapshots are often co-located. Organizations that rely on S3 for backups — and many do — may find that their backup strategy is itself the thing being ransomed. If the same compromised credentials have access to the backup bucket, those objects are also at risk.

The blast radius scales with bucket size automatically. The attacker doesn’t need to enumerate files. CopyObject applied to all objects in a bucket with --recursive handles everything.

KMS key policy changes are logged but rarely alerted on. kms:PutKeyPolicy appears in CloudTrail but is not a default alert in most SIEM configurations. By the time anyone notices the KMS change, the re-encryption is complete.

Detection

CloudTrail Signals

The attack generates a cluster of CloudTrail events. Alert on any of the following in combination:

KMS key creation followed by rapid S3 CopyObject volume:

{
  "eventName": ["CreateKey", "PutKeyPolicy"],
  "eventSource": "kms.amazonaws.com"
}

Combined with:

{
  "eventName": "CopyObject",
  "eventSource": "s3.amazonaws.com"
}

A spike in CopyObject events on a single bucket within a short window — particularly when the x-amz-server-side-encryption-aws-kms-key-id header references a newly created CMK — is a strong indicator.

Bulk version deletion:

{
  "eventName": "DeleteObject",
  "eventSource": "s3.amazonaws.com",
  "requestParameters": {
    "versionId": "*"
  }
}

Volume-based alerting: more than N DeleteObject calls targeting versioned objects within a rolling time window.

KMS key policy modifications removing account principals:

Alert when PutKeyPolicy is called and the resulting policy no longer includes the account root or primary administrators in the kms:Decrypt action. This requires parsing the policy document from the CloudTrail event — doable in Lambda-based alerting pipelines.

GuardDuty Coverage

AWS GuardDuty detects some elements of this pattern:

  • S3/AnomalousBehavior.CopyObject — flags unusual CopyObject volume
  • KMS/AnomalousBehavior findings for unusual KMS API call patterns
  • Discovery/S3/MaliciousIPCaller — if the calls originate from known threat actor infrastructure

GuardDuty is necessary but not sufficient. It requires the threat intelligence match or anomaly threshold to trigger. Explicit CloudTrail alerting provides defense-in-depth.

Prevention: The Controls That Break the Attack Chain

1. S3 Object Lock

S3 Object Lock with Compliance mode is the most effective control. Objects protected by Object Lock cannot be overwritten or deleted — including by the root user — until the retention period expires. It must be enabled at bucket creation.

aws s3api create-bucket --bucket critical-data-bucket --region us-east-1
aws s3api put-object-lock-configuration \
  --bucket critical-data-bucket \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

Object Lock in Compliance mode cannot be disabled or shortened, even by the account owner. This makes the data immutable for the retention period — a re-encryption overwrite cannot delete the locked original.

Apply Object Lock to:

  • All S3 buckets used for backups
  • Buckets storing CloudTrail logs
  • Any bucket holding data that would be ransomware-worthy

2. MFA Delete

Enable MFA Delete on versioning-enabled buckets. Version deletions require providing a valid TOTP code. This prevents bulk version deletion even from compromised programmatic credentials.

# Requires root credentials
aws s3api put-bucket-versioning \
  --bucket critical-data-bucket \
  --versioning-configuration '{
    "Status": "Enabled",
    "MFADelete": "Enabled"
  }' \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

MFA Delete must be enabled by the root account and cannot be disabled without root MFA. This is an underused control that directly addresses the version deletion step.

3. KMS Key Policy Guardrails

Apply a Service Control Policy (SCP) that prevents removal of account-level KMS Decrypt permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyKMSKeyPolicyRemoval",
      "Effect": "Deny",
      "Action": "kms:PutKeyPolicy",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/security-admin"
        }
      }
    }
  ]
}

Alternatively, use KMS key grants rather than key policies for application access — grants are revocable but can be constrained to not allow policy modification.

4. Restrict kms:CreateKey

Most applications don’t need to create KMS keys. Add an SCP or IAM permission boundary restricting kms:CreateKey to a central key management role.

{
  "Effect": "Deny",
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalArn": "arn:aws:iam::*:role/key-management-role"
    }
  }
}

An attacker who cannot create a KMS key they control cannot execute the re-encryption step.

5. Credential Hygiene

The attack chain starts with a compromised credential. Eliminate long-lived access keys where possible:

  • Audit all IAM users with access keys using aws iam generate-credential-report
  • Enforce access key rotation or replacement with IAM roles for EC2, Lambda, ECS
  • Enable IMDSv2 on all EC2 instances to block SSRF-based credential theft
  • Scan repositories for committed secrets (GitHub secret scanning, truffleHog)

6. S3 Block Public Access and Bucket Policies

While not directly related to ransomware encryption, preventing public access reduces the attacker’s ability to use your storage for staging exfiltrated data or hosting ransom notes accessible externally.

aws s3api put-public-access-block \
  --bucket critical-data-bucket \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Incident Response Considerations

If you detect S3 ransomware in progress or after the fact:

  1. Rotate or deactivate the compromised credentials immediately. Stop the attack if still in progress.
  2. Inventory affected KMS keys. Identify which CMKs were created or modified. Check if any keys were created in other AWS regions.
  3. Check for exfiltration. CloudTrail GetObject calls before CopyObject calls indicate the attacker downloaded the data before encrypting it — this is a double-extortion position.
  4. Assess Object Lock and versioning status. If Object Lock was active on affected buckets, the original objects may be recoverable.
  5. Check cross-region replication. S3 Replication policies may have propagated encrypted objects to destination buckets. Verify destination bucket state.
  6. Engage AWS Support. In cases where a CMK was modified to exclude account access, AWS can assist with key policy recovery in some circumstances, though this is not guaranteed.

Summary

S3 ransomware is a credential exploitation attack, not a malware deployment. The controls that break it — Object Lock, MFA Delete, KMS key policy SCPs, and elimination of long-lived access keys — are straightforward to implement and have no material impact on legitimate operations. The cost of not implementing them is high: data held hostage via controls you built and are paying for.

← All Analysis Subscribe via RSS