Attackers are encrypting AWS S3 data without using ransomware
A ransomware gang dubbed Codefinger is encrypting data stored in target organizations’ AWS S3 buckets with AWS’s server-side encryption option with customer-provided keys (SSE-C), and asking for money to hand over the key they used.
They do not exfiltrate the data beforehand, but mark the encrypted files for deletion within seven days, thus adding more pressure on organizations to pay the ransom.
How does the attack unfold?
The threat actor leverages targets’ previous compromised (whether stolen or inadvertently leaked) AWS keys that have permissions to read and write S3 objects.
“The attacker initiates the encryption process by calling the x-amz-server-side-encryption-customer-algorithm header, utilizing an AES-256 encryption key they generate and store locally,” the Halcyon research team explained.
“AWS processes the key during the encryption operation but does not store it. Instead, only an HMAC (hash-based message authentication code) is logged in AWS CloudTrail. This HMAC is not sufficient to reconstruct the key or decrypt the data.”
Thus target organizations are effectively forced to pay up if they don’t have a backup of the encrypted data. And, during negotiation, they are prevented from making changes to account permissions because the attackers threaten to go silent and leave the victims hanging.
Avoid becoming a victim
Organizations storing their data in AWS S3 buckets should take this information to heart and move to make such an attack impossible before the attack method gains broader adoption, the team says. (They know of two organizations that have been hit in recent weeks.)
“Use the Condition element in IAM policies to prevent the application of SSE-C to S3 buckets. Policies can be configured to restrict this feature to authorized data and users,” they advised.
“Regularly review permissions for all AWS keys to ensure they have the minimum required access. Disable unused keys and rotate active ones frequently.”
They also advised enabling detailed logging for S3 operations, so unusual activity can be detected and acted upon quickly.
When AWS becomes aware of publicly exposed customer keys, it puts them in automatic “quarantine”, thus putting limits on what can be done with them (though even that is not enough to prevent potential damage, researchers have previously found).
“AWS provides a rich set of capabilities that eliminate the need to ever store credentials in source code or in configuration files,” Amazon’s cloud computing subsidiary commented Halcyon’s findings.
“IAM Roles enable applications to securely make signed API requests from EC2 instances, ECS or EKS containers, or Lambda functions using short-term credentials that are automatically deployed, frequently rotated, requiring zero customer management. Even compute nodes outside the AWS cloud can make authenticated calls without long-term AWS credentials using the Roles Anywhere feature,” they said.
“Developer workstations use Identity Center to obtain short-term credentials backed by their longer-term user identities protected by MFA tokens. All these technologies rely on the AWS Security Token Service (AWS STS) to issue temporary security credentials that can control access to their AWS resources without distributing or embedding long-term AWS security credentials within an application, whether in code or configuration files.”