Codefinger Ransomware: Encrypting S3 Buckets With AWS's Own Keys
Codefinger surfaced in January 2025, when researchers at Halcyon documented a ransomware campaign that never touches a laptop or a server. It targets Amazon S3 buckets, and it does the encryption with a feature AWS itself provides: server-side encryption with customer-provided keys (SSE-C). There is no malware binary to detect and no file-encrypting process to kill. The attacker needs only a valid AWS key and two ordinary S3 permissions.
Halcyon identified two victims at the time of reporting. The numbers are small, but the technique is cheap, quiet and hard to undo, which is why it deserves attention from anyone who stores data in S3.
How the Attack Works
- Stolen or exposed AWS keys. The attacker uses AWS access keys that were publicly exposed or previously compromised, and that carry
s3:GetObjectands3:PutObjectpermissions. - Re-encryption with the attacker's key. Objects are rewritten using SSE-C with AES-256. The attacker supplies the encryption key in the request (the
x-amz-server-side-encryption-customer-algorithmand matching key headers). AWS uses the key to encrypt the data and does not store it. - A deadline. The attacker marks the files for deletion within seven days through S3 lifecycle rules, which turns the encryption into a countdown.
- A ransom note. A note left in the affected prefixes gives a Bitcoin address and a client ID, and warns that changing account permissions or files will end negotiations.
Why the Data Can't Be Recovered
With SSE-C, S3 never stores the key; whoever supplied it is the only one who can decrypt the data. There is no copy for AWS support to hand back and nothing in your logs to recover it from. Unless a clean copy exists somewhere the attacker couldn't reach, paying for the key is the only way back to the data, and even that depends on the attacker keeping their word.
Halcyon's report documents encryption and extortion. It does not document data exfiltration, so there is no evidence of a double-extortion stage in this campaign.
How This Differs From Classic Ransomware
Most ransomware still works the old way: a binary lands on Windows hosts, spreads through the network and encrypts files on disk. The code below, from a file-encrypting sample, is typical. It encrypts smaller files and overwrites larger ones with random data before renaming them.
Codefinger skips every one of those stages. There is no dropper, no lateral movement across hosts and no process to catch in the act. The attack happens entirely through legitimate, authenticated cloud API calls, so endpoint tools see nothing. The defences that matter are identity and cloud logging.
The Broader Ransomware Picture
For context, the rest of this section covers how classic ransomware grew and how it operates today. None of it describes Codefinger specifically.
Ransomware timeline
- 1989The AIDS Trojan (a.k.a. PC Cyborg), the first instance of ransomware. Created by Dr. Joseph Popp and distributed to 20,000 attendees at the World Health Organization (WHO) AIDS conference on 5¼" floppies. Demanded $189.
- 2004/2005GpCoder. A message on the user's home screen directed them to a .txt file on their desktop explaining how to pay the ransom and unlock the affected files. Demanded $200.
- 2006Archiveus Trojan. Primarily a Windows-based attack. Encrypted the MyDocuments directory. First ransomware to use RSA encryption.
- 2012Locker ransomware. Reveton locked the victim's screen with a fake law-enforcement notice (the "FBI MoneyPak" scam) and demanded a fine. WinLock was an earlier example of the same approach.
- 2013CryptoLocker. First ransomware to demand payment in bitcoin.
- 2014CryptoWall. Leveraged a Java vulnerability. Nearly 1,000 victims; estimated losses of at least $18 million.
- 2015TeslaCrypt. Targeted files belonging to computer games, alongside documents and photos.
- 2016Often called "the year of ransomware". Locky spread through huge phishing campaigns, with as many as 500,000 emails per day. Cerber, Jigsaw, SamSam and Petya were also active that year.
- 2017WannaCry attacked an estimated 200,000 computers in about 150 countries; U.S. and U.K. officials claimed North Korea was behind it. NotPetya, a variant of Petya, targeted victims in Ukraine including the National Bank of Ukraine; U.S. officials estimated damages at more than $10 billion.
- 2021DarkSide. The Colonial Pipeline attack. The pipeline was shut down for six days, and Colonial paid a $4.4 million bitcoin ransom.
Modern ransomware is an ecosystem. Initial access brokers, stealer and loader operators, affiliates and ransomware-as-a-service developers each handle one stage, supported by bulletproof hosting, money laundering and anonymisation services.
The ransomware-as-a-service ecosystem
Initial compromise
- Direct exploitation or brute force
- Distribution, through a TDS (traffic distribution system) to stealers and loaders
Access sold on
- Initial access brokers
- Access marketplaces
Operators
- Affiliates, using post-exploitation tools
Service
- Ransomware as a service (RaaS)
- Financial services
- Bulletproof hosting (BPH) services
- Anonymisation tools and communications
Groups advertise, recruit and publish victims through dark web forums, encrypted messengers and leak sites.
Inside a network, classic ransomware typically moves from one foothold, such as an exposed remote desktop, to file servers, user machines and connected devices.
Movement through the network
| From | To |
|---|---|
| Attacker | Remote desktop |
| Remote desktop | Web server |
| Remote desktop | File server |
| File server | End users |
| Remote desktop | Connected devices (printers, routers), marked as infected |
Two delivery chains
A malware TTP
- 'fallguy'
- Malicious codeindex.js
- Obfuscated code_0x13e5
- Steal information via a URLTelegram, cloud download
#TA577
- *.zip
- *.js
- *.exe
- C2
Every stage of that on-host kill chain leaves traces, and catching any one of them can stop the attack:
Ransomware kill chain: 7 detection opportunities
You only need to catch one to stop the attack.
01Initial access
- Indicators
- Phishing emails, RDP brute force, vulnerable public-facing apps.
- Tools and logs
- Email gateway, firewall logs, failed auth attempts, IDS/IPS.
- Action
- Block suspicious IPs, quarantine emails, disable compromised accounts immediately.
02Execution
- Indicators
- Suspicious process creation, PowerShell/cmd abuse, macro execution.
- Tools and logs
- EDR, Sysmon (Event ID 1), script block logging.
- Action
- Kill malicious processes, isolate endpoint, capture memory dump for forensics.
03Persistence
- Indicators
- Registry modifications, scheduled tasks, startup folder changes.
- Tools and logs
- Sysmon (Event ID 12, 13), Task Scheduler logs, Autoruns, EDR.
- Action
- Remove persistence mechanisms, check all systems for similar IOCs, rebuild if needed.
04Discovery and recon
- Indicators
- net.exe, nltest, whoami, ipconfig, mass network scanning.
- Tools and logs
- SIEM correlation rules, process command lines, network traffic logs.
- Action
- Isolate now. This is your best catch point. Network segmentation can limit spread.
05Credential access
- Indicators
- Mimikatz, LSASS dumps, ntds.dit access, SAM registry reads.
- Tools and logs
- EDR alerts, Sysmon (Event ID 10), Windows Security logs 4663/4656.
- Action
- Critical window. Isolate, force password resets on admin accounts, revoke Kerberos tickets.
06Lateral movement
- Indicators
- RDP sessions, PsExec, WMI, SMB file copies, unusual auth patterns.
- Tools and logs
- Windows Event ID 4624/4625, network flow data, EDR lateral movement alerts.
- Action
- Mass isolation mode. Segment networks, disable admin shares, hunt for additional compromises.
07Impact (encryption)
- Indicators
- vssadmin delete, bcdedit, wevtutil, mass file modifications, ransom notes.
- Tools and logs
- Process monitoring, file integrity monitoring, Event ID 1102, EDR ransomware detection.
- Action
- Too late for prevention. Activate the IR plan: isolate all systems, preserve evidence, engage leadership.
Detecting Codefinger-Style Attacks
- Turn on S3 data-event logging. CloudTrail doesn't record object-level requests by default. Without data events you won't see the encryption happen.
- Alert on SSE-C where you don't use it. In CloudTrail, S3 writes that used a customer-provided key carry
"SSEApplied":"SSE_C"in the event's additional data. They are rare in most environments, so a burst of them onPutObject,CopyObjector multipart uploads is a strong signal. - Watch lifecycle changes. New or modified lifecycle rules that expire objects within days, especially right after bulk writes.
- Watch the keys. Long-lived access keys used from new IP addresses, regions or user agents, or used at unusual volume.
- Look for ransom notes as objects. New small text objects appearing across many prefixes at once.
Mitigation
- Make sure SSE-C is blocked. Since April 2026, S3 blocks SSE-C by default on new buckets, and on existing buckets in accounts that had no SSE-C encrypted objects. Older buckets may still allow it: check each bucket's default encryption configuration (
BlockedEncryptionTypes) and block SSE-C unless a workload genuinely needs it. An IAM or bucket policyConditionons3:x-amz-server-side-encryption-customer-algorithmadds a second layer. - Get rid of long-lived keys. Audit and rotate access keys, disable the ones nobody uses, and prefer short-lived role credentials.
- Least privilege. Few principals need both read and write on every object in a bucket.
- Keep a copy out of reach. Versioned buckets protected by Object Lock, or replicas in a separate account, give you something to restore from.
- Find exposed keys before attackers do. Keys leak through public repositories, paste sites and stealer logs, which is exactly the kind of exposure external threat intelligence is built to catch.
Related reading from Cypho:
- Scattered Spider: The Group Currently Scattering UK Retail Organizations — how access brokers and ransomware operators collaborate in modern extortion campaigns
- Threat Detection and Response Acceleration — accelerate your ability to detect and contain ransomware before encryption begins
References
- https://www.cert.br/docs/ransomware/en/
- https://x.com/CyberDefenders/status/1980212997373956302
- https://www.esecurityplanet.com/threats/rdp-attacks/
- https://securityaffairs.com/173089/cyber-crime/codefinger-ransomware-gang-encrypts-s3-bucket.html
- https://cpl.thalesgroup.com/blog/data-security/the-rise-of-non-ransomware-attacks-on-aws-s3-data
- https://www.cyberark.com/resources/hybrid-and-multi-cloud-security/preventing-cloud-access-mismanagement-lessons-from-the-codefinger-ransomware-attack