{"id":1513,"date":"2025-01-14T04:42:35","date_gmt":"2025-01-14T04:42:35","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=1513"},"modified":"2025-01-14T04:42:35","modified_gmt":"2025-01-14T04:42:35","slug":"act-fast-to-blunt-a-new-ransomware-attack-on-aws-s3-buckets","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=1513","title":{"rendered":"Act fast to blunt a new ransomware attack on AWS S3 buckets"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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.<\/p>\n

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

\u201cUnlike traditional ransomware that encrypts files locally or in transit, this attack integrates directly with AWS\u2019s secure encryption infrastructure,\u201d the report notes. \u201cOnce encrypted, recovery is impossible without the attacker\u2019s key.\u201d<\/p>\n

The attacker allegedly behind the scheme has been dubbed Codefinger.<\/p>\n

An evolution in ransomware<\/h2>\n

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\u2019s account credentials, the report stresses. The key gives users permission to edit or access S3 buckets of data.<\/p>\n

\u201cWith 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,\u201d the report adds.<\/p>\n

The attacker leverages AWS\u2019s 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.<\/p>\n

To pressure victims, the encrypted files are marked for deletion within seven days.<\/p>\n

The report doesn\u2019t 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.<\/p>\n

Keys aren\u2019t stolen because of a vulnerability or exploit in AWS native services or products, Halcyon added.<\/p>\n

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

One difficulty for AWS customers: AWS CloudTrail logs only the hash-based\u00a0message authentication code (HMAC) of the encryption key used in each attack, which is insufficient for recovery or forensic analysis. \u00a0<\/p>\n

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.<\/p>\n

As for the attack identified by Halcyon, he noted that by default AWS encrypts data in S3 with keys managed by Amazon. \u201cThis 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.<\/p>\n

\u201cThe 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,\u201d Ullrich said.<\/p>\n

Advice to protect S3 buckets<\/h2>\n

There are, however, a few things AWS customers\u2019 IT administrators can do:<\/p>\n

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;<\/p>\n

enable detailed logging for S3 operations to detect unusual activity, such as bulk encryption or lifecycle policy changes;<\/p>\n

regularly review permissions for all AWS keys to ensure they have the minimum required access;<\/p>\n

disable unused keys and rotate active ones frequently.<\/p>\n

In a statement accompanying the Halcyon report, AWS referred customers to this web pag<\/a>e with information for administrators on how to deal with suspected unauthorized activity on their accounts.<\/p>\n

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\u2019s 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.<\/p>\n

Not a new tactic<\/h2>\n

The use of keys stolen from AWS customers by threat actors isn\u2019t a new tactic.<\/p>\n

In December, CSO reported<\/a> 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<\/p>\n

Last September, CSO reported<\/a> that attackers are using stolen AWS credentials for LMMjacking, which is hijacking large language models to run AI queries.<\/p>\n

In August, CSO reported<\/a> 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\u2019 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.<\/p>\n

\u201cDue to the security risks associated with authentication data stored inside .env files, organizations should follow security best practices\u00a0to never expose environment files publicly,\u201d Unit 42 said.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019 own encryption to make data virtually unrecoverable without paying the attackers for a […]<\/p>\n","protected":false},"author":0,"featured_media":1505,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1513","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1513"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1513"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1513\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/1505"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1513"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1513"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1513"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}