Ransomware abuses Amazon AWS feature to encrypt S3 buckets
A new ransomware campaign encrypts Amazon S3 buckets using AWS’s Server-Side Encryption with Customer Provided Keys (SSE-C) known only to the threat actor, demanding ransoms to receive the decryption key.
The campaign was discovered by Halcyon, who reported that a threat actor named “Codefinger” had encrypted at least two victims. However, the operation could escalate or the tactic could be adopted by more threat actors soon.
Encrypting cloud storage
Amazon Simple Storage Service (S3) is a scalable, secure, and high-speed object storage service by Amazon Web Services (AWS), and S3 buckets are cloud storage containers for storing files, data backups, media, logs, etc.
SSE-C is an encryption option to secure S3 data at rest, allowing customers to use their own encryption key to encrypt and decrypt their data using the AES-256 algorithm. AWS does not store the key, and customers are responsible for generating the key, managing it, and securing it.
In the attacks by Codefinger, the threat actors used compromised AWS credentials to locate victim’s keys with ‘s3:GetObject’ and ‘s3:PutObject’ privileges, which allow these accounts to encrypt objects in S3 buckets through SSE-C.
The attacker then generates an encryption key locally to encrypt the target’s data.
Since AWS doesn’t store these encryption keys, data recovery without the attacker’s key is impossible, even if the victim reports unauthorized activity to Amazon.
“By utilizing AWS native services, they achieve encryption in a way that is both secure and unrecoverable without their cooperation,” explains Halcyon.
Next, the attacker sets a seven-day file deletion policy using the S3 Object Lifecycle Management API and drops ransom notes on all affected directories that instruct the victim to pay ransom on a given Bitcoin address in exchange for the custom AES-256 key.
The ransom also warns the victim that if they attempt to change account permissions or modify files on the bucket, the attackers will unilaterally terminate the negotiations, leaving the victim with no way to recover their data.
Defending against Codefinger
Halcyon reported its findings to Amazon, and the cloud services provider told them that they do their best to promptly notify customers who have had their keys exposed so they can take immediate action.
Amazon also encourages people to implement strict security protocols and follow these steps to quickly resolve unauthorized AWS account activity issues.
Halcyon also suggests that AWS customers set restrictive policies that prevent the use of SSE-C on their S3 buckets.
Concerning AWS keys, unused keys should be disabled, active ones should be rotated frequently, and account permissions should be kept at the minimum level required.
Amazon’s full statement in response to the Codefinger activity is:
“AWS helps customers secure their cloud resources through a shared responsibility model. Anytime AWS is aware of exposed keys, we notify the affected customers. We also thoroughly investigate all reports of exposed keys and quickly take any necessary actions, such as applying quarantine policies to minimize risks for customers without disrupting their IT environment.
We encourage all customers to follow security, identity, and compliance best practices. In the event a customer suspects they may have exposed their credentials, they can start by following the steps listed in this post. As always, customers can contact AWS Support with any questions or concerns about the security of their account.
AWS provides a rich set of capabilities that eliminate the need to ever store credentials in source code or in configuration files. 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. 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. Even secure access to non-AWS technologies can be protected using the AWS Secrets Manager service. The purpose of that service is to create, manage, retrieve, and automatically rotate non-AWS credentials like database usernames and passwords, non-AWS API keys, and other such secrets throughout their lifecycles.” – An Amazon spokesperson
