En 2025, el grupo Storm-0501 comprometió organizaciones en entornos Azure sin desplegar un solo archivo de malware en los endpoints. El vector fue una cuenta con privilegios de administrador global en Entra ID. Con ese acceso, el grupo elevó sus permisos sobre todas las suscripciones Azure de la víctima, exfiltró datos masivamente y luego los destruyó junto con los backups — todo usando operaciones nativas de la plataforma. La notificación de extorsión llegó por Microsoft Teams, desde una cuenta comprometida de la propia organización.
No hubo ransomware. Hubo un operador de nube malicioso con credenciales válidas.
Esa distinción importa porque la mayoría de los controles defensivos están diseñados para detectar malware, no para detectar el abuso de accesos legítimos en entornos cloud.
La evolución táctica: de cifrar a destruir
El ransomware tradicional sigue operando — y seguirá haciéndolo — pero en entornos de nube los grupos más avanzados han adoptado una lógica distinta. El cifrado de archivos requiere desplegar código, lo que activa EDR y genera señales en los endpoints. En la nube, hay una alternativa más silenciosa y más efectiva: usar las propias capacidades del proveedor para hacer irrecuperables los datos.
En AWS, eso puede significar eliminar snapshots de RDS y buckets S3 sin versioning activo, o revocar las claves KMS usadas para cifrar los datos almacenados. En Azure, comprometer una cuenta con el rol de Global Administrator permite destruir Key Vaults y eliminar recursos completos a escala. En entornos SaaS, grupos como Scattered Spider demostraron en 2025 que comprometer tokens OAuth de aplicaciones integradas en Salesforce permite "saltar" silenciosamente de un cliente a otro, exfiltrando datos sin que el tráfico levante alertas porque se ve como comunicación legítima entre plataformas.
En 2026, muchos grupos están abandonando el cifrado por completo, optando por extorsión basada exclusivamente en exfiltración de datos. Eso hace que los backups — históricamente la primera línea de recuperación ante ransomware — dejen de ser una defensa suficiente. Si tus datos ya están en manos del atacante, restaurar desde backup no te protege de la presión regulatoria, reputacional y legal que viene con una brecha de datos.
Los vectores que más explotan hoy
IBM X-Force registró en 2025 más de 16 millones de dispositivos infectados con infostealers como Lumma, Acreed y Vidar — malware diseñado para extraer credenciales almacenadas en navegadores, cookies de sesión y tokens de autenticación. Esas credenciales robadas son la materia prima del ransomware en nube: permiten entrar como usuarios legítimos, sin explotar ninguna vulnerabilidad técnica, y sin dejar las huellas que dejaría un malware en un endpoint.
La segunda superficie de ataque que los grupos están explotando activamente son las integraciones SaaS. Cada aplicación que conectas a tu entorno de Microsoft 365, Google Workspace o Salesforce a través de OAuth crea una relación de confianza que, si se compromete en el lado del proveedor externo, permite acceder a tus datos sin pasar por tus controles de identidad. En 2025, grupos como Scattered Lapsus$ Hunters explotaron exactamente esa lógica: en lugar de atacar Salesforce directamente, comprometieron aplicaciones integradas de terceros y usaron los tokens OAuth robados para moverse entre los entornos de los clientes compartidos.
El tercer vector, menos visible pero creciente, es la falta de monitoreo sobre cambios en configuración y permisos de nube. Los atacantes están apuntando al ecosistema de nube — no a su infraestructura subyacente — explotando la acumulación de vulnerabilidades de identidad, configuración y gobernanza no resueltas en servicios interconectados. Un cambio de rol en Entra ID, una política de bucket S3 que se abre inadvertidamente, una nueva clave de API sin restricciones de IP: señales que los controles de nube pueden detectar si están configurados para ello, y que en la mayoría de los entornos pasan sin alertar a nadie.
¿Qué hacer al respecto?
El primer ajuste no es tecnológico: es conceptual. Si tu modelo de recuperación ante ransomware todavía depende principalmente de backups, necesitas revisarlo. Los backups siguen siendo necesarios, pero deben ser inmutables y estar fuera del alcance de las cuentas comprometidas. En AWS, eso significa vault locks en AWS Backup con políticas que impidan su eliminación aunque la cuenta sea comprometida. En Azure, políticas de retención en Recovery Services Vaults con protección de eliminación. Si el atacante puede eliminar tus backups desde la misma cuenta que comprometió, tus backups no son una defensa.
El segundo ajuste es implementar alertas sobre cambios en roles y permisos privilegiados. No es suficiente tener logs: necesitas que alguien revise — o que un sistema alerte — cuando una cuenta recibe el rol de Global Administrator, cuando se elimina un Key Vault, o cuando se crean nuevas instancias en tu entorno de forma inusual. En la mayoría de los proveedores, esas alertas se pueden configurar sin herramientas adicionales.
El tercer ajuste es revisar el inventario de integraciones OAuth activas en tus entornos SaaS. Muchas organizaciones tienen docenas de aplicaciones conectadas que fueron autorizadas por un usuario hace meses y que nadie ha revisado desde entonces. Cada una es una superficie de confianza potencial. Revocar integraciones no utilizadas y revisar los permisos de las activas es trabajo que se puede hacer hoy sin costo adicional.
La pregunta que vale hacerse
Si un atacante comprometiera hoy la cuenta de uno de tus administradores de nube, ¿cuánto tiempo tardarías en detectarlo antes de que llegue a tus datos y tus backups? Si la respuesta supera las pocas horas, la ventana de daño ya es significativa.
Acciones inmediatas
- Revisa quién tiene roles de administrador global o equivalente en tus entornos de nube esta semana. En Entra ID, AWS IAM o GCP IAM, identifica todas las cuentas con privilegios máximos. Cada cuenta con ese nivel de acceso sin MFA habilitado o sin revisión reciente de actividad es un vector activo de riesgo. Menos cuentas privilegiadas con mayor control sobre ellas es la postura correcta.
- Verifica que tus backups de nube tienen protección contra eliminación desde cuentas comprometidas. Activa vault lock en AWS Backup, protección de eliminación en Recovery Services Vaults de Azure, o el equivalente en tu proveedor. Un backup que el atacante puede borrar no es un backup: es una ilusión de resiliencia.
- Configura alertas sobre cambios en roles IAM y eliminación de recursos críticos. En AWS CloudTrail, Microsoft Sentinel o Google Cloud Audit Logs, define alertas para operaciones de alto impacto: asignación de roles de administrador, eliminación de Key Vaults, creación masiva de recursos o cambios en políticas de bucket. Estas alertas son gratuitas y la mayoría de los entornos no las tienen activas.
- Audita las integraciones OAuth activas en tus entornos de Microsoft 365, Google Workspace o Salesforce. Revisa qué aplicaciones de terceros tienen acceso activo y con qué permisos. Revoca las que no se usan o que tienen acceso más amplio del necesario. Es una tarea de una hora que reduce materialmente la superficie de ataque de cadena de suministro SaaS.
- Incluye un escenario de compromiso de cuenta de administrador de nube en tu próximo ejercicio de respuesta a incidentes. Los playbooks de ransomware tradicional (aislar endpoint, restaurar backup) no aplican directamente cuando el vector es una identidad comprometida con privilegios de nube. Practicar ese escenario específico revela brechas de proceso que ningún simulacro genérico detecta.
Si tu organización quiere evaluar su postura de seguridad frente al ransomware en entornos de nube o revisar la resiliencia de sus backups y controles de identidad, podemos ayudarte. Contáctanos en https://tbsek.mx/contacto/.
