Ransomware crew abuses AWS native encryption, sets data-destruct timer for 7 days

A new ransomware crew dubbed Codefinger targets AWS S3 buckets and uses the cloud giant's own server-side encryption with customer provided keys (SSE-C) to lock up victims' data before demanding a ransom payment for the symmetric AES-256 keys required to decrypt it.

Halcyon threat hunters say they first spotted this criminal gang in December, and in recent weeks observed two such ransomware attacks against their customers, both of whom were AWS native software developers.

Codefinger breaks into victim orgs' cloud storage buckets using publicly exposed or compromised AWS keys with write and read permissions to execute "s3:GetObject" and "s3:PutObject" requests.

And while other security researchers have documented techniques for encrypting S3 buckets, "this is the first instance we know of leveraging AWS's native secure encryption infrastructure via SSE-C in the wild," Tim West, VP of services with the Halcyon RISE Team, told The Register. 

"Historically AWS Identity IAM keys are leaked and used for data theft but if this approach gains widespread adoption, it could represent a significant systemic risk to organizations relying on AWS S3 for the storage of critical data," he warned. 

After abusing the compromised keys, the miscreants call the "x-amz-server-side-encryption-customer-algorithm" header and use a locally stored AES-256 encryption key they generate to lock up the victims' files. 

Because AWS processes the key during encryption but does not store it, the victim cannot decrypt their data without the attacker-generated key.

Plus, in addition to encrypting the data, Codefinder marks the compromised files for deletion within seven days using the S3 Object Lifecycle Management API — the criminals themselves do not threaten to leak or sell the data, we're told.

"This is unique in that most ransomware operators and affiliate attackers do not engage in straight up data destruction as part of a double extortion scheme or to otherwise put pressure on the victim to pay the ransom demand," West said. "Data destruction represents an additional risk to targeted organizations." 

• Crooks stole AWS credentials from misconfigured sites then kept them in open S3 bucket
• 110K domains targeted in 'sophisticated' AWS cloud extortion campaign
• Security pros baited with fake Windows LDAP exploit traps
• Atos denies Space Bears' ransomware claims – with a 'but'

Codefinger also leaves a ransom note in each affected directory that includes the attacker's Bitcoin address and a client ID associated with the encrypted data. "The note warns that changes to account permissions or files will end negotiations," the Halcyon researchers said in a report about S3 bucket attacks shared with The Register.

While West declined to name or provide any additional details about the two Codefinger victims – including if they paid the ransom demands – he suggests that AWS customers restrict the use of SSE-C. 

"This can be achieved by leveraging the Condition element in IAM policies to prevent unauthorized applications of SSE-C on S3 buckets, ensuring that only approved data and users can utilize this feature," he explained.

Plus, it's important to monitor and regularly audit AWS keys, as these make very attractive targets for all types of criminals looking to break into companies' cloud environments and steal data.

"Permissions should be reviewed frequently to confirm they align with the principle of least privilege, while unused keys should be disabled, and active ones rotated regularly to minimize exposure," West said.

AWS weighs in

When asked about the ransomware infections, an AWS spokesperson told The Register that anytime the cloud giant is aware of exposed keys, it notifies the affected customers and "quickly takes any necessary actions, such as applying quarantine policies to minimize risks for customers without disrupting their IT environment."

The spokesperson also directed users to this post about what to do upon noticing unauthorized activity, and encouraged customers to follow best practices related to security, identify, and compliance – especially as they related to the cloud-security shared responsibility model.

"AWS provides a rich set of capabilities that eliminate the need to ever store credentials in source code or in configuration files," the spokesperson told us. "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."

These capabilities also include allowing compute nodes outside of AWS to make authenticated calls without long-term AWS credentials using the Roles Anywhere feature. Plus, developer workstations that use AWS Identity Center can obtain short-term credentials that are protected by multi-factor authentication 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," the spokesperson said. ®