El phishing mediante código de dispositivo que afectó a 340 organizaciones

Un empleado abre un correo electrónico sobre un archivo compartido o una factura vencida. El mensaje incluye un enlace a microsoft.com/devicelogin, el sitio real de Microsoft, y un código corto para introducir. El empleado escribe el código, completa su propia autenticación multifactor y continúa con su jornada.

Nada en el proceso parece sospechoso, porque nada es falso. Cada paso se ejecuta en la propia infraestructura de Microsoft. Lo que el empleado desconoce es que el código proviene de un atacante y que, al aprobarlo, ha entregado una sesión activa en lugar de acceder a un archivo compartido.

Qué explota el phishing mediante códigos de dispositivo

La concesión de autorización de dispositivo OAuth 2.0, definida en el RFC 8628, fue creada para dispositivos sin teclado: televisores inteligentes, sistemas de salas de conferencias y herramientas de línea de comandos. El dispositivo muestra un código y el usuario lo introduce en un segundo dispositivo, en microsoft.com/devicelogin, para vincular ambos.

El diseño asume que la persona que solicita el código y la que lo aprueba son la misma. Los atacantes rompen esta premisa: ellos mismos solicitan el código, lo envían a un objetivo con un pretexto y esperan.

Cuando el objetivo introduce el código y completa su propia autenticación multifactor, el token de sesión resultante se envía al sistema del atacante, no al del objetivo.

Una campaña que se extendió por cinco continentes

Más de 340 organizaciones de Microsoft 365 en Estados Unidos, Canadá, Australia, Nueva Zelanda y Alemania fueron atacadas. Los investigadores detectaron la campaña por primera vez el 19 de febrero de 2026 (The Hacker News, 25 de marzo de 2026). Posteriormente, se extendió a organizaciones en América, Europa, Oriente Medio, Asia y Oceanía.

Los sectores de la construcción, organizaciones sin ánimo de lucro, inmobiliarias, manufactura, servicios financieros, salud, legal y organismos gubernamentales fueron los más afectados. Los investigadores atribuyen el origen de la técnica a un grupo identificado como Storm-2372. Las oleadas posteriores provinieron de otros actores que utilizaron kits de phishing comerciales, lo que puso esta técnica al alcance de atacantes sin grandes conocimientos técnicos.

Una investigación de seguimiento sobre la misma actividad reveló un patrón de seis etapas, desde el reconocimiento hasta la persistencia. Los atacantes primero confirmaban qué cuentas eran válidas y luego enviaban correos electrónicos de phishing con pretextos que iban desde facturas hasta archivos compartidos, algunos redactados con IA generativa adaptada al puesto del objetivo. El código del dispositivo se generaba en el momento en que la víctima hacía clic, por lo que permanecía válido el tiempo suficiente para que actuaran. Los atacantes comprobaban repetidamente si el inicio de sesión se había completado.

Una vez dentro, configuraban reglas ocultas en la bandeja de entrada, registraban nuevos dispositivos e identificaban perfiles de alto valor dentro de la cuenta: finanzas, ejecutivos y administradores.

Por qué la autenticación multifactor no lo detiene

La autenticación multifactor funcionó exactamente como estaba diseñada en esta campaña. La víctima introdujo una contraseña si era necesario, aprobó una solicitud o introdujo un código de un solo uso, y su identidad fue confirmada.

La MFA no falló técnicamente. La víctima aprobó una sesión que no era la suya.

Esa distinción es importante. Una vulnerabilidad se puede parchear, pero una suposición de confianza debe desaprenderse, empleado por empleado.

El phishing mediante códigos de dispositivo se suma a un patrón que ya hemos observado: llamadas de vishing que capturaban códigos MFA en tiempo real y transferencias bancarias aprobadas después de que la MFA superara todos los controles. En cada caso, la tecnología funcionó correctamente. La persona que autorizó la acción no sabía qué estaba autorizando.

La brecha de formación que esto expone

La mayoría de la formación en concienciación sobre seguridad enseña a los empleados a detectar una página de inicio de sesión falsa: un dominio incorrecto, la falta de un candado o una URL que casi coincide con la real. El phishing mediante códigos de dispositivo no presenta ninguna de esas señales.

El dominio es real. La página es real.

Lo único que cabe cuestionar es por qué un código llega por correo electrónico en primer lugar. Es algo más difícil de enseñar que a detectar un enlace sospechoso. Se le pide al empleado que interrumpa un proceso que parece totalmente normal, basándose en un juicio sobre la intención y no en una señal de alerta técnica. La formación basada en indicadores de phishing no llega a ese nivel de juicio. La formación basada en el comportamiento, en cambio, sí podría.

Lo que esto significa para los equipos de seguridad

Los controles técnicos ayudan. Las políticas de acceso condicional pueden bloquear el flujo de código de dispositivo para las cuentas que no lo necesitan, y restringir el registro de dispositivos limita lo que un atacante puede hacer con una sesión robada. Sin embargo, ninguno de estos controles enseña al empleado a reconocer el patrón la próxima vez que aparezca en un lugar donde esos controles no llegan.

Los equipos de seguridad deben combinar esos controles con una formación que enseñe a los empleados a cuestionar cualquier código no solicitado, no solo los enlaces sospechosos. Bloquear el flujo y fomentar el reconocimiento son tareas distintas, y un programa que solo cubre una deja la otra brecha abierta.

Esto plantea una pregunta sobre la que merece la pena reflexionar en lugar de responder rápidamente: ¿qué haría falta para preparar a los empleados ante un ataque que utiliza infraestructura real en lugar de falsificarla? Cualquier simulación de un flujo que interactúe con sistemas de autenticación reales necesitaría garantías firmes, que no se expongan datos reales de usuarios y que cualquier acceso concedido durante el ejercicio se revoque de inmediato. Lograr ese equilibrio, lo suficientemente realista para fomentar el reconocimiento y lo suficientemente controlado para ser seguro, es un problema de diseño más complejo que una simulación de phishing típica. Es también hacia donde apunta el problema a continuación.

Un control que bloquea un flujo puede ser evadido. Un empleado que reconoce el patrón, no.

El phishing mediante código de dispositivo no tuvo éxito en 340 organizaciones porque la autenticación multifactor fuera débil. Tuvo éxito porque pidió a los empleados que confiaran en un proceso que parecía, y era, genuinamente creado por Microsoft.

Ese es un problema más difícil que una página de inicio de sesión falsa, y es el que la gestión de riesgos humanos debe resolver a continuación. Este es el tercer patrón que hemos detectado en el que la MFA hace exactamente lo que se supone que debe hacer y, aun así, la cuenta cae.

Los otros son: llamadas de vishing que capturaron códigos de MFA en tiempo real, y una transferencia bancaria de 60 millones de dólares aprobada después de que la MFA superara todos los controles.