suKTech24

Analyzing Codefinger’s Attack on Amazon S3 server-side encryption with customer-provided keys (SSE-C)

Weekly #12-2025 – By suktech24, Sun 3 Aug 2025, Estimated reading time : 10 mins

In recent cloud ransomware campaigns, the Codefinger group has emerged as a sophisticated threat actor targeting Amazon S3 buckets by exploiting SSE-C. By abusing exposed AWS credentials with permissive S3 permissions, Codefinger overwrites existing objects with encrypted versions using their own keys – locking out legitimate access and demanding ransom for recovery.

This article explores how SSE-C works under normal conditions in Amazon S3, and how the Codefinger ransomware group abuses it to lock out legitimate access and extort victims. For educational purposes, the attack flow is mapped using both the Cyber Kill Chain and the MITRE ATT&CK framework, highlighting the end-to-end tactics and techniques used.

In part 2, detection strategies, sigma rule and investigative steps for identifying and mitigating SSE-C abuse will be discussed.

1. Codefinger Ransomware Group
2. AWS S3
3. Encryption
4. Workflow – Normal
5. Workflow – Attacker : Cyber Kill Chain
6. Workflow – Attacker : MITRE ATT&CK
7. Detection of SSE-C Usage in your environment
8. References

---

Codefinger Ransomware Group

“Codefinger is a ransomware group that targets Amazon S3 buckets by exploiting AWS’s Server-Side Encryption with Customer Provided Keys to encrypt victim data. They utilize compromised AWS credentials to gain access and demand Bitcoin ransoms for the decryption keys, threatening to delete files if negotiations fail. The group has been observed abusing publicly disclosed AWS keys with permissions to read and write S3 objects, making recovery impossible without their cooperation. Halcyon has documented multiple incidents linked to Codefinger’s data extortion campaign against organizations with unsecured infrastructure.”

---

AWS S3

Amazon Simple Storage Service (Amazon S3) is an object storage service that stores data as objects, hierarchical data, or tabular data within buckets and offers industry-leading scalability, data availability, security, and performance.

• An object is a file and any metadata that describes the file. A bucket is a container for objects.
• A bucket is a container for objects.
• To store your data in Amazon S3, you first create a bucket and specify a bucket name and AWS Region. Then, you upload your data to that bucket as objects in Amazon S3.
• Each object has a key (or key name), which is the unique identifier for the object within the bucket.

---

Encryption

Server-side encryption is the encryption of data at its destination by the application or service that receives it. Amazon S3 encrypts your data at the object level as it writes it to disks in AWS data centers and decrypts it for you when you access it.

As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects. For example, if you share your objects by using a presigned URL, that URL works the same way for both encrypted and unencrypted objects. Additionally, when you list objects in your bucket, the list API operations return a list of all objects, regardless of whether they are encrypted.

• All Amazon S3 buckets have encryption configured by default, and all new objects that are uploaded to an S3 bucket are automatically encrypted at rest. 
• Server-side encryption with Amazon S3 managed keys (SSE-S3) is the default encryption configuration for every bucket in Amazon S3. To use a different type of encryption, you can either specify the type of server-side encryption to use in your S3 PUT requests, or you can update the default encryption configuration in the destination bucket.
• Below are types of encryption :
  • SSE-S3 -> Amazon S3 managed encryption keys ( by default)
  • SSE-KMS -> AWS Key Management Service (AWS KMS) keys
  • DSSE-KMS -> Dual-layer server-side encryption with AWS KMS keys
  • SSE-C -> AWS server-side encryption with customer-provided keys

Feature	SSE-S3	SSE-KMS	DSSE-KMS	SSE-C
Key Management	AWS-managed	AWS KMS-managed	AWS KMS-managed (dual)	Customer-managed
Encryption	AES-256	AES-256	AES-256 (dual-layer)	AES-256
Use Case	Basic encryption	Compliance, auditing	High-security needs and highly regulated enviornments	Strict key control
Key Rotation	Automatic	Configurable in KMS	Configurable in KMS	Manual by customer If key is lost, data is unrecoverable.
Auditability	Limited	Fine-grained audit logging in CloudTrail.	Fine-grained audit logging in CloudTrail.	Only key’s HMAC (hash-based message authentication code)

---

Workflow – Normal

The normal flow outlines the legitimate process for using Amazon S3 with SSE-C to securely store and manage data in S3 buckets.

1. Initial Setup, Key generation and Management
   • By using SSE-C, customers can store their data in Amazon S3 encrypted using their own encryption keys. Amazon S3 handles the encryption of data as it is written to disk, and the decryption when the customer accesses their objects, using the key provided in each request.
   • This means customers don’t need to maintain custom encryption or decryption code, only to securely manage and supply their encryption keys.
   • When a customer uploads an object, Amazon S3 uses the provided encryption key to apply AES-256 encryption, then removes the key from memory. When retrieving the object, the customer must provide the same encryption key. Amazon S3 verifies the key by checking its Hash-based Message Authentication Code (HMAC) value, and if it matches, decrypts the data and returns the object.
2. IAM config for S3 access ( AWS IAM, AWS STS)
   • Customer configures AWS IAM policies to grant specific permissions to authorized users or applications.
     • s3:GetObject
     • s3:PutObject
     • s3:DeleteObject
     • s3:PutLifecycleConfiguration
     • s3:ListObjects
     • s3:ListBucket
3. Upload data to S3 with SSE-C (AWS S3, AWS Cloudtrail – logs only )
   • Customer uploads objects to an S3 bucket, specifying SSE-C. The request include headers like x-amz-server-side-encryption-customer-algorithm: true.
   • Amazon S3 does not store the encryption key that you provide. Instead, it stores a randomly salted Hash-based Message Authentication Code (HMAC) value of the encryption key to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means if the customer lose the encryption key, they lose the object.
4. Data Storage and retrieval (AWS S3)
   • The encrypted object is stored in S3, and the customer retrieves it by providing the same AES-256 key.
5. Detection Monitoring and Auditing
   • User’s S3 activities and IAM permissions for security and compliance
   • The AWS SSE-C key is not logged in CloudTrail. CloudTrail logs API activity such as getObject, PutObject, etc, and logs ONLY an hash-based message authentication code (HMAC) of the key for verification purposes.

SSE-C S3 Bucket policy – Sample

{
    "Version": "2012-10-17",
    "Id": "PutObjectPolicy",
    "Statement": [
        {
            "Sid": "RequireSSECObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption-customer-algorithm": "true"
                }
            }
        }
    ]
}

---

Workflow – Attacker : Cyber Kill Chain

This section maps Codefinger’s attack to Cyber Kill Chain and MITRE ATT&CK frameworks. This is done to contextualize the attack from both strategic (kill chain) and tactical (MITRE TTP) views .

Based on , https://www.elastic.co/security-labs/emulating-aws-s3-sse-c. Go to this gist for detailed implementation.

1. Reconnaissance
   • Identify exploitable AWS environments with accessible S3 buckets and exposed credentials.
   • Techniques:
     • Search public GitHub, GitLab, and other repositories for exposed AWS keys.
     • Enumerate S3 buckets with tools like aws s3 ls, bucket_finder, or custom scripts using compromised credentials
     • Query misconfigured or overly permissive IAM policies. (e.g., wildcard s3:* permissions).
2. Weaponization
   • Prepare the tools and custom encryption key needed for SSE-C misuse.
   • Steps:
     • Locally generate a 256-bit AES key for use with SSE-C.
     • openssl rand -out ssec.key 32
     • Write script for interactions with S3 to ensure objects are overwritten using SSE-C headers.
3. Delivery
   • Gain authenticated access to the victim’s AWS environment using stolen credentials.
   • Steps:
     • Load compromised AWS credentials (via environment variables, config files, or embedded tokens).
     • Ensure the credentials have s3:PutObject and s3:GetObject permissions.
     • Initialize an S3 client session using those credentials.
4. Exploitation
   • Encrypt existing S3 objects using SSE-C with generated key – effectively locking out legitimate access.
   • Steps:
     • List S3 objects: s3:ListObjectsV2
     • Download each object: s3:GetObject
     • Re-upload with SSE-C key (via signed s3:PutObject), overwriting originals
5. Installation
   • Increase long-term impact by scheduling irreversible object deletion.
   • Technique:
     • Apply an S3 lifecycle policy to auto-delete objects after a fixed period (e.g., 7 days), preventing future recovery.
6. Command and Control (C2)
   • Traditional C2 is not applicable in this step, but communication with the victim occurs.
   • Steps:
     • Upload a ransom note (e.g., README.txt) with instructions, Bitcoin address, and threats/warnings.
7. Actions on Objectives
   • Monetize the attack by demanding payment for decryption keys.

Above flow is derived Emulating AWS S3 SSE- C Ransom for Threat Detection, https://www.elastic.co/security-labs/emulating-aws-s3-sse-c

Visual representation of emulation workflow from Elastic security labs

---

Workflow – Attacker : MITRE ATT&CK

• https://attack.mitre.org/matrices/enterprise/cloud/
• https://attack.mitre.org/tactics/enterprise/

MITRE mapping

• Reconnaissance (TA0043)
  • T1589.001 – Gather Credentials: Public Repositories Attacker searches GitHub/GitLab for exposed AWS keys.
    (Load stolen AWS credentials)
  • T1590.005 – Gather Victim Network Information: IPs/Cloud Resources Enumerate open or misconfigured AWS S3 buckets via AWS CLI or bucket enumeration tools.
    (Generate S3 endpoint URL, Enumerate S3 objects)
• Initial Access (TA0001)
  • T1078.004 – Valid Accounts: Cloud Accounts Use of stolen AWS IAM credentials to authenticate and interact with victim resources (Establish S3 client with compromised credentials)
• Discovery (TA0007)
  • T1613 – Cloud Storage Object Discovery Use s3:ListObjectsV2 to enumerate contents of S3 buckets. (Enumerate S3 objects → s3:ListObjectsV2)
• Collection (TA0009)
  • T1530 – Data from Cloud Storage Retrieve unencrypted data from the S3 bucket using s3:GetObject. (Retrieve object from S3 → s3:GetObject)
• Impact (TA0040)
  • T1486 – Data Encrypted for Impact Encrypt S3 objects using SSE-C with attacker-provided key, locking out legitimate users. (Generate PUT request & sign with AWS SigV4 Encrypt & overwrite object in S3 → s3:PutObject)
  • T1485.001 – Data Destruction Apply lifecycle policy to delete encrypted S3 objects after 7 days. (Apply 7-Day deletion policy → s3:PutLifecycleConfiguration)
• Command and Control (TA0011)
  • T1102.002 – Web Service: Bidirectional Communication Upload ransom note into S3 bucket with payment instructions. (Upload ransom note to S3 → s3:PutObject)

---

Detection of SSE-C Usage in your environment

AWS provides guidance for detecting the use of SSE-C within an environment. As outlined in this AWS re:Post article, detection involves first configuring S3 Inventory on relevant buckets. The inventory reports, once delivered to a designated S3 bucket, can be queried using Amazon Athena to identify objects encrypted with SSE-C. CloudTrail logs can be examined for S3 operations that include the x-amz-server-side-encryption-customer-algorithm header, which signifies the use of customer-provided encryption keys.

put-bucket-inventory-configuration

aws s3api put-bucket-inventory-configuration \
    --bucket bucketname \
    --id bucketname-inventory \
    --inventory-configuration '{
        "Destination": {
            "S3BucketDestination": {
                 "AccountId": "DestinationBucketAccountId"
                "Bucket": "arn:aws:s3:::bucketname",
                "Format": "Parquet"
            }
        },
        "IsEnabled": true,
        "Id": "bucketname-inventory",
        "IncludedObjectVersions": "All",
        "Schedule": {
            "Frequency": "Daily"
        },
        "OptionalFields": [
            "Size",
            "LastModifiedDate",
            "StorageClass",
            "ETag",
            "IsMultipartUploaded",
            "ReplicationStatus",
            "EncryptionStatus",
            "ObjectLockRetainUntilDate",
            "ObjectLockMode",
            "ObjectLockLegalHoldStatus",
            "IntelligentTieringAccessTier"
        ]
    }'

Athena Query Sample

SELECT 
    count(encryption_status)
FROM 
    <inventory bucket table name>
WHERE 
    encryption_status = 'SSE-C'
    AND dt = '<most recent inventory report date>'

---

References

1. Abusing AWS Native Services: Ransomware Encrypting S3 Buckets with SSE-C, https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c
2. Amazon S3 encryption best practices, https://d1.awsstatic.com/events/Summits/reinvent2023/STG213-R_Amazon-S3-encryption-best-practices-REPEAT.pdf
3. Cloud Breach: Compromising AWS IAM Credentials, https://rhinosecuritylabs.com/aws/aws-iam-credentials-get-compromised/
4. Codefinger, https://malpedia.caad.fkie.fraunhofer.de/actor/codefinger
5. Codefinger Ransomware: Detection and Mitigation Using MixMode, https://mixmode.ai/blog/codefinger-ransomware-detection-and-mitigation-using-mixmode/
6. Cybersecurity Newsflash : New Codefinger ransomware attack targets compromised AWS keys, https://blog.devolutions.net/2025/01/cybersecurity-newsflash-new-codefinger-ransomware-attack-targets-compromised-aws-keys/
7. Defending Against Codefinger Ransomware in AWS S3, https://www.vectra.ai/blog/defending-against-codefinger-ransomware-in-aws-s3
8. Emulating AWS S3 SSE- C Ransom for Threat Detection, https://www.elastic.co/security-labs/emulating-aws-s3-sse-c
9. How to detect existing use of SSE-C in your Amazon S3 buckets, https://repost.aws/articles/ARhGC12rOiTBCKHcAe9GZXCA/how-to-detect-existing-use-of-sse-c-in-your-amazon-s3-buckets
10. impact_s3_excessive_object_encryption_with_sse_c.toml, https://github.com/elastic/detection-rules/blob/main/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml
11. impact_s3_unusual_object_encryption_with_sse_c.toml, https://github.com/elastic/detection-rules/blob/main/rules/integrations/aws/impact_s3_unusual_object_encryption_with_sse_c.toml
12. Ransomware Campaign Encrypting Amazon S3 Buckets using SSE-C, https://arcticwolf.com/resources/blog/ransomware-campaign-encrypting-amazon-s3-buckets-using-sse-c/
13. The shocking speed of AWS key exploitation, https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/
14. What is Amazon S3?, https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

---