Ransomware in the Cloud: S3 and EBS Threat Models, Immutability, and Recovery

On-prem ransomware encrypts files on disk. In AWS, the attacker who has stolen an IAM principal with broad data-plane access does not need a payload at all. They have the same APIs your platform team uses, and the cloud gives them primitives that are far more efficient than a binary crawling a filesystem: server-side re-encryption with their own key material, bulk versioned deletes, snapshot deletion, and the scheduling of KMS key deletion as a slow-burn denial mechanism. The control that saves you is not antivirus. It is immutability that holds even when the calling principal is a legitimate, fully-authorized administrator.

This article walks the realistic kill chain across S3, EBS, and KMS, then maps each step to a control that an attacker with valid credentials cannot trivially undo. The recurring theme: separate the ability to write data from the ability to destroy its recoverability, and push the immutability boundary into a different account and a different trust domain.

The S3 threat model: re-encryption, not deletion

The headline S3 ransomware technique is SSE-C re-encryption. The attacker reads each object and writes it back with x-amz-server-side-encryption-customer-key set to a key they control. AWS stores the ciphertext but never the SSE-C key, so the object is now unreadable to you and every GET returns 400 unless you supply the attacker's key. No data leaves the bucket; the put looks like ordinary application traffic in CloudTrail data events. A quieter variant uses CopyObject onto itself with the attacker's own customer-managed CMK (SSE-KMS), then revokes your access via a key policy or grant change. Either way the bytes are intact and cryptographically out of reach.

The destructive variants are blunter: DeleteObjects in batches of 1000, PutBucketVersioning to suspend versioning so overwrites stop creating recoverable versions, and DeleteObjectVersion against specific version IDs to purge history. A lifecycle rule that expires noncurrent versions after one day is another way to quietly drain your recovery window. The defensive posture has three layers: keep old versions, make deletes require a second factor, and make the retention itself non-negotiable.

• Versioning ON so every overwrite and SSE-C re-encrypt leaves the prior plaintext version recoverable.
• MFA Delete on the bucket so suspending versioning or permanently deleting a version requires the root/owner MFA token, which a compromised IAM role does not hold.
• S3 Object Lock in COMPLIANCE mode so locked object versions cannot be deleted or shortened by anyone, including the account root, until the retention period elapses.
• A bucket policy that denies SSE-C entirely and forces writes through a specific SSE-KMS key, so an attacker cannot introduce key material you do not control.

Forcing your encryption and blocking the attacker's key

Object Lock protects versions you already have, but you also want to stop the re-encryption put from succeeding in the first place. A bucket policy can reject any request that carries SSE-C headers and require that every put use a single approved KMS key. Pair this with Block Public Access and a deny on the version-deletion and versioning-toggle calls for everyone except a narrow break-glass principal.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCustomerProvidedKeys",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::prod-data-vault/*",
      "Condition": {
        "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" }
      }
    },
    {
      "Sid": "RequireApprovedKmsKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::prod-data-vault/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:111122223333:key/APPROVED-CMK"
        }
      }
    },
    {
      "Sid": "DenyVersioningAndVersionDeletes",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:PutBucketVersioning",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration"
      ],
      "Resource": [
        "arn:aws:s3:::prod-data-vault",
        "arn:aws:s3:::prod-data-vault/*"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::111122223333:role/BreakGlassDataAdmin"
        }
      }
    }
  ]
}

Object Lock COMPLIANCE mode is irreversible by design: not even the account root can delete or shorten a retention on a locked version before it expires. Pilot it on a non-production bucket and right-size the retention period before you enable it widely, because the same property that defeats an attacker will also defeat you if you lock terabytes for ten years by mistake. GOVERNANCE mode is bypassable with s3:BypassGovernanceRetention and is therefore not a ransomware control on its own.

EBS, RDS, and the snapshot deletion problem

For block and database storage the ransomware play is deletion, not encryption. An attacker calls DeleteSnapshot across your EBS history, DeleteDBSnapshot and DeleteDBClusterSnapshot for RDS, deregisters AMIs, and where automated backups exist, deletes those too. Because snapshots live in the same account as the workload, a single compromised admin role can erase your entire recovery posture in minutes. Tag-based or resource-policy restrictions inside the same account help against a careless principal but not a determined one who can also retag resources.

The durable answer is AWS Backup with Vault Lock, plus copying recovery points to a separate, locked-down backup account. Vault Lock in compliance mode makes the vault write-once-read-many: once the lock is in its enforced state, the minimum and maximum retention are fixed and recovery points cannot be deleted before their retention expires, even by an administrator or AWS support. Copy backups cross-account so that compromise of the production account cannot reach the immutable copy, and ideally cross-Region to survive a Region-scoped blast radius.

• Centralize EBS and RDS backups in AWS Backup and apply a Vault Lock in compliance mode to the destination vault.
• Copy recovery points into a dedicated backup account whose admin credentials are isolated from production identity and SSO.
• Restrict the backup account's KMS keys with a separate key policy so the production blast radius cannot schedule their deletion.
• Test restore, not just backup: a recovery point you have never restored is a hypothesis, not a backup.

KMS as the denial weapon

Every server-side-encrypted object, snapshot, and volume ultimately depends on a KMS key. An attacker who cannot delete your locked data can still make it permanently undecryptable by attacking the key: kms:ScheduleKeyDeletion starts a pending-deletion window (7 to 30 days) after which the key material is gone and every dependent ciphertext is unrecoverable. kms:DisableKey and a malicious PutKeyPolicy that strips your access are faster, reversible-looking denials that still break decryption while in effect. Treat key-lifecycle actions as among the most dangerous calls in your account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyKeyDestructionExceptKeyAdmins",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey",
        "kms:PutKeyPolicy",
        "kms:DeleteAlias"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::111122223333:role/KmsKeyAdministrator"
        }
      }
    }
  ]
}

Enforce a guardrail like the above as a Service Control Policy at the organization or OU level so it cannot be edited from inside a compromised member account, and scope the carve-out to a single hardened key-admin role guarded by MFA and session policies. Multi-Region keys and a documented import-key strategy further reduce the chance that one ScheduleKeyDeletion call becomes an extinction event.

Detection: catch the pattern, not the single call

Ransomware in AWS shows up as a behavioral spike, not a signature. The signal is volume and shape: thousands of PutObject calls carrying SSE-C headers in minutes, a burst of DeleteObjects or DeleteObjectVersion, a PutBucketVersioning that suspends versioning, mass DeleteSnapshot and DeleteDBSnapshot, or any ScheduleKeyDeletion at all. Wire CloudTrail (including S3 data events) and GuardDuty findings into automated, near-real-time alerting, and treat the first key-deletion or versioning-suspension event as a page-the-on-call incident rather than a daily-digest line item.

• Alert on any kms:ScheduleKeyDeletion and any s3:PutBucketVersioning that sets status to Suspended.
• Threshold-alert on DeleteObjects, DeleteObjectVersion, DeleteSnapshot, and DeleteDBSnapshot rates well below an attacker's bulk pace.
• Flag PutObject calls that include SSE-C customer-algorithm headers, which legitimate pipelines forced onto your CMK should never send.
• Automate containment: on a high-confidence detection, revoke the offending session, attach a restrictive deny policy, and freeze the principal before triaging.

The architecture that survives a cloud ransomware event is not the one with the most detections. It is the one where, after an attacker has done their worst with a valid admin credential, your data still exists in a form they could not encrypt, delete, or render undecryptable. Versioning plus Object Lock for S3, AWS Backup with Vault Lock and cross-account copies for EBS and RDS, and an org-level deny on KMS key destruction together give you a recovery path that does not depend on the attacker's cooperation. Build that immutability boundary first, then layer detection on top to shorten the window.