SSE-C Encryption Hijacking
A cloud-native ransomware attack vector where threat actors use compromised IAM credentials to execute CopyObject API calls with Server-Side Encryption using Customer-Provided Keys (SSE-C), re-encrypting an organization's S3 data with an attacker-controlled key and permanently locking the owner out.
Summary
A cloud-native ransomware attack vector where threat actors use compromised IAM credentials to execute CopyObject API calls with Server-Side Encryption using Customer-Provided Keys (SSE-C), re-encrypting an organization's S3 data with an attacker-controlled key and permanently locking the owner out.
Represents the evolution of cloud ransomware from data exfiltration and deletion to weaponizing legitimate AWS encryption APIs. Unlike traditional ransomware that is noisy and detectable, SSE-C hijacking uses standard S3 operations that pass all API validation. The only durable defense is S3 Object Lock in Compliance Mode, which prevents any modification — including re-encryption — during the retention period.
- Default encryption at rest does NOT protect against this attack — SSE-C hijacking uses valid API calls with valid credentials to re-encrypt data.
- Versioning alone is insufficient — attackers can delete version markers or re-encrypt all versions.
- MFA Delete adds friction for automated scripts but does not prevent legitimate CopyObject API calls with SSE-C headers.
constrained_byObject Lock / WORM Semantics — the only cryptographic guarantee against re-encryption during retention periodsconstrained_byEncryption / KMS — proper KMS key policies can restrict who performs encryption operationsscoped_toS3 — exploits native S3 API operations that pass all standard validation
Definition
A cloud-native ransomware attack vector where threat actors use compromised IAM credentials to execute CopyObject API calls with Server-Side Encryption using Customer-Provided Keys (SSE-C), re-encrypting an organization's S3 data with an attacker-controlled key and permanently locking the owner out.
Recent developments
- AWS disabled SSE-C encryption by default on new S3 buckets (effective April 6, 2026). SSE-C is now off by default on all new general-purpose buckets — and disabled on existing buckets in accounts with no SSE-C data — rolling out across 37 Regions; apps needing it must opt in via PutBucketEncryption. AWS frames this as a security-hardening default favoring SSE-KMS. Per Advanced notice: Amazon S3 to disable SSE-C encryption by default (AWS Storage Blog).
- AWS disabling SSE-C by default — April 6, 2026. Material AWS policy change: from April 6, AWS disables SSE-C by default on all new S3 general-purpose buckets, and disables for existing buckets without SSE-C-encrypted data. Closes the SSE-C ransomware vector at the default level. Per AWS Security Blog — Preventing unintended encryption of Amazon S3 objects.
- First widely-documented campaign: Codefinger (January 2025). The Halcyon RISE Team identified the Codefinger campaign as the first widely-documented S3 ransomware operation using SSE-C encryption to lock victims out of their data — establishes the attack pattern that AWS's default-disable response targets.
- Attack mechanism: leaked IAM credentials → SSE-C encryption → permanent lockout. Threat actors gain write-level access via compromised credentials or leaked IAM roles from public GitHub repos. They then provide a locally-stored AES-256 key through specific HTTP request headers — once encrypted, recovery is impossible without the attacker's key. CloudTrail logs only the HMAC of the encryption key, insufficient for recovery or forensic analysis.
- Detection signal: x-amz-server-side-encryption-customer-algorithm header presence. The presence of this field identifies when user-managed keys are used to encrypt objects — the foundational signal for detection pipelines. Per Elastic Security Labs — Emulating AWS S3 SSE-C Ransom for Threat Detection.
- Amazon GuardDuty + S3 Protection + Extended Threat Detection covers SSE-C. GuardDuty with S3 Protection + Extended Threat Detection now detects potential ransomware attempts conducted with SSE-C encryption. AWS-native baseline detection. Per Panther — Detecting Cloud Ransomware on AWS S3.
- 2026 Arctic Wolf + Cybersecurity News tracking new variants. Multiple ransomware variants now target Amazon S3 services leveraging misconfigurations + weak access controls. Active threat landscape — defense must be configuration + monitoring + Object Lock, not any single layer. Per Arctic Wolf — Ransomware Campaign Encrypting S3 with SSE-C and Cybersecurity News — Ransomware Variants Targeting S3.
Connections 3
Outbound 3
scoped_to1constrained_by2Resources 3
Detailed guide on using S3 Object Lock to defend against cloud-native ransomware including SSE-C re-encryption attacks.
Analysis of S3 Object Lock as defense against encryption hijacking, covering Compliance vs Governance mode trade-offs.
MinIO's implementation of immutable WORM storage as ransomware defense for on-premises S3-compatible deployments.