Full Report
On several occasions recently, hackers have gone after Amazon Web Services’ cloud storage products known as S3 buckets and used the company’s own encryption tools to lock customers out of their data.
Analysis Summary
# Incident Report: S3 Bucket Ransomware Encrypting Data via AWS SSE-C
## Executive Summary
A novel ransomware threat group, dubbed "Codefinger," has been observed encrypting data within Amazon S3 buckets by leveraging Amazon’s native Server-Side Encryption with Customer-Provided Keys (SSE-C) functionality. Attackers gain access via stolen AWS account credentials, steal the customer's encryption keys, and then lock the data, demanding ransom for key return with a seven-day file deletion deadline. This technique represents a sophisticated evolution in ransomware, making recovery extremely difficult without paying the ransom.
## Incident Details
- Discovery Date: Since the beginning of December (observations by Halcyon)
- Incident Date: Occurred multiple times since December (two incidents documented)
- Affected Organization: AWS customers, specifically AWS-native software developers (two initial victims identified)
- Sector: Technology/Cloud Services
- Geography: Global (affects AWS users worldwide)
## Timeline of Events
### Initial Access
- Date/Time: Unknown, but occurring since early December.
- Vector: Stolen AWS account credentials.
- Details: Attackers obtain valid AWS credentials for targeted customer accounts.
### Lateral Movement
- Details: Attackers likely gain access to the S3 bucket configuration and management plane using the compromised credentials to apply new encryption settings (SSE-C) or obtain/use existing keys.
### Data Exfiltration/Impact
- Details: Data within S3 buckets is encrypted using the victim's own customer-provided keys (SSE-C). Attackers create a ransomware scenario by holding the keys hostage, threatening to delete files within seven days.
### Detection & Response
- Details: Incidents were documented and reported by cybersecurity firm Halcyon. AWS was notified and stated they investigate reports of exposed keys, notify affected customers, and may apply quarantine policies to minimize risk.
## Attack Methodology
- Initial Access: Stolen AWS Account Credentials.
- Persistence: Not explicitly detailed, but maintaining access is likely achieved via the compromised AWS account.
- Privilege Escalation: Not explicitly detailed, but necessary access to manage S3 bucket encryption settings and associated keys is required.
- Defense Evasion: Utilizing a legitimate, native AWS feature (SSE-C) for encryption, making the resulting state appear "secure" and unrecoverable via standard means.
- Credential Access: Theft of AWS account credentials (specific method unknown).
- Discovery: Attackers likely scouted targets based on their AWS footprint and poor credential hygiene (e.g., storing credentials in source code/config files).
- Lateral Movement: Movement within the AWS management plane to access S3 configurations.
- Collection: Accessing and exfiltrating the encryption keys associated with the SSE-C configuration.
- Exfiltration: Not explicitly stated data was exfiltrated, but the primary impact is **encryption** of stored data.
- Impact: Data unavailability/encryption enforced via key destruction or withholding.
## Impact Assessment
- Financial: Ransom demands are implied; potential costs associated with recovery failure or downtime.
- Data Breach: Sensitive Organizational Data stored in S3 buckets, encrypted and rendered inaccessible.
- Operational: Significant operational disruption due to data unavailability; victims face a seven-day countdown to file deletion.
- Reputational: Potential reputational damage for victims relying on secure cloud storage.
## Indicators of Compromise
- Network indicators: None specified (specific domains/IPs not disclosed).
- File indicators: Introduction of ransom notes, potential changes to S3 bucket policies.
- Behavioral indicators: Unauthorized API calls to modify S3 bucket encryption settings to SSE-C using customer keys; potential unauthorized key access/retrieval actions.
## Response Actions
- Containment measures: AWS stated they notify affected customers upon discovery of leaked keys and may apply quarantine policies to minimize risk.
- Eradication steps: Not specified, but likely involves rotating all compromised AWS credentials and reviewing key management policies.
- Recovery actions: Affected customers must contact AWS support; recovery heavily reliant on the attackers returning the keys or finding alternative recovery paths (None known currently).
## Lessons Learned
- The ability of threat actors to weaponize legitimate, intended security features (like SSE-C) poses a unique and severe threat.
- Storing security credentials (including encryption keys) insecurely (e.g., in source code or configuration files) remains a critical vulnerability.
- This tactic represents a significant evolution in ransomware capabilities, as recovery without paying the ransom appears unfeasible.
## Recommendations
- Immediately review all AWS account credentials and enforce strict Multi-Factor Authentication (MFA).
- **Do not store customer-provided encryption keys (SSE-C keys) or AWS access credentials, secrets, or tokens within source code or configuration files.** Use robust secrets management tools (e.g., AWS Secrets Manager, HashiCorp Vault).
- Implement strict Identity and Access Management (IAM) policies to enforce the principle of least privilege, limiting which roles/users can modify S3 encryption settings or manage KMS/SSE-C keys.
- Monitor AWS CloudTrail logs closely for API calls related to S3 encryption configuration changes and key management activities from unusual sources.