Storm‑2949: cuando el restablecimiento de contraseña abrió la puerta a toda la nube de Microsoft

En lugar de desplegar malware, el grupo se centró en comprometer cuentas y aprovechar funciones legítimas de la nube. Una vez que obtenían acceso a una identidad —especialmente si pertenecía a un usuario con privilegios— podían utilizar los flujos administrativos normales de Microsoft 365 y Azure para ampliar el acceso dentro del entorno de la organización.

Esto les permitió camuflarse dentro de actividad aparentemente legítima y evitar muchas herramientas de seguridad diseñadas para detectar software malicioso.

El papel del Self‑Service Password Reset (SSPR)

Una pieza clave del ataque fue el abuso del sistema Self‑Service Password Reset (SSPR) de Microsoft Entra, que normalmente permite a los usuarios restablecer su contraseña sin contactar con el equipo de TI.

Los atacantes explotaron este proceso mediante ingeniería social:

• Se hacían pasar por personal interno de soporte o seguridad de TI.
• Contactaban a empleados específicos dentro de la organización.
• Pedían aprobar lo que parecía una verificación rutinaria.

En realidad, esas notificaciones eran solicitudes MFA generadas durante un intento de restablecimiento de contraseña iniciado por el atacante.

Cuando la víctima aprobaba la solicitud, el atacante podía completar el proceso de recuperación de la cuenta.

Después de tomar el control, el atacante podía:

• Cambiar la contraseña de la cuenta.
• Eliminar los métodos de autenticación asociados al usuario legítimo.
• Registrar su propio dispositivo de autenticación (por ejemplo, una instancia de Microsoft Authenticator).

En la práctica, esto bloqueaba al usuario real fuera de su cuenta y dejaba al atacante con acceso persistente protegido por MFA.

De una cuenta comprometida a toda la nube

Una vez dentro, Storm‑2949 comenzó a moverse lateralmente por la infraestructura cloud de la organización.

Las cuentas comprometidas solían pertenecer a usuarios con privilegios elevados, como personal de TI o directivos, lo que abría acceso a múltiples servicios corporativos.

Entre los objetivos del ataque estaban:

• Archivos de SharePoint y OneDrive dentro de Microsoft 365
• Entornos de producción alojados en Azure
• Cuentas de almacenamiento y bases de datos cloud
• Secretos y credenciales guardados en Azure Key Vault

El incidente demuestra una realidad clave de la seguridad en la nube: la identidad funciona como plano de control. Si una identidad con privilegios es comprometida, un atacante puede acceder a numerosos servicios interconectados sin explotar vulnerabilidades de software.

Por qué Microsoft está eliminando la autenticación por SMS

Paralelamente a incidentes como Storm‑2949, Microsoft anunció que dejará de usar códigos SMS para autenticación y recuperación de cuentas personales.

La empresa considera que este método se ha convertido en una fuente importante de fraude y presenta varias debilidades conocidas.

Entre los riesgos más comunes:

• Ataques SIM‑swap, donde el número de la víctima se transfiere a una tarjeta SIM controlada por el atacante
• Intercepción de mensajes en redes de telecomunicaciones
• Ingeniería social para que el usuario revele el código recibido

Como los códigos SMS pueden ser robados o reenviados fácilmente, Microsoft los considera menos seguros que métodos modernos de autenticación sin contraseña.

En su lugar, la compañía impulsa:

• Passkeys basadas en criptografía
• Aplicaciones de autenticación
• Correos electrónicos de recuperación verificados

Estos métodos dependen de credenciales vinculadas a dispositivos o flujos de autenticación más seguros.

Medidas de seguridad recomendadas por Microsoft

El caso Storm‑2949 muestra cómo los ataques basados en identidad pueden evadir muchas defensas tradicionales. Microsoft recomienda varias medidas para reducir este riesgo.

1. Usar MFA resistente al phishing

Las organizaciones deberían adoptar métodos de autenticación que no puedan ser fácilmente engañados mediante ingeniería social, como passkeys o autenticación basada en hardware.

2. Aplicar el principio de mínimo privilegio

El control de acceso basado en roles (RBAC) debe garantizar que cada usuario solo tenga los permisos estrictamente necesarios para su trabajo. Esto limita el impacto si una cuenta es comprometida.

3. Tratar los procesos de recuperación como de alto riesgo

Funciones como SSPR facilitan el soporte a usuarios, pero también pueden convertirse en vectores de ataque si no se supervisan adecuadamente.

4. Monitorizar identidad y operaciones de la nube

Las organizaciones deberían registrar y supervisar eventos como:

• Autenticaciones e identidades
• Restablecimientos de contraseña
• Accesos a datos en Microsoft 365
• Operaciones administrativas en Azure

Esta visibilidad permite detectar comportamientos sospechosos antes de que el ataque escale.

La lección principal: la identidad es la nueva superficie de ataque

Storm‑2949 ilustra un cambio importante en la ciberseguridad moderna. En lugar de explotar vulnerabilidades técnicas o desplegar malware, muchos atacantes se centran ahora en sistemas de identidad y procesos de recuperación de cuentas.

Cuando una identidad con privilegios es comprometida, puede convertirse en la puerta de entrada a todo el ecosistema cloud de una organización. Por eso, reforzar la autenticación, limitar privilegios y vigilar la actividad de identidad se ha convertido en una prioridad crítica para cualquier entorno basado en la nube.