Detecting S3 Ransomware via Cross-Account KMS Encryption

This threat involves the exploitation of S3 bucket permissions where an adversary performs a CopyObject operation on objects in a target bucket while applying server-side encryption using an AWS KMS key located in a different AWS account. By forcing the encryption of these objects with an external key that the bucket owner cannot access, the attacker effectively renders the data unusable, mirroring traditional ransomware tactics within a cloud-native environment. This technique is often a precursor to further destructive activity or extortion. Defenders must differentiate these malicious events from legitimate cross-account data governance or migration workflows, which may involve centralized encryption accounts. The activity is particularly dangerous if object versioning is disabled, as the original unencrypted or differently encrypted data may be overwritten during the copy process.

Attack Chain

1. Attacker performs reconnaissance to identify S3 buckets with overly permissive bucket policies or IAM roles with s3:PutObject permissions.
2. Attacker enumerates accessible objects using ListObjectsV2 or GetObject calls.
3. Attacker gains access to an external AWS account and creates or identifies a target-ready KMS key.
4. Attacker executes the CopyObject API call targeting the victim bucket, specifying the external KMS key via the x-amz-server-side-encryption-aws-kms-key-id request parameter.
5. S3 processes the CopyObject request, re-encrypting the data with the attacker-controlled KMS key.
6. Victim bucket owner attempts to access the object but fails due to lack of decrypt permissions on the external KMS key.
7. Attacker potentially proceeds to delete original object versions (if versioning is enabled) or demands ransom for the KMS key access.

Impact

The impact of this activity is the complete loss of data availability for the targeted S3 objects. If applied at scale, this technique can effectively neutralize entire buckets of data. If object versioning is disabled, the original data is overwritten and potentially unrecoverable, leading to significant operational disruption and data loss. This technique targets organizations using misconfigured cross-account IAM or S3 bucket policies.

Recommendation

1. Enable S3 data event logging in AWS CloudTrail to capture CopyObject operations for all critical buckets.
2. Implement monitoring to alert on CopyObject events where the kms_key_account_id does not match the bucket owner's cloud.account.id.
3. Audit IAM roles and S3 bucket policies for overly permissive s3:PutObject access and ensure no unnecessary external accounts have write access.
4. Enforce AWS Service Control Policies (SCPs) that restrict KMS usage to explicitly approved AWS accounts.
5. Enable S3 bucket versioning to ensure that objects can be restored if they are overwritten by malicious CopyObject operations.