Ataque a Azure Storm-3168: qué ocurrió

Microsoft ha revelado una campaña que rastrea como Storm-3168 en la que los atacantes comprometieron entidades de servicio de Azure, los objetos de identidad que las aplicaciones y los servicios automatizados utilizan para autenticarse en Azure, y usaron ese acceso para eliminar cuentas de almacenamiento. Según el propio relato de Microsoft, la actividad se parece menos a una operación de robo de datos por la fuerza y más a una preparación de ransomware o a una interrupción activa. En particular, Microsoft no ha confirmado que se produjera extorsión o exfiltración de datos en este incidente concreto, aunque las tácticas se asemejan a las primeras fases de un ataque de ransomware.

Esa distinción importa. Eliminar cuentas de almacenamiento puede ser tan dañino como cifrarlas, especialmente si no hay copia de seguridad, pero es un modelo de amenaza distinto al de un atacante que copia archivos en silencio antes de desaparecer. Para las organizaciones que dependen de Azure, la conclusión es que un atacante no necesitaba robar datos para causar un daño grave. Le bastó con tomar el control de la identidad adecuada.

Por qué las entidades de servicio son un objetivo principal

Las entidades de servicio son fáciles de pasar por alto porque no son cuentas de usuario humanas. Son las credenciales que permiten que un servicio o una aplicación de Azure se comunique con otro, a menudo con permisos elevados y una supervisión diaria mínima. Eso las convierte en un objetivo atractivo para los atacantes: compromete una y podrías heredar un acceso amplio a almacenamiento, bases de datos o infraestructura sin tocar nunca la pantalla de inicio de sesión de una persona.

Esto forma parte de un patrón más amplio que los investigadores de seguridad han estado señalando en todo el ecosistema en la nube de Microsoft. Los atacantes van cada vez más tras las credenciales y las relaciones de confianza que están entre bastidores en lugar de atacar directamente a los usuarios finales. Es una lógica similar a campañas como la operación de phishing de voz de Storm-3032 dirigida a dispositivos BYOD para acceder a Microsoft 365, donde el objetivo no es engañar a una persona para que entregue una contraseña en el momento, sino encontrar el eslabón más débil de una cadena de identidad y cabalgar sobre él hasta un entorno mucho mayor.

Una advertencia relacionada: la nota de rescate oculta en una base de datos

Aunque el incidente de Azure Storm-3168 no ha escalado (según lo documentado hasta ahora) a extorsión, un caso aparte reportado por la firma de seguridad Sysdig muestra a dónde puede llevar este tipo de acceso si se deja sin control. En ese incidente, resumido por SOCFortress, un atacante que obtuvo acceso a un entorno de base de datos cifró datos, eliminó tablas de la base de datos y dejó atrás una demanda de rescate. Los investigadores descubrieron que el atacante había creado una tabla llamada README_RANSOM que contenía una dirección de cartera de Bitcoin y un contacto de Proton Mail para negociar el pago.

La actividad de Storm-3168 de Microsoft no llegó a esa fase, pero el paralelismo es instructivo. Ambos casos comenzaron de la misma manera: un atacante se hizo con credenciales o acceso que deberían haber estado estrictamente controlados, y usó ese punto de apoyo para amenazar la integridad de los datos almacenados. Ya sea que el resultado final sea la eliminación, el cifrado o una nota de rescate, la causa raíz es la misma. Alguien entró en una cuenta que no debería haber sido accesible.

Qué significa esto para ti

Si tu organización o tus proyectos personales dependen de Azure o de plataformas en la nube similares, esta campaña es un recordatorio de que la seguridad de identidades, y no solo la defensa perimetral, es donde se ganan o se pierden estos ataques. Aplican algunos pasos prácticos tanto si gestionas infraestructura empresarial como el almacenamiento en la nube de una pequeña empresa:

  • Audita periódicamente los permisos de las entidades de servicio. Muchas organizaciones conceden acceso amplio al configurar la automatización y nunca lo revisan. Reduce los permisos al mínimo necesario.
  • Habilita la autenticación multifactor en todos los lugares donde se admita, incluso para cuentas administrativas y de servicio, no solo para los inicios de sesión de usuarios estándar.
  • Revisa los registros de acceso en busca de patrones de autenticación inusuales, especialmente inicios de sesión desde ubicaciones inesperadas o a horas extrañas vinculados a cuentas de servicio.
  • Haz copias de seguridad de las cuentas de almacenamiento de forma independiente del entorno principal, para que la eliminación o el cifrado no signifiquen una pérdida permanente.
  • Rota las credenciales y los secretos según un calendario, en lugar de dejar las claves de las entidades de servicio válidas indefinidamente.

El robo de credenciales sigue siendo una de las vías más comunes de entrada a entornos en la nube, y una autenticación sólida combinada con una gestión cuidadosa de los accesos hace más para detener estos ataques que cualquier herramienta por sí sola. Usar una VPN para proteger las redes desde las que se conectan tus administradores y el personal remoto añade otra capa, pero funciona mejor junto con una higiene de identidad sólida, no en su lugar.

Conclusiones

El ataque a Azure Storm-3168 demuestra que los atacantes no necesitan exfiltrar datos para causar daño; eliminar cuentas de almacenamiento mediante entidades de servicio comprometidas ya es suficientemente disruptivo por sí solo. Combinado con el detalle de la nota de rescate del caso de Sysdig, es una señal clara de que la gestión de identidades en la nube merece el mismo escrutinio que las organizaciones dedican a los firewalls y a la seguridad de endpoints. Revisar quién y qué tiene acceso a tu almacenamiento en la nube, restringir los permisos y habilitar la autenticación multifactor en todos los tipos de cuenta son pasos prácticos que puedes dar hoy para reducir el riesgo de convertirte en el próximo caso de estudio.