In January 2025, the security firm Halcyon described a ransomware campaign that never used ransomware. A threat actor it calls Codefinger took AWS access keys that victims had leaked or had stolen, found keys allowed to read and write objects in Amazon S3, and re-encrypted the victims' data using AWS's own server-side encryption with customer-provided keys (SSE-C). The attacker generated the AES-256 key locally. AWS processes such a key but does not store it, so without the attacker's copy the data cannot be decrypted. Codefinger then set lifecycle rules to delete the files within seven days and left ransom notes demanding Bitcoin. Halcyon knew of at least two victims. AWS said it notifies customers whose keys are exposed and later added automatic mitigations for mass SSE-C overwrites.
Key takeaways
- Codefinger used compromised AWS keys with
s3:GetObjectands3:PutObjectpermissions, whether stolen or inadvertently leaked, according to Halcyon. - No AWS vulnerability was involved: the attacker used SSE-C, a legitimate feature, with a key only the attacker held.
- Files were marked for deletion within seven days, and victims were warned not to change permissions or files during negotiation.
- Halcyon reported at least two victims; AWS later confirmed it had seen large numbers of SSE-C overwrite operations and added automatic mitigations.
- The identity lesson: a long-lived access key with write access to storage is a ransom key waiting to be used, which is why AWS urges short-term credentials instead.
At a glance
| Organisations | At least two AWS customers, unnamed; Amazon Web Services (S3) |
|---|---|
| When | Attacks in the weeks before 13 January 2025, when Halcyon published its research; AWS update reported 22 January 2025 |
| Attacker | A threat actor Halcyon calls Codefinger |
| Entry point | Compromised or publicly leaked AWS access keys with permission to read and write S3 objects |
| Identities abused | Long-term AWS access keys belonging to victims |
| Impact | S3 data encrypted with keys only the attacker held, scheduled for deletion within seven days, and held for ransom |
| Category | NHI. Incident class: confirmed NHI breach (stolen cloud access keys used for extortion) |
What happened
Amazon S3 offers several ways to encrypt data at rest. One, SSE-C, lets customers supply their own AES-256 key with each request. AWS uses the key to encrypt the object but does not keep it. Codefinger turned that design into an extortion tool. According to BleepingComputer, "the threat actors used compromised AWS credentials to locate victim's keys with 's3:GetObject' and 's3:PutObject' privileges, which allow these accounts to encrypt objects in S3 buckets through SSE-C." Help Net Security described the keys as "previous compromised (whether stolen or inadvertently leaked)".
"The attacker initiates the encryption process by calling the x-amz-server-side-encryption-customer-algorithm header, utilizing an AES-256 encryption key they generate and store locally," Halcyon's researchers explained, as quoted by Help Net Security. "AWS processes the key during the encryption operation but does not store it. Instead, only an HMAC (hash-based message authentication code) is logged in AWS CloudTrail. This HMAC is not sufficient to reconstruct the key or decrypt the data." The attacker then used the S3 lifecycle API to schedule deletion within seven days and left ransom notes with a Bitcoin address, warning that changing account permissions or files would end negotiations. Halcyon said it knew of two organisations hit in recent weeks.
Amazon responded that "anytime AWS is aware of exposed keys, we notify the affected customers" and applies quarantine policies. It pointed to IAM roles, Roles Anywhere and Identity Center, which issue short-term credentials "without distributing or embedding long-term AWS security credentials within an application." On 22 January, Help Net Security added that AWS's Customer Incident Response Team had "detected a pattern where a large number of S3 CopyObject operations using SSE-C began to overwrite objects" and had "implemented automatic mitigations that will help to prevent this type of unauthorized activity in many cases," while noting that attacks with valid credentials may still get through.
Timeline
| Date | Event |
|---|---|
| January 2025 | Codefinger encrypts S3 data at at least two organisations using compromised AWS keys, according to Halcyon. |
| 13 January 2025 | Halcyon publishes its research; BleepingComputer and Help Net Security report it with Amazon's response. |
| 22 January 2025 | Help Net Security reports AWS's automatic mitigations for mass SSE-C overwrites. |
How it happened: the identity attack path
- Keys leaked or stolen. Victims' long-term AWS access keys were exposed or compromised.
- Permissions checked. The attacker identified keys allowed to read and write S3 objects.
- Data re-encrypted. Objects were rewritten with SSE-C using a key generated and kept by the attacker.
- Deletion scheduled. Lifecycle rules marked the files for deletion within seven days.
- Ransom demanded. Notes demanded Bitcoin for the key and threatened to end talks if permissions were changed.
Impact
- Victims: at least two organisations had S3 data encrypted and held for ransom.
- Recovery: impossible without the attacker's key or a separate backup, because AWS does not store SSE-C keys.
- Platform response: AWS added automatic mitigations for mass SSE-C overwrite patterns.
What this means for NHI governance
This attack needed only one thing from the victim: a long-lived access key with permission to write to S3. Everything else was standard AWS functionality. Keys like that are created for applications, scripts and CI pipelines, often with broad S3 permissions because narrowing them is effort, and they tend to live for years in code, configuration or developer machines until one leaks.
The strongest fix is the one AWS itself recommends: stop using long-term keys where temporary credentials are possible, through IAM roles, workload identity federation and Identity Center. Where keys remain, they should be scoped to specific buckets and actions, rotated, monitored, and blocked from using SSE-C unless an application needs it. See our Cloud Workload Identity Guide and Cloud PAM and CIEM Guide.
Recommendations
- Replace long-term access keys with temporary credentials. Use IAM roles, Roles Anywhere and Identity Center. See the Cloud Workload Identity Guide.
- Block SSE-C where it is not needed. Use the Condition element in IAM or bucket policies to deny SSE-C requests.
- Scope S3 permissions tightly. Give each key only the buckets and actions it needs. See the Cloud PAM and CIEM Guide.
- Find and disable leaked or unused keys. Scan code and configuration for keys, disable unused ones and rotate active ones. See the Leaked Credential Response Playbook.
- Keep independent backups and monitor S3 activity. Enable versioning, protected backups and detailed S3 logging, and alert on bulk overwrites and lifecycle changes.
Frequently asked questions
What is the Codefinger ransomware attack?
Codefinger used compromised AWS keys to re-encrypt victims' S3 data with AWS's SSE-C feature and a key only the attacker held, then demanded a ransom and scheduled the files for deletion within seven days.
Did Codefinger exploit an AWS vulnerability?
No. The attack used legitimate AWS features with the victims' own compromised credentials. AWS later added automatic mitigations for mass SSE-C overwrite activity.
How can organisations prevent SSE-C ransom attacks?
Use temporary credentials instead of long-term keys, block SSE-C in IAM and bucket policies unless needed, scope S3 permissions narrowly, keep independent backups and monitor for bulk overwrites.
Related NHI Mgmt Group resources
230 Million AWS Environments Extortion Campaign · Hacked AWS Accounts and Crypto Mining · Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · Leaked Credential Response Playbook
How NHI Mgmt Group can help
Long-lived cloud keys are still behind many of the breaches in our database. We help teams find them, replace them with temporary credentials and scope what remains. See our NHI and AI agent security training.