Loading story…
Attackers who obtain AWS programmatic credentials with broad Amazon S3 permissions can overwrite objects using server-side encryption with customer-provided keys (SSE-C). The attackers control the AES-256 keys, which AWS does not store or recover; consequently, organizations cannot decrypt the replaced objects without the original attacker-held keys. The technique can be paired with a ransom note and a seven-day bucket lifecycle deletion policy, creating both an extortion mechanism and a risk of permanent data loss.
Organizations should collect Amazon S3 data events in AWS CloudTrail and alert on successful PutObject activity specifying SSE-C/AES256 encryption, especially where the behavior is new for an IAM principal or bucket. Defenses include enabling S3 versioning to preserve recoverable object versions, enforcing least-privilege IAM and restrictive bucket policies, and monitoring changes to lifecycle configurations. S3 default server-side encryption should be configured as appropriate, but it does not eliminate the risk from authorized requests that explicitly supply attacker-controlled SSE-C keys.
Map this exposure pattern across your cloud, code, and identities.
2 events from the most recent confirmed update back to the earliest known activity.
Elastic Security Labs published detection-engineering research emulating SSE-C ransom activity, including compromised AWS credentials being used to overwrite S3 objects, apply a seven-day deletion lifecycle policy, and leave a ransom note. It recommended comprehensive CloudTrail S3 data-event logging and detection of anomalous SSE-C PutObject activity.
Halcyon Research Team documented what it described as the first publicly known in-the-wild ransomware use of Amazon S3 Server-Side Encryption with Customer-Provided Keys (SSE-C), in which attacker-controlled keys can deny victims access to encrypted objects.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
4 references tracked. Mallory keeps watching after this page renders.
docs.aws.amazon.com
Open sourcedocs.aws.amazon.com
Open sourceelastic.co
Open sourcehalcyon.ai
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Ransomware operators are increasingly integrating native Amazon Web Services (AWS) features, such as S3 buckets, compute snapshots, and cloud backup systems, into their attack toolkits to maximize the impact of their campaigns. Recent research highlights that these groups are not only targeting misconfigured cloud storage but are also leveraging built-in AWS capabilities—like encryption management and key rotation—to delete, overwrite, or render data unrecoverable, often bypassing traditional security controls. The attackers exploit customer-provided keys and other advanced cloud-native mechanisms to assert control over cryptographic protections, making recovery efforts significantly more difficult for victims. Trend Micro researchers have identified at least five distinct ransomware variants that exploit AWS S3 misconfigurations for irreversible data destruction. Security experts note that while S3-focused attacks have been observed for years, the current trend marks a shift toward systematic abuse of cloud-native features for extortion. This evolution in tactics underscores the need for organizations to strengthen cloud security postures, particularly around key management, backup strategies, and monitoring for suspicious use of native cloud services.
Jun 29, 2026
Attackers can exfiltrate data from cloud environments by abusing legitimate cross-account sharing, backup, and replication features instead of moving files over traditional outbound channels. MITRE ATT&CK tracks this behavior as **`T1537` — Transfer Data to Cloud Account**, describing how adversaries use provider APIs and internal cloud networking to make exfiltration resemble normal intra-cloud activity and evade controls focused on internet egress or command-and-control traffic. Research detailing AWS tradecraft shows attackers with snapshot-related permissions can create **Amazon EC2** and **Amazon RDS** snapshots, share them with attacker-controlled AWS accounts, and recover the underlying data without logging back into the original instance or database. Similar abuse is possible in **Amazon S3**, where adversaries can alter replication rules or trigger batch replication jobs to copy bucket contents into external accounts, particularly when overly permissive IAM roles are available. The activity largely occurs through cloud control-plane operations, reducing host-level forensic evidence and increasing the importance of monitoring **CloudTrail**, restricting IAM and KMS permissions, and encrypting sensitive resources.
Aug 15, 2026
A documented AWS attack path shows how an attacker can escalate privileges by combining **SSRF**, exposed EC2 instance credentials, and a misconfigured **CodeBuild** project that reads its `buildspec` from an attacker-writable **S3** bucket. In the reported scenario, the attacker first used Server-Side Request Forgery against an EC2 instance’s **IMDSv1** metadata service to obtain temporary AWS credentials, then enumerated access and found permissions including `codebuild:StartBuild` and `s3:PutObject`. Without needing `iam:PassRole` or permission to modify CodeBuild projects directly, the attacker altered the S3-hosted build specification and triggered a new build, causing arbitrary commands to run on the CodeBuild worker. That execution exposed the worker’s AWS credentials, which inherited the project’s assigned role and in the described case led to a more privileged role with `iam:*` permissions. The technique highlights how cloud misconfigurations can turn limited access into broad account compromise, and underscores mitigations including **least privilege**, tighter S3 and CodeBuild controls, and use of **IMDSv2** to reduce SSRF impact on EC2 instances.
Jul 25, 2026