Act fast to blunt a new ransomware attack on AWS S3 buckets

by CybrGPT
0 comment

A threat actor is leveraging AWS’s own encryption against victim firms with no way out except paying for decryption keys, says report.

CISOs are being warned to make sure employees take extra steps to protect their AWS access keys after word that a threat actor is using stolen login passwords for ransomware attacks.

The target is Amazon S3 buckets and the attack uses AWS’ own encryption to make data virtually unrecoverable without paying the attackers for a decryption key, said a report by researchers at Halcyon Tech.

“Unlike traditional ransomware that encrypts files locally or in transit, this attack integrates directly with AWS’s secure encryption infrastructure,” the report notes. “Once encrypted, recovery is impossible without the attacker’s key.”

The attacker allegedly behind the scheme has been dubbed Codefinger.

An evolution in ransomware

Infosec pros should note this attack does not require the exploitation of any AWS vulnerability, but instead relies on the threat actor first obtaining an AWS customer’s account credentials, the report stresses. The key gives users permission to edit or access S3 buckets of data.

“With no known method to recover the data without paying the ransom, this tactic represents a significant evolution in ransomware capabilities. If this method becomes widespread, it could pose a systemic threat to organizations using Amazon S3 for critical data storage,” the report adds.

The attacker leverages AWS’s Server-Side Encryption with Customer Provided Keys (SSE-C) to encrypt data, demanding ransom payments if the victim firm wants the symmetric AES-256 keys required for decryption. While SSE-C has been available since 2014, say the researchers, this appears to be a novel use of the feature by ransomware operators.

To pressure victims, the encrypted files are marked for deletion within seven days.

The report doesn’t detail how the stolen AWS keys are obtained. But in response to emailed questions, Halcyon said keys can be exposed in a variety of ways, including through compromised IT networks and phishing. Keys often get leaked publicly by developers or employees who embed them in code repos such as GitHub or GitLab.

Keys aren’t stolen because of a vulnerability or exploit in AWS native services or products, Halcyon added.

Halcyon has identified two victims in recent weeks, both AWS native software developers, neither of which were Halcyon customers at time of the attacks.

One difficulty for AWS customers: AWS CloudTrail logs only the hash-based message authentication code (HMAC) of the encryption key used in each attack, which is insufficient for recovery or forensic analysis.  

Johannes Ullrich, dean of research at the SANS Institute, said that there have been similar schemes with attackers using Bitlocker and other full disk encryption systems to lock legitimate users out of their data.

As for the attack identified by Halcyon, he noted that by default AWS encrypts data in S3 with keys managed by Amazon. “This encryption is more or less invisible to the user but does not protect the data from Amazon itself as it manages the keys. To better protect the data, Amazon offers users to upload their own keys (SSE-C keys). These keys are now managed by the AWS customer, and by design, Amazon has no way to recover these keys if the customer loses them. In this case, the attacker uploads the encryption keys, and the AWS customer cannot recover the data. This is a feature, not a bug.

“The real problem is that the AWS customer leaked access credentials, allowing the attacker to upload the malicious keys. The attacker could also delete the data at this point, but encrypting it allows for the ransomware scheme,” Ullrich said.

Advice to protect S3 buckets

There are, however, a few things AWS customers’ IT administrators can do:

  • use the Condition element in IAM (identity and access management) policies to prevent the application of SSE-C to S3 buckets. Policies can be configured to restrict this feature to only authorized data and users;
  • enable detailed logging for S3 operations to detect unusual activity, such as bulk encryption or lifecycle policy changes;
  • regularly review permissions for all AWS keys to ensure they have the minimum required access;
  • disable unused keys and rotate active ones frequently.

In a statement accompanying the Halcyon report, AWS referred customers to this web page with information for administrators on how to deal with suspected unauthorized activity on their accounts.

It also notes that AWS Security Token Service (AWS STS) can be used to issue temporary security credentials that can control access to a customer’s AWS resources without distributing or embedding long-term AWS security credentials within an application, whether in code or in configuration files. Secure access to non-AWS technologies can be protected using the AWS Secrets Manager service, AWS adds. That service creates, manages, retrieves and automatically rotates non-AWS credentials like database usernames and passwords, non-AWS API keys, and other such secrets throughout their lifecycles.

Not a new tactic

The use of keys stolen from AWS customers by threat actors isn’t a new tactic.

In December, CSO reported that thousands of AWS customers had been compromised by exploits of vulnerabilities and misconfigurations of public websites which gave up database credentials and AWS keys

Last September, CSO reported that attackers are using stolen AWS credentials for LMMjacking, which is hijacking large language models to run AI queries.

In August, CSO reported that attackers were collecting AWS keys and access tokens to various cloud services to extort data from victim firms. That report, from research by Palo Alto Networks’ Unit 42 threat analysts, noted that crooks were getting AWS access keys from publicly available environment files in unsecured web applications. Environment files allow users to define configuration variables used within applications and platforms. These files often contain secrets such as hard-coded cloud provider access keys, software-as-a-service (SaaS) API keys, and database login information which is then used by the threat actor for initial access.

“Due to the security risks associated with authentication data stored inside .env files, organizations should follow security best practices to never expose environment files publicly,” Unit 42 said.

Source link

You may also like

Leave a Comment

Stay informed with the latest in cybersecurity news. Explore updates on malware, ransomware, data breaches, and online threats. Your trusted source for digital safety and cyber defense insights.

BuyBitcoinFiveMinute

Subscribe my Newsletter for new blog posts, tips & new photos. Let’s stay updated!

© 2025 cybrgpt.com – All rights reserved.