Phishing de código de dispositivo: aprobar un inicio de sesión que nunca iniciaste
En febrero de 2025, Microsoft Threat Intelligence Center documentó una campaña activa del actor al que sigue como Storm-2372, que robaba sesiones de inicio de sesión a organizaciones de Europa, Norteamérica, África y Oriente Medio. Lo notable de la técnica, el phishing de código de dispositivo, es lo que evita: no hay una página de inicio de sesión falsa que detectar, ninguna contraseña que robar y ningún malware que descubrir. La víctima nunca teclea un secreto. Un código suministrado por el atacante se introduce en la página de inicio de sesión genuina de Microsoft, la víctima aprueba el aviso en su propio dispositivo y el atacante se marcha con una sesión funcional.
Una función legítima, dada la vuelta
El flujo de código de dispositivo es una función real de OAuth 2.0, no una falsificación. Existe para hardware sin teclado ni navegador utilizables: impresoras, televisores, pantallas de salas de conferencias, decodificadores. El dispositivo muestra un código breve, el usuario abre el portal de inicio de sesión en un teléfono o portátil, introduce el código, inicia sesión y aprueba. El dispositivo recibe sus tokens. Storm-2372 invirtió esta secuencia. Según Microsoft, el grupo llevó la campaña desde agosto de 2024: abría chats en Microsoft Teams haciéndose pasar por directivos o funcionarios y luego trasladaba la conversación a Signal o WhatsApp con la excusa de compartir documentos. Las invitaciones a reuniones enviadas por correo usaban el mismo señuelo, disfrazado de tráfico ordinario de Teams. La cobertura de BleepingComputer sobre la misma campaña describía a víctimas a las que se pedía autenticar un dispositivo para recibir un documento importante: seguían un enlace a la página real de inicio de sesión de Microsoft, introducían el código recibido y aprobaban el inicio de sesión, con el habitual paso multifactor incluido. Los objetivos documentados por Microsoft incluían organismos gubernamentales, proveedores de servicios de TI, defensa, telecomunicaciones, sanidad, educación superior y empresas energéticas.Por qué esto anula por completo la MFA
El orden de las operaciones es lo que lo hace funcionar. El atacante inicia primero una solicitud legítima de código de dispositivo y solo después involucra a la víctima. Cuando esta introduce el código y aprueba, todas las comprobaciones de la página pasan con honestidad: la página es real, el código es válido y la persona que interactúa completa un inicio de sesión genuino, incluida la autenticación multifactor que corresponda. Los tokens que Microsoft emite, incluidos los refresh tokens de larga vida, van a quien inició la solicitud: el atacante. Desde el punto de vista del directorio, un usuario simplemente inició sesión con éxito. No hay nada que los filtros de correo ni los proxies web puedan marcar, porque la infraestructura implicada es completamente legítima. El informe de Microsoft registra lo que ocurrió después en los inquilinos comprometidos: los atacantes buscaron en los buzones con consultas de Graph API términos como credenciales, contraseñas y admin, extrajeron correspondencia y usaron cuentas internas de confianza para enviar phishing a colegas, de modo que una sola aprobación podía extenderse en cascada por la organización. En una actualización publicada un día después de la entrada original, Microsoft documentó además un cambio hacia solicitudes mediante el cliente Microsoft Authentication Broker, que permitían registrar dispositivos controlados por el atacante y solicitar primary refresh tokens. Proofpoint, que siguió la técnica mientras se extendía por kits de phishing durante 2026, señaló otro refinamiento: códigos generados a demanda en el momento en que la víctima hace clic en un enlace, sorteando la caducidad de quince minutos de un código pregenerado.El consejo habitual, mirar de cerca la página de inicio de sesión antes de escribir, no ayuda aquí. El análisis de Proofpoint de campañas posteriores señala que comprobar la URL falla porque el portal es genuinamente el de Microsoft; lo que se abusa es de la aprobación de la víctima, no de la barra de direcciones.
Señales de alerta que vale la pena enseñar
Las señales son consistentes entre campañas, y ninguna exige conocimientos técnicos para notarlas.- un inicio de sesión que no iniciaste: un código de dispositivo solo existe porque alguien lo solicitó
- urgencia y presión para actuar antes de que el código caduque o empiece una reunión
- un correo, chat o mensaje que pide aprobar o autenticar algo con un código que nunca solicitaste
- un contacto que salta de plataforma, como un chat de Teams que se muda a Signal o WhatsApp
- un documento o invitación a reunión que solo se desbloquea si verificas un código