Codefinger (Jan 2025): Ransomware That Encrypts S3 Buckets With AWS's Own SSE-C

Retrospective: this article looks back at events from January 2025, written in 2026 with the benefit of hindsight.

On January 13, 2025, security firm Halcyon published research on a ransomware campaign by a group it called Codefinger that targeted Amazon S3 — without exploiting any vulnerability and without deploying malware. The attackers used valid AWS credentials and a legitimate S3 feature to lock victims out of their own data.

1. Stolen AWS keysCodefinger obtains valid AWS credentials with permission to read and write S3 objects.
2. SSE-C re-encryptionObjects are rewritten using server-side encryption with customer-provided keys that only the attacker holds.
3. Deletion pressureS3 lifecycle policies mark the files for deletion within seven days.
4. Ransom noteVictims are told to pay for the AES-256 key; AWS can't recover data encrypted with a key it never stored.
5. Platform responseIn April 2026, AWS disables SSE-C by default for new general purpose buckets and many existing ones.

The campaign showed what "cloud-native ransomware" looks like: a sequence of ordinary API calls, made with stolen keys, that antivirus can't see.

How it worked

1. Stolen credentials. Codefinger obtained AWS access keys belonging to victims — the kind of long-lived keys that leak through code repositories, configuration files and compromised machines. The keys had permission to read and write S3 objects.
2. Re-encryption with SSE-C. S3 supports server-side encryption with customer-provided keys (SSE-C). The caller supplies an encryption key with each request; S3 uses it to encrypt the object and keeps only a hash to verify future requests — never the key itself. The attackers rewrote victims' objects using SSE-C with keys only they held.
3. Deletion pressure. They set S3 lifecycle policies to delete the files within seven days.
4. Ransom note. Notes in affected locations demanded payment for the AES-256 key and warned victims not to change permissions.

Because AWS never stored the key, AWS couldn't decrypt the data. Without versioning or backups, recovery depended on paying.

AWS's response

AWS stated that the attacks didn't exploit an AWS vulnerability and encouraged customers to use short-term credentials, enable data recovery features and block features they didn't use. AWS later went further: after an advance notice in late 2025, starting April 6, 2026, Amazon S3 disabled SSE-C by default for all new general purpose buckets, and also disabled it for existing buckets in accounts that had no SSE-C encrypted objects. Write requests specifying SSE-C on those buckets are now rejected with an access-denied error unless the bucket owner explicitly re-enables SSE-C.

That default closes the specific technique for many accounts. It doesn't remove the underlying problem: stolen keys with write and delete permissions can still overwrite or destroy data in other ways.

Why it mattered

No malware means no malware alert. Endpoint protection can't see API calls made from an attacker's machine with your credentials.

Long-lived keys were the root cause. Every step required valid credentials. Organizations that had replaced IAM user keys with roles and short-lived sessions were far less exposed.

Recoverability decides the outcome. Versioning, Object Lock and independent backups turned a ransom demand into an inconvenience.

What to do now

1. Check SSE-C status. If your buckets predate April 2026 or your account uses SSE-C anywhere, confirm whether SSE-C is still allowed. If you don't need it, block it. On buckets where it's still enabled, a bucket policy can deny s3:PutObject requests that include the s3:x-amz-server-side-encryption-customer-algorithm condition key; an SCP can apply the same denial across your organization.
2. Enable versioning on critical buckets so overwritten objects can be restored, with lifecycle rules to control cost.
3. Use S3 Object Lock in governance or compliance mode for data that must not be altered or deleted during a retention period.
4. Back up to a separate account using AWS Backup, with Vault Lock so backups can't be deleted early — even by an administrator in the source account.
5. Restrict lifecycle and versioning changes. Limit s3:PutLifecycleConfiguration and s3:PutBucketVersioning to administrators and alert on changes.
6. Eliminate long-lived access keys. Use IAM Identity Center for people, roles for workloads and OIDC federation for CI/CD. Delete root access keys.
7. Reduce delete permissions. Few applications need s3:DeleteObject or the ability to delete object versions.

How to detect cloud-native ransomware

• SSE-C usage. With S3 data events enabled in CloudTrail for critical buckets, alert on PutObject or CopyObject requests that include SSE-C headers — especially if your organization never uses SSE-C.
• Mass rewrites. One identity rewriting or copying many objects in a short window.
• Lifecycle and versioning changes. PutBucketLifecycleConfiguration setting short expirations, or versioning being suspended.
• Deletion of object versions or backups.
• New objects resembling ransom notes.
• GuardDuty S3 Protection findings for anomalous access.

Common mistakes

• Not logging S3 data events for critical buckets, which leaves object-level activity invisible.
• Backups in the same account with the same credentials that attackers can reach.
• Assuming the new default protects old buckets. Check buckets created before April 2026 and accounts that already use SSE-C.
• Broad S3 permissions granted to applications "to be safe."

Other ways stolen keys can destroy S3 data

Blocking SSE-C closes one technique. Attackers with write and delete permissions have others:

• Deleting objects and versions directly, if the credentials allow s3:DeleteObject and s3:DeleteObjectVersion.
• Lifecycle rules that expire current and previous versions quickly.
• KMS key deletion. If data is encrypted with a customer managed KMS key and an attacker can schedule that key for deletion, the data becomes unreadable once the waiting period ends. Restrict kms:ScheduleKeyDeletion and alert on it.
• Replication or copying data to an attacker-controlled account before deleting it.

Object Lock, cross-account backups with Vault Lock, tight delete and key-administration permissions, and alerts on these actions protect against the whole category — not just one feature.

Questions for leadership

• Can we restore our most important S3 data if it's overwritten or deleted today?
• Are backups stored in a separate account that attackers with our production keys couldn't reach?
• How many long-lived AWS access keys do we still have?

Key takeaways

• Codefinger encrypted S3 data with SSE-C and stolen keys — no malware, no vulnerability.
• AWS disabled SSE-C by default for new buckets from April 2026, but check older buckets.
• Versioning, Object Lock and cross-account backups make S3 data recoverable.
• Removing long-lived keys removes the starting point for this entire class of attack.