The Codefinger Ransomware Attack: Wake-Up Call for Cloud Security

Picture this: It’s a regular Tuesday. Your team is rolling out updates, pushing code, and everything in your AWS environment looks calm and under control.

Then you get an alert that your Amazon S3 buckets have been encrypted.

Not by malware. Not from an infected laptop. But by someone using AWS’s features—SSE-C encryption—against you.

This isn’t fiction.

It happened very recently in the 2025 Codefinger ransomware attack.

This breach exposed a hard truth: even legitimate cloud-native features can be exploited if security isn’t built into the architecture. Security isn’t just about having the right tools—it’s about thoughtfully designing your cloud environment to prevent misuse.

In this newsletter, we’re exploring what it means to build securely in AWS.

We'll cover:

• What went wrong with Codefinger: When native services are misused due to weak configurations

• How AWS helps you protect yourself: Identity boundaries, encryption strategies, and monitoring

• Security best practices: Principle of least privilege, managed key services, secure access policies

• Why SSE-C is risky: When to use SSE-KMS or SSE-S3 instead

• Real-world strategies: Setting up detective controls, centralized logging, and compliance automation

Let’s start!

2025 Codefinger ransomware attack#

In early 2025, a ransomware campaign named Codefinger made headlines for its unique way of attacking AWS customers, particularly those using Amazon S3 to store their data.

Unlike traditional ransomware attacks (which usually rely on malware to lock your computer or encrypt files), Codefinger didn’t need to install anything. Instead, it cleverly used AWS’s feature—server-side encryption with customer-provided keys (SSE-C)—to encrypt S3 objects with keys only the attackers knew, effectively locking users out of their data.

Why does SSE-C matter in this attack?#

To understand how the attackers locked users out of their data, we need to look at a lesser-used encryption method in AWS: SSE-C (server-side encryption with customer-provided keys).

It played a central role in the Codefinger breach, and knowing how it works helps explain how AWS-native features can become vulnerabilities when misconfigured.

What is SSE-C?#

In Amazon S3, you can encrypt the data using different methods. One of those methods is SSE-C:

This means you provide your encryption key when uploading data, and AWS uses that key to encrypt your data before storing it. You must provide the same key whenever you want to retrieve your data.

What did Codefinger do?#

Here’s how the Codefinger attack worked:

1. Targeted poorly secured S3 buckets that were public or had misconfigured access permissions.

2. Used valid API calls (not malware!) to download the data, encrypt it with a new SSE-C key, and re-upload it.

3. The data was locked, and the AWS user could no longer access it because only Codefinger had the encryption key.

4. Victims received a ransom demand: Pay to get the key and regain access.

Why did this happen?#

The success of the Codefinger attack highlighted several security lapses:

• Overly permissive access controls: The attack exploited S3 buckets with weak or misconfigured permissions, allowing unauthorized access without compromising credentials.

• Misuse of SSE-C: Employing SSE-C without stringent controls allowed attackers to encrypt data with their keys

• Insufficient monitoring: The absence of real-time monitoring and alerting delayed detecting unauthorized activities.​

AWS Well-Architected Framework: Security pillar#

The Codefinger attack didn’t breach AWS itself—it exposed how AWS can be misused when security isn’t woven into the architecture.

This is exactly what the security pillar of the AWS Well-Architected Framework is built to prevent. The AWS Well-Architected Framework is a set of guidelines to help us build secure, resilient, and performant infrastructure on AWS.

In the Security pillar, design principles include:

• Strong identity foundation: Implementing the principle of least privilege and centralized identity management.

• Enable traceability: Monitoring, alerting, and auditing actions and changes to your environment in real time.​

• Apply security at all layers: Implementing defense in depth by applying security measures at every layer, from the perimeter to the application.

• Automate security best practices: Using automation to enforce security policies and detect threats promptly.​

• Protect data in transit and at rest: Using encryption and tokenization to safeguard data.​

• Prepare for security events: Developing incident response plans and regularly simulate scenarios to ensure readiness.

This is all designed to keep intruders out, and ensure the tools inside your environment don’t become your weakest link.

Let's dig into what it means to build a strong identity foundation.

Implementing a strong identity foundation#

Implementing a strong identity foundation ensures that access to AWS resources is strictly controlled, traceable, and based on a user’s job responsibilities.

This involves 2 key concepts:

1. The principle of least privilege#

The principle of least privilege states that users, systems, or services should be given the minimum level of access, only the permissions necessary to perform their functions.

This minimizes the attack surface, reduces the risk of unauthorized access, and limits the damage from accidental or malicious activities.

Why is it important?#

The principle of least privilege prevents overly permissive access, reducing the chances of severe damage. It enforces tighter control over sensitive resources and supports compliance and auditability. Let’s see an example of an overly permissive and restricted policy.

The widget above has two policies:

• The first one, in the “Overly Permissive” tab, allows all actions on all resources.

• The policy in the “Restrictive Policy” tab allows retrieving and updating the code of the specific Lambda function MyLambdaFunction in the us-east-1 region.

2. Centralized identity management#

In AWS, centralized identity management refers to managing user identities, access controls, and permissions using services like AWS Identity and Access Management (IAM), AWS IAM Identity Center (formerly AWS SSO), and Directory Service integrations.

Lessons from the Security Pillar #

Let's revisit guidelines from the security pillar and actionable tips you can apply today:

• Implement a strong identity foundation:

  • Enforce the principle of least privilege by granting users only the permissions necessary for their roles.

    • Regularly audit and rotate credentials to prevent unauthorized access.​

• Enable traceability:

  • Use AWS CloudTrail and Amazon CloudWatch to monitor, log, and alert on account activities in real time, facilitating prompt detection of suspicious actions.

• Protect data at rest and in transit:

  • Use AWS-managed encryption keys (SSE-S3 or SSE-KMS) instead of SSE-C to maintain better control and auditing capabilities over encryption keys.​

    • SSE-S3 (Server-side encryption with S3-managed keys): AWS-managed encryption keys (SSE-S3) do not require any key management and integrate well with AWS IAM for access control.

    • SSE-KMS (Server-side encryption with AWS Key Management Service): AWS uses KMS AWS or customer-managed keys to encrypt objects, offering fine-grained access control through key policies and IAM. It also provides detailed audit logs via AWS CloudTrail, allowing users to track who accessed specific resources and when.

• Automate security best practices:

  • Implement automated responses to security incidents, such as revoking compromised credentials and notifying administrators of anomalous activities.​

• Prepare for security events:

  • Develop and regularly test incident response plans to ensure swift action when security breaches occur.​

• Apply security at all layers:

  • Implement defense in depth by applying security measures at every layer, from the perimeter to the application.

Where we go from here #

The Codefinger ransomware attack wasn’t a flaw in AWS but a failure in its use.

It showed us that misconfigured permissions, misunderstood encryption settings, and missing monitoring can turn powerful tools into security risks. While useful in the right hands, SSE-C became a weapon when left unguarded.

The lesson? Cloud security depends on intentional and well-designed architecture.

As you build forward:

• Choose managed encryption (like SSE-KMS or SSE-S3) over risky key management unless necessary.

• Treat identity and access policies as code—review, test, and minimize.

• Automate monitoring, auditing, and response—because humans miss things that code won’t.

• Simulate failure. Prepare for it. Design like it’s not if, but when.

The future of cloud security is proactive#

Security isn’t a product you buy. It’s a culture you build.

Tools will evolve, threats will get smarter, but a well-architected foundation stays resilient. Keep challenging your assumptions. Review your architectures regularly. And above all, build with the idea that anyone—even you—could be tomorrow’s headline.

Stay alert. Stay curious. Stay secure.

Learn how to secure your AWS environment by mastering IAM. Write effective access policies, prevent over-permissioning, and build strong identity foundations just like AWS architects do with our popular course:

You can also get hands-on with AWS (with no setup or account required) with Educative Cloud Labs, including:

• Understanding AWS Security and Management—From Zero to Hero

• Improving Your Security Posture Using AWS Security Hub

Happy learning!