Las bandas de vishing usan teléfonos personales para acceder a Microsoft 365 sin tocar los dispositivos corporativos

Los actores de amenazas están llamando y enviando mensajes de texto a empleados en sus teléfonos personales, haciéndose pasar por personal interno de TI para capturar identidades y sesiones de autenticación de Microsoft 365. Una vez dentro, utilizan interfaces legítimas en la nube para mapear los entornos corporativos y extraer datos discretamente de SharePoint, OneDrive y Exchange.

La actividad se comunicó el 10 de septiembre de 2026. Microsoft lleva vigilando estas campañas dirigidas contra dispositivos personales desde mayo y sigue la pista de sus operadores como Storm-3032 y Storm-3121.

La técnica es especialmente peligrosa porque la primera fase tiene lugar fuera del alcance de muchos controles de seguridad corporativos. Los atacantes no necesitan necesariamente comprometer un portátil administrado, desplegar malware ni enviar un mensaje a través del sistema de correo de la empresa.

En su lugar, explotan la confianza del empleado.

El ataque comienza fuera del perímetro corporativo

Entre los objetivos hay ejecutivos, administradores y empleados con privilegios elevados en Microsoft 365. Estas cuentas pueden dar acceso a más usuarios, grupos, sitios, aplicaciones, permisos, comunicaciones y archivos empresariales que una identidad de un empleado ordinario.

El atacante contacta con el número de móvil personal del objetivo mediante una llamada de voz o un mensaje de texto. El interlocutor se hace pasar por el servicio de asistencia de la organización y afirma que el empleado debe actualizar una configuración de autenticación o, de lo contrario, podría perder el acceso a los servicios de trabajo.

Los pretextos habituales incluyen:

• Registrar o sustituir una passkey
• Cambiar una configuración de MFA
• Actualizar la configuración de inicio de sesión único
• Restablecer un acceso a la cuenta supuestamente interrumpido

A continuación, la víctima recibe un enlace que conduce a una página de inicio de sesión de Microsoft falsificada. Los dominios maliciosos pueden combinar el nombre del empleador con términos relacionados con la autenticación, siguiendo patrones como company[.]add-passkey[.]com.

La campaña puede utilizar un sistema de phishing de adversary-in-the-middle, o AiTM, para interceptar credenciales y tokens de sesión autenticados. También puede abusar de la device-code authentication, convenciendo a la víctima para que autorice una sesión que el atacante inició en otro lugar.

En un número menor de casos, los operadores utilizan una cuenta de empleado comprometida para contactar con otro trabajador. Los mensajes procedentes de una identidad interna conocida pueden hacer que la solicitud de autenticación parezca más creíble.

Es posible que el propio teléfono no se vea comprometido. El ataque tiene éxito porque el usuario sigue instrucciones fraudulentas y completa una acción de autenticación legítima para la persona equivocada.

Por qué BYOD crea una brecha de monitorización

Es posible que las pasarelas de correo corporativo, las plataformas de detección y respuesta para endpoints y los controles de navegador administrado nunca vean el señuelo original. La llamada o el mensaje de texto llega a un dispositivo personal que no está registrado en el conjunto de herramientas de seguridad de la organización.

Esto deja a los investigadores ante un punto de partida complicado. Las primeras pruebas pueden consistir en el recuerdo de un empleado sobre una conversación telefónica o un mensaje de texto, en lugar de un correo conservado, una alerta del endpoint o un archivo adjunto capturado.

A partir de ahí, los equipos de respuesta deben relacionar ese informe con los eventos posteriores de identidad y de la nube. La telemetría relevante incluye:

• Inicios de sesión inusuales
• Intentos de autenticación mediante device code
• Uso de tokens desde ubicaciones o clientes inesperados
• Cambios en los métodos de autenticación registrados
• Registro de nuevos dispositivos MFA
• Enumeración de Microsoft Graph
• Acceso a SharePoint, OneDrive o Exchange
• Descargas pequeñas y repetidas desde repositorios en la nube

Después de hacerse con el control de una identidad, el atacante puede registrar un dispositivo MFA bajo su control. Este paso proporciona persistencia y puede hacer que los accesos posteriores parezcan más coherentes con el uso normal de la cuenta.

Una prohibición general de las modalidades bring-your-own-device no resolvería por completo el problema. La debilidad reside principalmente en los flujos de autenticación, los permisos de las cuentas y la confianza del usuario, no en el malware que se ejecuta en el teléfono del empleado.

Microsoft Graph convierte una identidad robada en una herramienta de reconocimiento

Tras autenticarse, se ha observado que Storm-3032 y Storm-3121 utilizan la Microsoft Graph API para inspeccionar los entornos de Microsoft 365. Graph es una interfaz programática estándar, por lo que los atacantes no necesitan instalar utilidades de reconocimiento dentro de la red corporativa.

Según los permisos de la identidad comprometida, las solicitudes a Graph pueden revelar:

• Usuarios y grupos
• Sitios de SharePoint
• Aplicaciones y otros recursos
• Ubicaciones de contenido
• Derechos de acceso y relaciones de permisos
• Otros detalles de configuración de Microsoft 365

Las solicitudes a endpoints como /users, /groups y /sites no son intrínsecamente maliciosas. Las empresas y las aplicaciones autorizadas las utilizan habitualmente, lo que limita el valor de las alertas basadas en una sola llamada a la API.

Lo importante es el patrón, no el endpoint.

Un usuario o una aplicación que de repente consulte muchas partes del entorno, siga una secuencia inusual de solicitudes de enumeración o combine el reconocimiento con una actividad de autenticación sospechosa merece una investigación. Las líneas base deben tener en cuenta la función de cada identidad, ya que una actividad normal de Graph para una cuenta de automatización puede ser muy anómala en el caso de un ejecutivo.

Los atacantes utilizan este inventario para identificar archivos, mensajes y vías de acceso valiosos. Microsoft ha observado el robo de datos de SharePoint, OneDrive y Exchange, así como de otros repositorios de Microsoft 365.

La exfiltración está diseñada para pasar desapercibida. En lugar de descargar un archivo grande de una sola vez, los actores recuperan pequeños lotes periódicamente durante un periodo prolongado. Esto puede eludir los umbrales centrados en volúmenes de transferencia repentinos y, al mismo tiempo, mezclarse con el uso habitual de la nube.

Los intermediarios de acceso pueden entregar las cuentas a grupos de extorsión

Microsoft considera que los operadores podrían vender o transferir el acceso obtenido a grupos de extorsión posteriores, entre ellos ShinyHunters. Sin embargo, hasta ahora no se ha atribuido directamente ninguna brecha corporativa conocida a ninguna de estas campañas de acceso inicial.

Esta distinción limita las conclusiones que pueden extraerse en este momento. La actividad observada demuestra que existe una vía viable para el reconocimiento, el acceso persistente y el robo de datos, pero no prueba que Storm-3032 o Storm-3121 hayan provocado una intrusión concreta conocida públicamente.

El posible impacto empresarial sigue siendo considerable. Una identidad comprometida de administrador o ejecutivo podría exponer comunicaciones internas, documentos confidenciales, relaciones organizativas y configuraciones de seguridad. El acceso también podría facilitar una extorsión posterior si la información robada se utiliza para presionar a la empresa víctima.

No se trata de una vulnerabilidad de software. No existe ningún CVE asociado, versión de producto afectada, parche de seguridad ni fecha límite de CISA Known Exploited Vulnerabilities. La campaña abusa de la ingeniería social, las funciones de autenticación válidas, los permisos excesivos y las carencias de monitorización en la nube.

La información de Microsoft sobre estos hallazgos describe las campañas como una amenaza en la capa de identidad, no como un compromiso que requiera controlar un endpoint corporativo.

Las defensas deben seguir la identidad entre dispositivos y servicios en la nube

La recomendación central de Microsoft es exigir MFA resistente al phishing en cada inicio de sesión. Cuando se aplica correctamente al usuario objetivo, debería impedir esta cadena de ataque, en lugar de limitarse a generar una solicitud adicional que el interlocutor pueda convencer a la víctima de aprobar.

Las organizaciones también deberían bloquear la device-code authentication allí donde no exista una necesidad operativa documentada. Si algunos flujos la requieren, las políticas de Conditional Access deben restringir quién puede utilizarla, desde qué dispositivos y en qué condiciones.

Otras medidas prioritarias son:

1. Restringir las aplicaciones sensibles a dispositivos administrados. Aplique este control cuando el valor de los datos justifique el coste operativo.
2. Reducir los permisos de Microsoft Graph. Los usuarios y las aplicaciones deben recibir únicamente los ámbitos necesarios para sus funciones.
3. Monitorizar los cambios en los métodos de autenticación. Los nuevos registros de MFA posteriores a llamadas, mensajes de texto o inicios de sesión inusuales deben someterse a una revisión inmediata.
4. Correlacionar la telemetría de identidad y de la nube. Los eventos de device code, la actividad de tokens, las consultas de Graph y las descargas son más reveladores cuando se analizan conjuntamente.
5. Detectar la exfiltración de bajo volumen. La monitorización debe examinar el acceso acumulado y repetido, no solo las transferencias individuales de gran tamaño.
6. Revisar las cuentas privilegiadas. El principio de mínimo privilegio reduce la cantidad de información y contenido disponibles después de que se comprometa una identidad.
7. Establecer un proceso de verificación para el servicio de asistencia. Los empleados necesitan un canal de confianza para confirmar solicitudes inesperadas relacionadas con passkeys, MFA o SSO.

La formación debe centrarse en una regla clara: un interlocutor no solicitado nunca debe indicar a un empleado que se autentique mediante un enlace enviado a su teléfono personal. Los usuarios deben finalizar la interacción y ponerse en contacto con TI a través de un número interno o un portal conocidos.

Cortar la llamada es solo la primera capa. Los equipos de defensa también deben asumir que algunos empleados seguirán las instrucciones y crear controles capaces de contener el compromiso de identidad resultante antes de que el reconocimiento mediante Graph se convierta en un robo de datos prolongado.