La nueva investigación de Trend Research analiza cómo los actores de ransomware están dejando atrás únicamente los entornos on-premise para enfocarse cada vez más en activos cloud, con especial énfasis en Amazon Web Services (AWS) y, en particular, en Amazon S3 como blanco central de extorsión y destrucción de datos.
El análisis desglosa cinco variantes de ransomware contra S3, combina técnicas ya observadas en ataques reales con vectores potenciales que aprovechan malas configuraciones, abuso de cifrado del lado del servidor y claves gestionadas por KMS, y presenta cómo Trend Vision One™ puede ayudar a detectar y responder a estos patrones mediante telemetría de AWS CloudTrail.
De servidores on-premise a S3: el nuevo “territorio” del ransomware
Tradicionalmente, el ransomware explotaba intrusiones de red, phishing y software vulnerable para cifrar archivos en servidores o endpoints. En la nube, el modelo cambia:
los atacantes ya no dependen solo de malware, sino de:
Credenciales filtradas o robadas (IAM users, roles, keys).
Buckets mal configurados y permisos demasiado amplios (s3:PutObject, s3:DeleteObject, kms:Encrypt, etc.).
Uso malicioso de características nativas de AWS (S3, KMS, backups, snapshots) para borrar, sobrescribir, cifrar o exfiltrar datos.
Los principales objetivos señalados por Trend Research son:
Snapshots de cómputo (EBS/EC2): eliminar o cifrar snapshots para impedir recuperación rápida.
Almacenamiento estático (S3): backups, logs, configs, infra-as-code (como archivos Terraform state).
Bases de datos cloud (RDS, Aurora, DynamoDB): impacto directo en datos sensibles, cumplimiento y continuidad de negocio.
Imágenes y registros de contenedores (ECR): detener pipelines CI/CD o inyectar imágenes maliciosas.
Sistemas de backup y DR (S3, Glacier, AWS Backup): borrar o corromper el “último recurso” de recuperación.
Entre todos, S3 se mantiene como el objetivo más atractivo, tanto por su uso masivo como por su rol en respaldos, datos de producción y artefactos críticos.
Cómo piensan los atacantes: el “blueprint” del ransomware en S3
Antes de ejecutar el ataque, el adversario busca buckets que cumplan estas condiciones:
Sin versioning: no hay rollback a versiones previas.
Sin Object Lock: es posible sobrescribir o borrar libremente.
Sin MFA Delete: borrado definitivo sin segundo factor.
Con permisos de escritura mal diseñados: políticas con
*, roles mal configurados, credenciales filtradas.Con datos de alto valor: backups, dumps de BD, configs, código propietario.
El objetivo final es claro: hacer que los datos sean ilegibles e irrecuperables, y luego presionar con una demanda de rescate.
Cinco variantes de ransomware contra S3
Trend Research describe cinco variantes (algunas ya vistas en ataques reales, otras como escenarios plausibles):
Variante 1 – Abuso de SSE-KMS con claves por defecto
El atacante obtiene acceso de escritura a buckets S3.
Crea una CMK en KMS en otra cuenta (world-readable) y cifra los objetos con esa clave.
Programa la eliminación de la CMK en 7 días, imponiendo un “deadline” antes de que la clave desaparezca.
Deja una ransom note e impide la recuperación cuando la clave se destruye.
Es un vector factible, pero menos probable en la vida real por el tiempo de gracia de KMS, donde AWS soporte aún podría intervenir.
Variante 2 – Uso malicioso de cifrado SSE-C (clave proporcionada por el cliente)
Basado en el caso real del actor Codefinger:
El atacante cifra objetos S3 usando SSE-C con su propia clave AES-256.
AWS no almacena la clave, solo un HMAC en CloudTrail que no sirve para descifrar.
Una vez cifrados los datos, el atacante deja la nota de rescate.
Este escenario es altamente realista: ni el cliente ni AWS pueden recuperar los datos sin la clave del atacante.
Trend propone políticas explícitas para bloquear SSE-C a nivel de:
Resource Control Policy (RCP) / AWS Organizations.
Bucket policies específicas, denegando
s3:PutObjectcuando se use SSE-C.
Variante 3 – Exfiltración y borrado (Bling Libra)
Ya observado en ataques reales:
El atacante exfiltra todos los datos de un bucket S3.
Después, borra los objetos o el bucket completo.
Finalmente extorsiona a la víctima con amenaza de filtración y destrucción permanente.
Es simple, efectivo y difícil de revertir, incluso con apoyo de AWS, cuando no hay versioning ni backups externos.
Variante 4 – Uso de material de clave externo en KMS (BYOK)
Escenario avanzado:
El atacante recurre a KMS con Import Key Material, trayendo su propia clave externa.
Configura expiraciones cortas para que el key material se destruya rápido.
Usa esa CMK para cifrar datos de S3 y luego deja expirar la clave.
Resultado: datos cifrados con una clave que ya no existe ni en AWS ni en manos del cliente.
Mitigación: políticas IAM que nieguen kms:GenerateDataKey y kms:Decrypt cuando kms:KeyOrigin sea EXTERNAL o EXTERNAL_KEY_STORE y el servicio sea S3.
Variante 5 – Abuso de External Key Store (XKS)
Escenario aún teórico, pero factible:
El atacante monta un XKS proxy propio (por ejemplo, vía Docker + ngrok).
Configura un key store externo y lo integra con AWS KMS.
Usa ese key store para cifrar datos en S3, quedando las claves fuera del control de AWS.
Otra vez, si el atacante controla el key store externo, puede cortar el acceso a las claves y dejar los datos irrecuperables.
Cómo ayuda Trend Vision One™ frente a ransomware en S3
La plataforma Trend Vision One™ se apalanca de AWS CloudTrail y otros logs para detectar patrones específicos de estas variantes y actividades relacionadas, por ejemplo:
Workbenches específicos de variantes
AWS Possible S3 Ransomware Activity Detected (Variantes 1, 4, 5): cifrado sospechoso que podría causar pérdida de datos.
AWS S3 Object Upload Using Custom Encryption (Variante 2): uso de cifrado no estándar (SSE-C u otros) en S3.
AWS S3 Data Encrypted with Imported Key and Key Material Deleted (Variante 4).
AWS S3 Potential Ransomware Activity via Bulk Download and Deletion (Variante 3): gran volumen de descargas seguido de borrados masivos.
Detecciones genéricas en S3
Incluye modelos para:
Enumeración exitosa o fallida de buckets.
Subida de posibles notas de ransomware.
Cambios en cifrado, políticas, acceso público, borrado de buckets, deshabilitar logs de acceso, descargas sospechosas de archivos de credenciales, etc.
Detecciones IAM críticas (pre-ransomware)
Antes de llegar a S3, los atacantes tocan IAM:
Adjuntar AdministratorAccess a usuarios, roles o grupos.
Crear/actualizar políticas inline con privilegios totales.
Desactivar MFA, crear nuevas access keys, modificar trust policies para backdoor.
Trend Vision One resalta este tipo de cambios como indicadores tempranos de un compromiso que puede terminar en ransomware en S3.
Postura de riesgo en S3 (Cloud Risk Management)
Trend Vision One Cloud Risk Management incluye más de 28 reglas específicas para S3 (S3-001 a S3-028), entre ellas:
S3-013: Verificar que MFA Delete esté habilitado en buckets críticos.
S3-023: Comprobar Object Lock para evitar sobrescrituras.
S3-025: Detectar uso de SSE-C, reconocido como vector de ransomware.
S3-026: Garantizar Block Public Access activo.
S3-015: Detectar patrones sospechosos de acceso cross-account.
Buenas prácticas para defender S3 frente a ransomware
La investigación cierra con un set de recomendaciones que aplican directo a cualquier organización con AWS:
Aplicar mínimo privilegio: limitar
s3:PutObject,s3:DeleteObjecty operaciones KMS a roles bien definidos.Gobernanza estricta de KMS: restringir keys externas/importadas y separar rol de administradores de claves vs. dueños de datos.
Inmutabilidad en S3: habilitar versioning y Object Lock en buckets críticos.
MFA Delete en buckets sensibles: segunda capa antes de borrados o cambios de versioning.
Bloquear acceso público: activar S3 Block Public Access y restringir acceso por VPC endpoints o access points privados.
Evitar cifrado débil o no gobernado: limitar o deshabilitar SSE-C; preferir SSE-KMS con monitoreo en KMS.
Monitoreo unificado y detección temprana: revisar CloudTrail, S3 Data Events y logs de KMS para detectar patrones anómalos.
Respaldos aislados: replicación cross-account con claves separadas y protección de borrado.
Pruebas de restauración periódicas y revisión de IAM/KMS para detectar “privilege creep”.
Respuesta automatizada: playbooks para revocar credenciales, deshabilitar claves KMS sospechosas y aislar recursos afectados.
