En incidentes cloud-native el patrón más dañino no es exfiltrar y cifrar “fuera”, sino convertir tu propia plataforma en el mecanismo de denegación: snapshots que pasan a ser inútiles, objetos en S3 que quedan inaccesibles o reemplazados, y un KMS “legítimo” que sigue auditando todo como si fuera operación normal. El resultado en empresa es el mismo que en on‑prem, pero con una particularidad: muchas acciones del atacante se ejecutan con credenciales válidas y APIs estándar.
El foco aquí es concreto: cómo se produce el secuestro mediante cifrado de snapshots y S3, especialmente cuando el atacante abusa de tu KMS, y por qué el versionado y la inmutabilidad (Object Lock) son de los pocos frenos que siguen funcionando cuando ya han comprometido permisos.
Superficie de ataque: cuando KMS se convierte en el “cómplice” involuntario
En cloud, el cifrado no es un detalle técnico: es un control de acceso. Si un atacante logra operar sobre KMS (crear claves, modificar key policies, revocar grants o reconfigurar el uso de claves), puede forzar que datos y copias queden cifrados de una forma que tu organización ya no puede descifrar. No necesita “romper” el cifrado; le basta con cambiar quién puede usarlo.
En la práctica corporativa esto aparece tras el compromiso de un rol con permisos amplios (DevOps, automatización, break-glass mal gobernado) o por abuso de cadenas de asunción de roles. La señal peligrosa es que los eventos parecen legítimos: llamadas a kms:CreateKey, kms:PutKeyPolicy, kms:DisableKey o kms:ScheduleKeyDeletion desde identidades que tu entorno ya conoce. Cuando esto impacta a snapshots y S3, el daño se multiplica porque suele tocar datos “de recuperación”, no solo producción.
Escenario típico: snapshots cifrados que ya no puedes restaurar
En EC2/EBS, los snapshots son el salvavidas operativo… hasta que dejan de ser restaurables. El atacante no necesita cifrar cada snapshot “a mano”; puede inducir condiciones que provoquen que los siguientes snapshots (o copias de snapshots entre cuentas/regiones) queden cifrados con una CMK bajo su control, o puede romper el acceso a la CMK que cifra snapshots existentes (por ejemplo, endureciendo la key policy para excluir a tus roles de recuperación).
El impacto real en empresa suele aparecer en el peor momento: durante la restauración. El equipo de respuesta ejecuta el runbook, intenta crear un volumen desde snapshot y recibe errores de autorización KMS. A nivel de continuidad, eso convierte un RTO asumible en un corte prolongado porque tus backups “existen”, pero no son utilizables. Además, si el atacante programa la eliminación de la clave (o la deshabilita), incluso un equipo con buen control de snapshots puede quedarse sin ventana de recuperación.
- Cambio de key policy o grants: el snapshot sigue ahí, pero el principal que restaura ya no tiene
kms:Decryptokms:CreateGrant. Operativamente se traduce en tickets de “AWS no me deja restaurar” y horas perdidas revisando IAM, cuando el bloqueo está en KMS.
Una práctica que he visto fallar es asumir que “si tengo snapshots, estoy cubierto”. En cloud, la dependencia crítica no es el snapshot, es la capacidad de usar la clave correcta para materializarlo en un volumen. Si esa capacidad se secuestra, el snapshot es un archivo muerto.
S3 bajo ransomware cloud-native: cifrado, reemplazo de objetos y extorsión operativa
En S3 el atacante tiene dos caminos habituales para lograr el mismo efecto: reemplazar el contenido (subir versiones cifradas/alteradas) o bloquear el acceso mediante cifrado y políticas. Con permisos suficientes, puede escribir objetos “cifrados” con su esquema (por ejemplo, cifrando localmente antes de subir) o forzar cambios de comportamiento mediante configuraciones de bucket y KMS que degradan el acceso. En ambos casos, tu aplicación sigue apuntando al bucket, pero los datos ya no son los esperados.
La consecuencia empresarial no siempre es una caída total inmediata; a veces es más difícil: corrupción silenciosa de datos, procesos batch que “terminan bien” pero con entradas incorrectas, o pipelines de analítica que se alimentan de objetos sustituidos. Y cuando intentas volver atrás, descubres que el atacante también limpió versiones o impidió que tú lo hagas, según qué controles tenga o no tenga tu bucket.
- Sin versionado: un
PUTmalicioso reemplaza el objeto y tu “backup” depende de sistemas externos. En incidentes reales, esto suele terminar en restauraciones parciales desde otros repositorios, con pérdida de trazabilidad. - Con versionado pero sin inmutabilidad: hay historial, pero un actor con permisos puede borrar versiones (incluidas no-current) y vaciar el bucket. El versionado ayuda, pero no es un freno suficiente frente a credenciales comprometidas.
- Con Object Lock (WORM): el atacante puede subir versiones nuevas, pero no puede eliminar ni sobrescribir el pasado dentro de la ventana de retención. Esto cambia la dinámica: sigues teniendo un punto de recuperación verificable.
Object Lock no “evita el ransomware”; evita que el atacante convierta tu almacenamiento en una pizarra reescribible. En corporaciones con requisitos de continuidad, esa diferencia es la que determina si el plan de recuperación es viable o te quedas negociando.
Cómo hacerlo en la práctica: guardrails operativos en KMS, snapshots y S3
La defensa efectiva aquí se diseña asumiendo credenciales comprometidas. Eso significa reducir al mínimo quién puede alterar KMS y poner barreras en S3 que no dependan de “portarse bien” con IAM. En operaciones reales, lo que funciona es separar responsabilidades: roles que consumen datos no deberían poder reconfigurar el cifrado; y los roles que administran KMS deberían ser escasos, auditados y con fricción (MFA, break-glass controlado).
Acciones concretas que puedes ejecutar y verificar:
- Crear una CMK dedicada para backups/snapshots y limitar su administración: usa una key policy que permita uso (Encrypt/Decrypt) a los servicios/roles necesarios, pero restrinja administración (PutKeyPolicy, ScheduleKeyDeletion, DisableKey) a un conjunto mínimo. Después valida en AWS KMS > Key > “Key policy” que no existan principales amplios (por ejemplo,
"AWS": "*") ni permisos de administración delegados a roles de automatización. - Habilitar versionado en buckets críticos y activar Object Lock donde el riesgo lo justifique: Object Lock requiere configuración explícita del bucket y un modo (Governance/Compliance) con retención. Valida en S3 > Bucket > “Properties” que Versioning está “Enabled” y que Object Lock está activo con una política de retención acorde a tu RPO/RTO. La verificación debe incluir una prueba: intentar borrar una versión protegida con un rol con permisos elevados y confirmar que falla por retención.
Ejemplo de control IAM útil para reducir daño (ilustrativo; debes adaptarlo a tus ARNs y modelo): denegar acciones destructivas sobre KMS salvo a un rol break-glass. Este tipo de deny by default evita que un rol comprometido “administre” la clave aunque tenga permisos amplios en otras capas.
{
"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"
}
}
}
]
}
La validación no se queda en “la policy existe”: revisa CloudTrail (o Lake/athena) buscando intentos denegados sobre esas acciones desde roles no autorizados, porque eso te confirma que el guardrail está realmente interponiéndose ante movimientos laterales o abuso de automatización.
Recomendaciones para entornos corporativos
El ransomware cloud-native que impacta snapshots y S3 suele apoyarse en un hecho incómodo: el atacante no necesita herramientas especiales si puede usar tu KMS, tus roles y tus APIs. Por eso, la protección real no es “más cifrado”, sino gobernar quién puede cambiar las reglas del cifrado y asegurar que existen copias que no se puedan borrar ni reescribir dentro de la ventana necesaria para recuperarte.
En snapshots, el riesgo operativo clave es tener copias que existen pero no se pueden materializar por bloqueo en KMS. En S3, el diferencial suele ser versionado + Object Lock: sin inmutabilidad, una identidad comprometida puede borrar el histórico; con inmutabilidad, puedes volver a un estado anterior incluso si el atacante subió contenido cifrado o corrupto.
Si solo puedes priorizar dos cosas, que sean estas: limitar de forma agresiva la administración de KMS (key policies e IAM con denegaciones explícitas) y establecer inmutabilidad en S3 para datos de recuperación. Eso reduce la probabilidad de quedar “rehén” de tu propio cifrado cuando más lo necesitas.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.