In cloud-native incidents, the most damaging pattern is not exfiltrating and encrypting “outside”, but turning your own platform into the denial mechanism: snapshots that become useless, objects in S3 that become inaccessible or replaced, and a “legitimate” KMS that keeps auditing everything as if it were normal operation. The result for the company is the same as on‑prem, but with one particularity: many attacker actions are executed with valid credentials and standard APIs.
The focus here is specific: how hijacking occurs through encryption of snapshots and S3, especially when the attacker abuses your KMS, and why versioning and immutability (Object Lock) are among the few brakes that keep working when permissions have already been compromised.
Attack surface: when KMS becomes the involuntary “accomplice”
In the cloud, encryption is not a technical detail: it is an access control. If an attacker manages to operate on KMS (create keys, modify key policies, revoke grants, or reconfigure key usage), they can force data and copies to end up encrypted in a way your organization can no longer decrypt. They don’t need to “break” encryption; it’s enough to change who can use it.
In corporate practice this shows up after the compromise of a role with broad permissions (DevOps, automation, poorly governed break-glass) or via abuse of role-assumption chains. The dangerous signal is that the events look legitimate: calls to kms:CreateKey, kms:PutKeyPolicy, kms:DisableKey or kms:ScheduleKeyDeletion from identities your environment already knows. When this impacts snapshots and S3, the damage multiplies because it usually touches “recovery” data, not just production.
Typical scenario: encrypted snapshots you can no longer restore
In EC2/EBS, snapshots are the operational lifeline… until they stop being restorable. The attacker doesn’t need to encrypt each snapshot “by hand”; they can induce conditions that cause subsequent snapshots (or copies of snapshots across accounts/regions) to be encrypted with a CMK under their control, or they can break access to the CMK that encrypts existing snapshots (for example, by tightening the key policy to exclude your recovery roles).
The real impact in the company usually appears at the worst time: during restoration. The response team runs the runbook, tries to create a volume from a snapshot, and gets KMS authorization errors. From a continuity perspective, that turns an acceptable RTO into a prolonged outage because your backups “exist”, but are not usable. In addition, if the attacker schedules deletion of the key (or disables it), even a team with good snapshot control can end up without a recovery window.
- Key policy or grants change: the snapshot is still there, but the restoring principal no longer has
kms:Decryptorkms:CreateGrant. Operationally this translates into tickets like “AWS won’t let me restore” and hours lost reviewing IAM, when the block is in KMS.
One practice I’ve seen fail is assuming that “if I have snapshots, I’m covered”. In the cloud, the critical dependency is not the snapshot, it is the ability to use the correct key to materialize it into a volume. If that ability is hijacked, the snapshot is a dead file.
S3 under cloud-native ransomware: encryption, object replacement, and operational extortion
In S3 the attacker has two common paths to achieve the same effect: replace the content (upload encrypted/altered versions) or block access via encryption and policies. With sufficient permissions, they can write “encrypted” objects with their scheme (for example, encrypting locally before upload) or force behavior changes via bucket configurations and KMS that degrade access. In both cases, your application still points to the bucket, but the data is no longer what is expected.
The business consequence is not always an immediate total outage; sometimes it is harder: silent data corruption, batch processes that “finish fine” but with incorrect inputs, or analytics pipelines that feed on substituted objects. And when you try to roll back, you discover the attacker also cleaned up versions or prevented you from doing so, depending on which controls your bucket has or doesn’t have.
- Without versioning: a malicious
PUTreplaces the object and your “backup” depends on external systems. In real incidents, this usually ends in partial restores from other repositories, with loss of traceability. - With versioning but without immutability: there is history, but an actor with permissions can delete versions (including non-current) and empty the bucket. Versioning helps, but it is not a sufficient brake against compromised credentials.
- With Object Lock (WORM): the attacker can upload new versions, but cannot delete or overwrite the past within the retention window. This changes the dynamics: you still have a verifiable recovery point.
Object Lock doesn’t “prevent ransomware”; it prevents the attacker from turning your storage into a rewritable whiteboard. In corporations with continuity requirements, that difference is what determines whether the recovery plan is viable or you end up negotiating.
How to do it in practice: operational guardrails in KMS, snapshots, and S3
Effective defense here is designed assuming compromised credentials. That means minimizing who can alter KMS and putting barriers in S3 that don’t depend on “behaving” with IAM. In real operations, what works is separating responsibilities: roles that consume data should not be able to reconfigure encryption; and roles that administer KMS should be few, audited, and have friction (MFA, controlled break-glass).
Concrete actions you can execute and verify:
- Create a dedicated CMK for backups/snapshots and restrict its administration: use a key policy that allows use (Encrypt/Decrypt) to the necessary services/roles, but restricts administration (PutKeyPolicy, ScheduleKeyDeletion, DisableKey) to a minimal set. Then validate in AWS KMS > Key > “Key policy” that there are no broad principals (for example,
"AWS": "*") nor administration permissions delegated to automation roles. - Enable versioning on critical buckets and enable Object Lock where the risk justifies it: Object Lock requires explicit bucket configuration and a mode (Governance/Compliance) with retention. Validate in S3 > Bucket > “Properties” that Versioning is “Enabled” and that Object Lock is active with a retention policy aligned to your RPO/RTO. Verification must include a test: attempt to delete a protected version with a role with elevated permissions and confirm it fails due to retention.
Example of a useful IAM control to reduce damage (illustrative; you must adapt it to your ARNs and model): deny destructive actions on KMS except to a break-glass role. This kind of deny by default prevents a compromised role from “administering” the key even if it has broad permissions in other layers.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyKMSAdminExceptBreakGlass",
"Effect": "Deny",
"Action": [
"kms:DisableKey",
"kms:ScheduleKeyDeletion",
"kms:PutKeyPolicy",
"kms:UpdateKeyDescription",
"kms:CreateAlias",
"kms:DeleteAlias"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/security-breakglass"
}
}
}
]
}
Validation doesn’t stop at “the policy exists”: review CloudTrail (or Lake/athena) looking for denied attempts on those actions from unauthorized roles, because that confirms the guardrail is really getting in the way of lateral movement or automation abuse.
Recommendations for corporate environments
Cloud-native ransomware that impacts snapshots and S3 often relies on an uncomfortable fact: the attacker doesn’t need special tools if they can use your KMS, your roles, and your APIs. That’s why real protection is not “more encryption”, but governing who can change the rules of encryption and ensuring that there are copies that cannot be deleted or rewritten within the window needed to recover.
With snapshots, the key operational risk is having copies that exist but cannot be materialized due to a block in KMS. In S3, the differentiator is usually versioning + Object Lock: without immutability, a compromised identity can delete history; with immutability, you can roll back to a prior state even if the attacker uploaded encrypted or corrupted content.
If you can only prioritize two things, let them be these: aggressively limit KMS administration (key policies and IAM with explicit denials) and establish immutability in S3 for recovery data. That reduces the probability of being held “hostage” by your own encryption when you need it most.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.