Codefinger: How an emerging ransomware threat exploited an AWS S3 encryption feature to hold data hostage

When it comes to ransomware, most organizations think of file encryption happening on endpoints or corporate servers. But a new attack method has emerged—one that turns Amazon S3’s own security features against its users.

Meet Codefinger, a threat actor that exploits AWS Server-Side Encryption with Customer-Provided Keys (SSE-C) to lock organizations out of their own data. By encrypting S3 objects with their own encryption keys, Codefinger forces businesses into an impossible dilemma: pay the ransom or lose access to critical cloud data forever.

This blog explores how this attack works, why it’s so dangerous, and most importantly, how you can protect your AWS environment from becoming the next victim.

This research is based on findings from Halcyon.ai and internal security assessments on AWS S3 vulnerabilities.

How Codefinger uses AWS SSE-C as a ransomware tool

Cloud platforms like AWS offer powerful security features, but security is never a set-it-and-forget-it process. While AWS provides strong encryption, identity management, and monitoring tools, no cloud environment is inherently impenetrable. Staying secure requires vigilance, proactive risk assessment, and continuous adaptation to evolving threats.

Codefinger’s attack is a reminder that even features designed to secure a platform can become attack vectors if misused. In this case, server-side encryption with customer-provided keys (SSE-C)—designed to protect data—was turned into a ransomware weapon. Here’s how the attack unfolds:

1. Gaining access: Credential compromise

To launch this attack, Codefinger first needs access to a victim’s AWS credentials. This can happen in multiple ways:

• Leaked AWS keys in GitHub repositories or misconfigured applications.
• Session hijacking attacks that steal valid AWS authentication tokens.

2. Reconnaissance: Finding vulnerable buckets

Once inside the AWS environment, Codefinger scans for S3 buckets where it can manipulate in such a way that it can’t be recovered. Specifically, they look for:

• s3:GetObject and s3:PutObject which allows overwriting existing objects, effectively locking out the original owner by encrypting the data with an attacker-controlled SSE-C key.
• s3:PutBucketLifecycleConfiguration which enables modification of lifecycle policies, allowing attackers to remove previous object versions and permanently delete unencrypted copies such that they can’t be recovered.

By identifying S3 buckets where both of these permissions are available, the attacker ensures that once they execute the encryption, even standard AWS versioning and recovery mechanisms will be useless.

3. Execution: Encrypting data with SSE-C

With access secured, Codefinger then:

• Generates a new AES-256 encryption key (using OpenSSL).
• Encrypts each file using AWS S3’s SSE-C feature.
• Overwrites the original files, rendering them inaccessible without the attacker’s key.

4. Exploitation: The ransom demand

With the data now locked under an encryption key the attacker controls, Codefinger ensures that recovery is impossible by systematically deleting original, unencrypted files. This is accomplished through a combination of direct deletions and lifecycle policy manipulation:

• Overwriting files with SSE-C encryption: The attacker replaces original objects with encrypted versions, ensuring that victims cannot access the data without the ransom key.
• Modifying S3 lifecycle rules (s3:PutBucketLifecycleConfiguration): The attacker sets or alters lifecycle policies to:
  • Permanently delete old object versions, preventing recovery through S3 Versioning.
  • Shorten retention periods for deleted objects, ensuring rapid removal from S3’s underlying storage.

By co-opting lifecycle rules, even organizations with S3 Versioning enabled may find their historical object versions systematically erased, leaving no way to restore unencrypted copies.

At this point, Codefinger leaves a ransom note in the affected bucket, demanding payment—often in cryptocurrency—to provide the encryption key before all remaining versions are automatically purged. Victims are warned that any attempt to alter bucket policies will lead to irreversible deletion of their files.

Why this attack is so dangerous

• AWS doesn’t hold the encryption key: Unlike standard ransomware, which might have decryption workarounds, AWS does not store SSE-C keys. If you lose the key, your data is gone forever.
• Limited forensic evidence: AWS only logs a hashed (HMAC) version of the encryption key, which is not useful for recovery or forensic investigations.
• High-pressure ransom tactics: Codefinger typically threatens to delete the encrypted data within 7 days, leaving businesses with little time to respond.

How to protect your AWS S3 buckets from SSE-C ransomware

The good news? You can defend against this attack. Here’s what security teams should do right now to protect their AWS environments:

1) Restrict SSE-C encryption in S3

• Disable SSE-C where unnecessary – Use AWS IAM policies to deny SSE-C usage in your environment.
• Require AWS KMS (Key Management Service) for all encryption instead.
• Enforce S3 bucket policies that prevent objects from being overwritten using external encryption keys.

2) Strengthen AWS credential security

• Regularly rotate AWS access keys and eliminate long-lived credentials.
• Use IAM roles instead of static keys wherever possible.
• Enable Multi-Factor Authentication (MFA) to prevent unauthorized access.

3) Enforce resource control policies (RCPs)

• Use AWS Organizations to apply security guardrails that block SSE-C abuse.
• Restrict who can perform s3:PutObject operations with customer-provided keys.

4) Monitor for suspicious AWS activity

• Enable AWS GuardDuty to detect unusual access patterns.
• Audit CloudTrail logs for anomalies, especially around S3 activity.

5) Maintain a reliable backup strategy

• Follow the 3-2-1 backup rule: 3 copies of your data, 2 different storage types, 1 backup stored offsite.
• Regularly test your disaster recovery plan to ensure you can restore data without paying ransom.

How we stopped SSE-C ransomware with an RCP policy

At Rewind, we implemented an AWS Resource Control Policy (RCP) that blocks the use of SSE-C encryption for S3 objects. This ensures that even if credentials are compromised, attackers can’t encrypt data using their own keys.

AWS RCP Policy: Blocking unauthorized SSE-C use

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenySSECEncryption",
            "Effect": "Deny",
 "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "*",
            "Condition": {
                "Null": {
                   "s3:x-amz-server-side-encryption-customer-algorithm": "false"
                }
            }
        }
    ]
}

What this policy does:

• Blocks any attempt to encrypt S3 objects using SSE-C.
• Prevents an attacker from locking legitimate users out of their data.

Final takeaways: Adapting to the evolving cloud security landscape

At Rewind, security isn’t a feature, it’s fundamental. We continuously monitor emerging threats, analyze their impact, and adjust our security posture in real time to stay ahead of adversaries.

Codefinger’s SSE-C ransomware attack is a perfect example of how threat actors adapt, leveraging cloud-native features against the very organizations that rely on them. When we identified this risk, we took immediate action:

• Conducted a rapid assessment of our AWS environments to determine exposure.
• Implemented Resource Control Policies (RCPs) to block unauthorized SSE-C encryption.
• Strengthened AWS access controls and enhanced monitoring to detect suspicious activity.
• Validated our backup and recovery processes to ensure resilience against this type of attack.

We acted fast and now, we’re sharing our insights in the hope that we can help others enhance their security posture. 

Attacks like Codefinger are a reality of modern cloud security: threats will evolve and data resilience requires a backup plan.