A new ransomware campaign, dubbed Codefinger, has been targeting Amazon S3 users by exploiting compromised AWS credentials to encrypt data using Server-Side Encryption with Customer-Provided Keys (SSE-C). Attackers then demand ransom payments for the symmetric AES-256 keys required to decrypt the data. AWS has released recommendations to help users mitigate the risk of ransomware attacks on S3.
All key management for S3 server-side encryption with SSE-C is handled outside of AWS, with encryption key material provided alongside the object, ensuring the cloud provider never stores the key material. Following Halcyon’s report, AWS published an article clarifying how to prevent the unintended encryption of Amazon S3 objects. Steve de Vera, manager in the AWS Customer Incident Response Team, and Jennifer Paz, security engineer at AWS, explain:
Working with customers, our security teams detected an increase of data encryption events in S3 that used an encryption method known as SSE-C. While this is a feature used by many customers, we detected a pattern where a large number of S3 CopyObject operations using SSE-C began to overwrite objects, which has the effect of re-encrypting customer data with a new encryption key. Our analysis uncovered that this was being done by malicious actors who had obtained valid customer credentials, and were using them to re-encrypt objects.
Using publicly disclosed or compromised AWS keys, the threat actor identifies keys with permissions to execute s3:GetObject and s3:PutObject requests. The attacker can then initiate the encryption process by including the x-amz-server-side-encryption-customer-algorithm header, using an AES-256 encryption key that they generate and store locally. An S3 lifecycle rule is then applied to mark files for deletion within seven days, adding urgency to the ransom demand. The Halcyon RISE team explains why this poses a significant challenge:
Unlike traditional ransomware that encrypts files locally or in transit, this attack integrates directly with AWS’s secure encryption infrastructure. Once encrypted, recovery is impossible without the attacker’s key.
While these actions do not exploit a vulnerability in any AWS service, Reddit user Zenin highlights in a popular thread:
The biggest threat here is really that the heavy lifting of encrypting the data can be offloaded to S3 and far less likely to raise concerns while it processes. Most traditional ransomware attacks cause a lot of side effects as they run.
Furthermore, AWS CloudTrail logs only the HMAC of the encryption key, which is insufficient for recovery and forensic analysis. Corey Quinn, chief cloud economist at The Duckbill Group, comments:
“Encrypt Everything–no wait not like that” says AWS, in the wake of S3 objects being encrypted using native S3 functionality via ransomware. That’s frankly an ingenious attack vector. Evil. But ingenious.
AWS emphasizes the importance of using short-term credentials, implementing data recovery procedures, and preventing the use of SSE-C on S3 buckets when not necessary for the workload. Additionally, enabling detailed logging for S3 operations is a best practice for detecting unusual activity, such as bulk encryption or lifecycle policy changes. Paz and de Vera write:
If your applications don’t use SSE-C as an encryption method, you can block the use of SSE-C with a resource policy applied to an S3 bucket, or by a resource control policy (RCP) applied to an organization in AWS Organizations.
If a ransomware attack on S3 is suspected, both Halcyon and AWS recommend immediately restricting SSE-C usage, auditing AWS keys, enabling advanced logging, and promptly engaging AWS support as mitigation measures.
