Codefinger: The Ransomware That Doesn’t Infect Your Servers

Threat Advisory Date: December 30, 2024
Threat Name: Codefinger Ransomware
Target Platform: Amazon Web Services (AWS) S3
Classification: Cloud-Native Ransomware / Data Encryption Malware
Threat Level: CRITICAL

Executive Summary

A new ransomware strain known as Codefinger has emerged, marking a dangerous shift in how ransomware attacks are executed. Unlike traditional ransomware that infects endpoints or servers, Codefinger operates entirely inside the cloud, directly abusing native APIs to encrypt data stored in Amazon S3 buckets hosted on Amazon Web Services.

This is not malware in the conventional sense. There is no executable dropped, no endpoint alert, and no disk-level encryption. Instead, attackers leverage compromised AWS credentials and misconfigured IAM permissions to overwrite, encrypt, and delete S3 objects at scale. For organizations without S3 versioning, immutable backups, or Object Lock enabled, recovery may be impossible without paying the ransom.

What makes Codefinger especially dangerous is how legitimate its activity appears. Every action is performed using standard AWS APIs, making it easy to miss until data is already gone.

Why Codefinger Is Different (and More Dangerous)

Codefinger is best described as cloud-native ransomware. It was clearly designed with deep knowledge of AWS environments and common misconfigurations.

Key distinguishing traits include:

Purpose-built to target AWS S3, not operating systems
Exploits overprivileged IAM roles and leaked access keys
Bypasses antivirus, EDR, and endpoint security entirely
Deletes object versions and backup markers when possible
Encrypts data and manipulates metadata and access controls

The result is a ransomware event that looks like “normal cloud activity” until it’s far too late.

Severity and Business Impact

S3 is often used to store an organization’s most critical assets: production data, backups, analytics datasets, application artifacts, and data lakes. A successful Codefinger attack can cause:

Permanent loss of business-critical data
Complete application outages
Regulatory violations (GDPR, HIPAA, PCI DSS)
Breach notification obligations
Severe reputational and financial damage

If S3 versioning and immutable backups were not enabled before the attack, even AWS cannot help recover the data.

Threat Intelligence Overview

Codefinger was first observed in the wild in December 2024. Early incidents indicate financially motivated attackers demanding anywhere from 5 to 50 Bitcoin per affected bucket, depending on data size and perceived business value.

Attribution remains unclear, though tradecraft suggests an experienced cybercrime group familiar with cloud environments rather than traditional endpoint ransomware crews.

What is clear is that exploitability is high. The attack relies on extremely common cloud mistakes: leaked credentials, wildcard IAM permissions, and weak backup hygiene.

How the Attack Works: From Access to Extortion

1. Initial Access: Credentials, Not Malware

Codefinger does not “break into” AWS. It simply logs in.

Access is typically gained through:

Exposed AWS keys in GitHub repositories or CI/CD pipelines
Hardcoded credentials in application code or Docker images
Compromised developer workstations
Overly permissive IAM roles attached to EC2 or Lambda
Third-party SaaS tools with excessive S3 access

Once valid credentials are obtained, the rest of the attack looks like legitimate automation.

2. Discovery and Assessment

After gaining access, the attacker:

Enumerates all accessible S3 buckets
Checks which buckets have versioning enabled
Looks for replication, backups, or Object Lock
Identifies buckets that can be destroyed without recovery

Buckets lacking strong defenses are prioritized first.

3. Encryption and Destruction

For each target bucket, Codefinger:

Downloads objects via GetObject
Encrypts data using AES-256, typically with unique keys per object
Uploads encrypted replacements
Deletes original objects
Attempts to delete all historical versions and delete markers

Object metadata is modified to mark files as encrypted and embed ransom identifiers.

4. Ransom Deployment

Once encryption is complete, a ransom note is dropped into every affected bucket. Victims are instructed to pay Bitcoin within a limited time window, often with escalating penalties for delays.

Attackers explicitly warn victims not to contact AWS, knowing that cloud providers cannot decrypt customer-managed data.

Indicators of Compromise (IOCs)

Behavioral Indicators (Most Reliable)

Because this attack uses legitimate APIs, behavioral detection is far more effective than signature-based detection.

Red flags include:

Sudden spikes in PutObject and DeleteObject calls
Mass DeleteObjectVersion activity
Buckets suddenly filled with .encrypted, .CF2024, or similar extensions
Appearance of ransom note files
S3 API calls originating from Tor exit nodes or unfamiliar geographies

Metadata and Object Changes

Encrypted objects often contain new metadata fields indicating:

Encryption status
Ransom ID
Attacker contact information
Bitcoin wallet addresses

Detection and Monitoring Strategy

Traditional endpoint tools are ineffective here. Detection must focus on AWS CloudTrail, GuardDuty, and log analytics.

Effective detection strategies include:

Alerting on abnormal S3 API call volumes
Correlating bucket enumeration followed by mass writes/deletes
Flagging versioning changes on protected buckets
Monitoring for automated user agents like boto3 or aws-cli at unusual hours

Organizations that monitor S3 data events, not just management events, are far more likely to catch attacks early.

Incident Response: What to Do If You’re Hit

Immediate Priorities (First 15 Minutes)

Disable compromised IAM credentials immediately
Apply deny-all policies to affected users or roles
Preserve CloudTrail logs for forensics
Notify security, cloud, legal, and executive teams

Speed matters. Every minute of delay can mean more data destroyed.

Recovery Options

Best case:

Restore from S3 versioning, replication, or AWS Backup

Worst case:

No versioning, no immutable backups → permanent data loss

Paying the ransom is strongly discouraged. There is no guarantee attackers will provide working decryption keys, and payments may violate sanctions laws.

Prevention: What Actually Stops Codefinger

Codefinger is devastating—but also highly preventable.

The most effective defenses are simple, but must be enabled before an attack:

1. S3 Versioning + MFA Delete

Prevents attackers from permanently deleting data history.

2. S3 Object Lock (Immutable Storage)

Stops anyone—including attackers with admin access—from deleting objects during retention periods.

3. Least-Privilege IAM

No wildcard s3:*. No unnecessary delete permissions. Ever.

4. Credential Hygiene

No hardcoded keys
Frequent key rotation
Secrets Manager or IAM roles only

5. Independent Backups

Backups must live in separate accounts or regions with restricted access.

The Bigger Picture: Why This Matters

Codefinger is not just another ransomware variant. It’s a preview of what modern ransomware looks like in cloud-first organizations.

This attack proves a hard truth:

Cloud ransomware doesn’t need malware. It only needs permissions.

Organizations that rely on AWS but still think in endpoint-security terms are dangerously exposed. Cloud security is about identity, access, logging, and resilience—not antivirus.

Final Takeaway

Codefinger represents a fundamental shift in ransomware strategy. It exploits trust in cloud platforms, human error in IAM configuration, and the false assumption that “the cloud backs everything up automatically.”

The real question is no longer if cloud ransomware will hit your organization—but whether you’ve already done the work to survive it.