Huge ransomware campaign targets AWS S3 storage: attackers have thousands of keys

A massive database of over 1,200 unique Amazon Web Services (AWS) access keys has been amassed and exploited in a ransomware campaign. Administrators of exposed AWS S3 buckets are finding their files encrypted except for a ransom note demanding payment in bitcoin.

Security researchers discovered a publicly accessible server containing over 158 million AWS secret key records. Most of the keys were duplicate entries replicated across different regional endpoints and configurations.

However, further investigation unveiled a malicious campaign involving scraping and otherwise collecting AWS keys, encrypting the storage buckets, and demanding ransom payments.

The researchers narrowed the list down to 1,229 unique AWS key pairs containing an Access Key ID and corresponding Secret Access Key. Many of the key pairs were already rotated. However, the active and functional pairs have led to encrypted S3 buckets containing ransom notes.

An unknown threat actor is abusing native AWS’s server-side encryption to remain hidden.

“This is a rare and potentially unprecedented case of a coordinated extortion campaign leveraging leaked AWS credentials to apply server-side encryption (SSE-C) on data stored in S3 buckets, without owner interaction or realization,” Bob Diachenko, a cybersecurity researcher and owner of SecurityDiscovery.com said.

Key Takeaways

• 158M+ leaked AWS key records were found, pointing to 1,229 unique credentials. Working AWS keys allowed S3 bucket listing and retrieval of ransom demands.
• Ransom notes indicate files were encrypted using Server Side Encryption with Customer Provided Keys (SSE-C).
• The extortion amount was 0.3 BTC (~$25,000) per victim.

Some victims are still unaware

This malicious campaign has no clear attribution and is heavily automated. The threat actor leaves ransom notes in a file named warning.txt. Each encrypted S3 bucket seems to have its own warning with a unique Bitcoin (BTC) address. The hackers leave the email address awsdecrypt[@]techie.com for contact.

The attackers are using AWS against their own customers – they abuse AWS Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt S3 bucket data. The Halcyon RISE Team has previously detailed this technique.

This means that the attackers generate their own encryption keys (AES-256), which are then used to lock the data, making recovery impossible without the key.

This attack pattern allows for “silent compromise,” with no alerts or reports issued to the victims when the breach occurs and no file deletion logs. The threat actor leaves the bucket structure intact. It also seems that the hackers don’t even bother to exfiltrate data for double extortion.

Previously, attackers have been observed setting S3 lifecycle policies to delete the encrypted data within 7 days, further pressuring victims to pay.

Alarmingly, in several instances, the affected AWS environments continue to operate, suggesting that the victims may still be unaware of the breach.

“Some victims may still be unaware their buckets are encrypted, especially if the affected files are infrequently accessed, or the buckets are used for backup. Some exposed backups are empty and might be newly created, putting future projects at risk,” Diachenko said.

The researchers also noted that attackers, in several instances, warned victims not to change credentials and offered “proof of decryption” by allowing test file restoration.

“This incident marks a significant escalation in cloud ransomware tactics. Its simplicity makes it particularly dangerous: attackers only need stolen keys – no fancy exploits,” Diachenko added.

They warn that it is virtually impossible to brute-force or otherwise decrypt the data locked with strong AWS-native encryption.

How did the hackers collect the AWS keys?

The exact method used by the threat actors to amass the vast collection of AWS keys remains unconfirmed. However, Cybernews researchers have identified several most plausible hypotheses:

1. AWS keys leaking from public code repositories: secret credentials are often mistakenly committed to GitHub, Bitbucket, and similar platforms. Attackers then use tools like TruffleHog, Gitleaks, and others to scrape these repositories for secrets.
2. Insecure CI/CD (Continuous Integration and Continuous Deployment) tools: Jenkins or GitLab runners often store AWS keys. These keys might have been exposed due to misconfigured deployments or weak credentials.
3. Misconfigured .env and config.php or JSON config files in Web Apps: these files are supposed to be secret, but due to misconfigurations, they might leak credentials.
4. Leaks and breaches: compromised developer tools, cloud dashboards, or password managers could be a source. Hackers can harvest credentials from illicit marketplaces.
5. Old or forgotten Identity and Access Management (IAM) users: rarely rotated and long-lived credentials for inactive IAM users are too common in many cloud environments. They are prime targets for silent attacks.

Attackers can extract credentials in many other ways. Previous Cybernews research has found that iOS apps have an average of five hardcoded secrets, which can lead to leaks and data breaches.

Protect your cloud storage buckets

AWS credentials are supposed to be kept secret. Cybernews researchers recommend further hardening AWS environments using the following methods:

• Audit all IAM credentials immediately. Disable unused keys and rotate active ones.
• Implement AWS Config and GuardDuty to detect suspicious access patterns.
• Use automated tools to scan public repos for leaked secrets.
• Enforce short-lived tokens and remove hardcoded credentials from apps.
• Apply least privilege principles for all IAM roles.
• Monitor for new or unknown files like warning.txt in buckets.
• Configure policies to restrict SSE-C usage and enable detailed logging to detect unusual activity.

Cybernews disclosed the exposed instance to AWS. We also reached out for additional comments and will include their response.

AWS encourages all customers to follow security, identity, and compliance best practices. If a customer suspects a compromise, they can start by following the steps listed in this post or contact AWS Support.