The ransomware group Codefinger is using compromised AWS keys to encrypt S3 bucket data using SSE-C, Halcyon researchers warn.
The ransomware group Codefinger has been spotted using compromised AWS keys to encrypt data in S3 buckets.
The threat actor used AWS’s Server-Side Encryption with Customer Provided Keys (SSE-C) for encryption, then demanded the payment of a ransom to the victim to recover the data using the attackers’ symmetric AES-256 keys required to decrypt data.
Halcyon researchers pointed out that this ransomware campaign does not exploit any AWS vulnerability.
“Threat actor dubbed Codefinger uses compromised AWS keys to encrypt S3 bucket data via SSE-C, leveraging AWS’s secure encryption infrastructure in a way that prevents recovery without their generated key.” reads the report published by Halcyon. “AWS CloudTrail logs only an HMAC of the encryption key, which is insufficient for recovery or forensic analysis.”
The researchers highlighted that the encrypted files are marked for deletion within seven days to pressure victims.
Halcyon reported that at least two organizations were victims of this campaign, the company also urges for immediate action by organizations utilizing Amazon S3.
Attackers rely on publicly disclosed or compromised AWS keys to locate keys with permissions to execute s3:GetObject and s3:PutObject requests. Then they start the encryption by
The threat actor looks for keys with permissions to write and read S3 objects (s3:GetObject and s3:PutObject requests), and then launches the encryption process by calling the x-amz-server-side-encryption-customer-algorithm header. The ransomware group Codefinger utilizes an AES-256 encryption key they generate and store locally.
“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.” Halcyon continues.
The attackers drop a ransom note in each directory, it provides instructions to pay the ransom in Bitcoin. The ransomware group’s note warns that any changes to account permissions or files will end negotiations.
The Codefinger ransomware campaign targeting AWS SSE-C encryption is highly dangerous due to irreversible data loss without the attacker’s key, limited forensic evidence in AWS CloudTrail logs, and the potential to significantly disrupt critical data storage on Amazon S3
Organizations are recommended to protect themselves by hardening AWS environments: restrict SSE-C usage with IAM policies, monitor and audit AWS keys, enable detailed S3 logging, and collaborate with AWS support.
Halcyon reported their findings to AWS that replied with the following statement and guidance:
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.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, Codefinger ransomware)
