SCN-006 / Compromised AKID + SSE-C + 7-day lifecycle delete / 2025

Codefinger 2025

Codefinger encrypts S3 objects in place using AWS native SSE-C (Server-Side Encryption with Customer Provided Keys) - AWS holds the key only during the operation and logs only an HMAC, so forensic recovery is impossible. A 7-day S3 Lifecycle policy triggers deletion if the ransom is not paid.

7 days

until lifecycle delete

HMAC only

in CloudTrail

AES-256

attacker-controlled key

No CVE

native AWS feature abuse

Codefinger · disclosed Jan 13 2025 →

Ransomware without ransomware - attackers used AWS's own encryption feature against the customer, with CloudTrail unable to recover the key needed to undo it.

Unrecoverable

Exposure

recovery technically impossible without attacker-held AES-256 key; per-victim ransom undisclosed

7 days

Time to detect

attacker sets S3 Lifecycle deletion deadline; CloudTrail logs HMAC only, not the key

1 SCP Deny

Fix complexity

Deny PutObject with x-amz-server-side-encryption-customer-algorithm for principals not using SSE-C

Ask your team this Friday

Do we have an SCP that denies PutObject requests with SSE-C customer-provided keys on buckets where we never use customer-managed keys?

→ Audit my environment

Select scenario

  
 TEXT   
 STEP 01 Codefinger acquires compromised AWS keys 
Source - leaked credentials, no CVE required
 1# Per Halcyon (halcyon.ai, Jan 13 2025) - Codefinger relies entirely on
2# pre-leaked AWS keys. No exploit, no zero-day, no AWS vulnerability.
3
4Sources observed in wild:
5  - Public GitHub commits containing .env / AWS_ACCESS_KEY_ID strings
6  - Infostealer logs (REDLINE, LUMMA, RACOON STEALER)
7  - Paste sites + Pastebin clones
8  - Old S3 buckets with leaked deployment artifacts
9
10Required permissions:
11  - s3:GetObject
12  - s3:PutObject
13  - (optional) s3:PutBucketLifecycleConfiguration 
Halcyon attribution · "This ransomware campaign does not exploit any AWS vulnerability." Defense is entirely about credential hygiene + bucket policy controls.
  1 / 6  

← back

Executive briefing · blast-audit

Codefinger 2025

Ransomware without ransomware - attackers used AWS's own encryption feature against the customer, with CloudTrail unable to recover the key needed to undo it.

Unrecoverable

Exposure

recovery technically impossible without attacker-held AES-256 key; per-victim ransom undisclosed

7 days

Time to detect

attacker sets S3 Lifecycle deletion deadline; CloudTrail logs HMAC only, not the key

1 SCP Deny

Fix complexity

Deny PutObject with x-amz-server-side-encryption-customer-algorithm for principals not using SSE-C

Ask your team this Friday

Do we have an SCP that denies PutObject requests with SSE-C customer-provided keys on buckets where we never use customer-managed keys?

Verified incident

First in-the-wild abuse of AWS SSE-C as ransomware primitive

Codefinger - financially motivated ransomware operator. Disclosed by Halcyon Threat Hunting Team on Jan 13, 2025. No public attribution to a nation-state or known criminal cluster.

How it happened

Codefinger uses pre-compromised AWS access keys (publicly exposed via GitHub, infostealer logs, paste sites) with s3:GetObject + s3:PutObject permissions. For each object in the victim bucket, Codefinger calls s3:CopyObject over the original key with x-amz-server-side-encryption-customer-algorithm: AES256 and a customer-generated key. AWS encrypts server-side and discards the key - only an HMAC of the key is captured in CloudTrail per AWS documentation. This means even AWS Support cannot recover the data. Codefinger then calls PutBucketLifecycleConfiguration to add an Expiration: Days=7 rule, arming the destruction timer that AWS itself executes. A plaintext ransom note (README_RANSOM.txt) is uploaded with a Bitcoin address and the promise to publish the SSE-C key after payment.

Outcome

Halcyon researchers observed the technique on two AWS-native-software-developer customers in December 2024 and disclosed publicly on Jan 13, 2025. AWS responded by recommending defenders (1) deny SSE-C usage via bucket policy condition keys, (2) alarm on PutBucketLifecycleConfiguration, (3) use cross-account replication to Object-Lock buckets, and (4) rotate any exposed access keys. The technique exploits no AWS vulnerability - it is a misuse of native AWS encryption features. Halcyon notes: "This is the first instance known of leveraging AWS's native secure encryption infrastructure via SSE-C in the wild."

Sources

Open on desktop for the full demo

Codefinger 2025

Codefinger 2025

Generate audit report