Device Code Phishing Amenaza Real en Microsoft 365 sin Páginas de Inicio Falsas

Entre finales de junio y los primeros días de julio de 2026, investigadores de ZeroBEC describieron una campaña activa de phishing que aprovecha el flujo legítimo de autenticación por dispositivo de Microsoft 365 para secuestrar cuentas, usando señuelos de colaboración (mensajes, invitaciones a carpetas compartidas, avisos de pago) que incitan a la víctima a introducir un código de dispositivo proporcionado por el atacante. La amenaza no depende de páginas de ingreso falsas tradicionales: explota una funcionalidad real y de confianza, lo que la hace más difícil de detectar por usuarios distraídos y por controles que buscan formularios de login falsos.

La técnica, conocida como device code phishing, abusa del mecanismo estándar OAuth 2.0 Device Authorization Grant, diseñado para dispositivos con interfaces limitadas. En la práctica, un atacante inicia la generación de un código de dispositivo, engaña a la víctima para que lo introduzca en microsoft.com/devicelogin y así autoriza, sin saberlo, la sesión controlada por el atacante. Microsoft documenta el flujo y sus propiedades en su guía técnica, que conviene leer para entender por qué el proceso es legítimo y qué logs quedan tras su uso: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code.

Lo preocupante de los hallazgos es la industrialización del ataque. ZeroBEC y otros equipos han identificado una capa reutilizable de tooling llamada DEBULL y plataformas de phishing-as-a-service (PhaaS) como EvilTokens, ARToken o Tycoon que empaquetan desde la orquestación del código hasta paneles post‑compromiso para mantener persistencia, exfiltrar correos y archivos, y automatizar campañas de business email compromise (BEC) mediante AI. Esto convierte lo que antes era una táctica compleja en un servicio accesible para operadores con distintos niveles de habilidad, multiplicando el riesgo y la velocidad de propagación.

Las implicaciones son severas: superar la MFA, obtener tokens válidos sin robar contraseñas, persistencia en entornos Microsoft 365, acceso a Exchange, OneDrive/SharePoint, y movimiento lateral soportado por APIs de Microsoft Graph. Además, el uso de cuentas ya comprometidas para distribuir enlaces legítimos hace que los mensajes parezcan fiables para destinatarios que confían en el remitente, facilitando el efecto multiplicador de las campañas.

Para usuarios individuales la recomendación más inmediata es sencilla pero crítica: nunca introducir códigos de dispositivo que te lleguen en un correo, chat o llamada si no están apareciendo en la pantalla del dispositivo donde intentas autenticarte. Trátalos como un OTP sensible: si no has iniciado una acción consciente en un dispositivo que controlas, no autorices nada y comunícate por canales verificados con quien supuestamente te solicita la acción.

En el plano organizacional conviene priorizar mitigaciones que reduzcan la ventana de abuso y que favorezcan métodos de autenticación resistentes al phishing: implementar autenticadores phishing‑resistentes (FIDO2, Windows Hello for Business), exigir dispositivos administrados o conformes mediante Conditional Access, monitorizar e investigar inicios de sesión con el grant type "device_code" en los registros de sign‑in de Azure AD y configurar alertas para patrones anómalos (tokens emitidos de ubicaciones extrañas o sesiones concurrentes). También es recomendable revisar la exposición de la función si no se utiliza y evaluar el bloqueo o restricción del Device Authorization Grant a entornos controlados. Para orientación general sobre prevención de phishing y buenas prácticas, CISA ofrece recursos públicos útiles: https://www.cisa.gov/publication/phishing.

Detectar y responder requiere combinar señales técnicas y procesos: correlacionar registros de autenticación que indiquen uso de device codes con actividad de correo y acceso a SharePoint/OneDrive, bloquear dominios e infraestructuras asociadas a PhaaS conocidas, rotar credenciales elevadas y aplicar acceso just‑in‑time y privilegios mínimos. Además, la capacitación continua de empleados debe incluir ejemplos concretos de este vector y procedimientos claros de verificación para solicitudes de acceso o pagos que lleguen por correo o chat.

Finalmente, la evolución hacia paneles completos de BEC operables por afiliados y con funciones impulsadas por IA subraya que la defensa debe ser proactiva y adaptativa. No basta con MFA tradicional; hay que añadir controles phishing‑resistentes, visibilidad en los logs de autenticación y procesos de detección y respuesta que asuman que cualquier cuenta puede ser el punto de partida de una campaña. La combinación de educación, endurecimiento de políticas de identidad y visibilidad operativa es la forma más práctica de reducir el impacto de estas campañas.