Phishing de código de dispositivo: La nueva amenaza de IA en Microsoft OAuth

En el panorama de la ciberseguridad de 2026, la sofisticación de las amenazas ha alcanzado un punto de inflexión crítico. El equipo de Investigación de Seguridad de Microsoft Defender ha revelado recientemente los pormenores de una campaña masiva y altamente coordinada que redefine el concepto de ingeniería social. Se trata de un ataque de phishing de código de dispositivo que no solo utiliza inteligencia artificial generativa para engañar al ojo humano, sino que emplea una infraestructura automatizada de “generación dinámica de códigos” para doblegar los controles técnicos que antes considerábamos infranqueables.

Esta campaña, detectada en su fase de máxima expansión durante abril de 2026, marca el debut a gran escala de plataformas de Phishing-as-a-Service (PhaaS) como “EvilTokens”. A diferencia de los ataques tradicionales que buscan robar contraseñas, este método explota el flujo de autorización de dispositivos de OAuth 2.0, un protocolo diseñado para la comodidad del usuario en dispositivos con interfaces limitadas (como Smart TVs o impresoras), pero que hoy se ha convertido en el talón de Aquiles de la identidad corporativa.

La anatomía del Phishing de código de dispositivo en la era de la IA

El phishing de código de dispositivo se basa en una premisa técnica ingeniosa: separar la sesión de autenticación del dispositivo del atacante. En un flujo legítimo, un dispositivo solicita un código de 8 caracteres que el usuario introduce en un navegador para autorizar el acceso. Los atacantes han industrializado este proceso. El flujo de ataque descubierto por Microsoft sigue una secuencia lógica de cinco fases que demuestra una madurez operativa sin precedentes:

• Reconocimiento silencioso: Uso del API GetCredentialType.
• Ingeniería social de precisión: Lures hiper-personalizados mediante IA.
• Generación dinámica de códigos: Bypass del tiempo de expiración de 15 minutos.
• Infraestructura de redirección elusiva: Uso de Railway.com y AWS Lambda.
• Exfiltración y persistencia: Abuso de Microsoft Graph API y tokens persistentes.

Fase 1: Reconocimiento y validación mediante GetCredentialType

Antes de enviar un solo correo electrónico, los actores de amenazas ejecutan una fase de reconocimiento técnico que suele pasar desapercibida para los equipos de SOC. Utilizan el endpoint /common/GetCredentialType de Microsoft para realizar consultas masivas. Este API permite confirmar si una dirección de correo electrónico es válida dentro de un tenant específico y, lo más importante, qué métodos de autenticación tiene activos el usuario.

Al abusar de este API, el atacante puede filtrar su lista de objetivos para centrarse únicamente en cuentas activas, evitando generar “ruido” con rebotes de correos inexistentes. Además, este paso les permite identificar si el branding de la empresa (logos, fondos de pantalla personalizados) está configurado, información que la IA utilizará posteriormente para clonar la apariencia visual de la página de inicio de sesión con una precisión del 100%.

Fase 2: Hiper-personalización impulsada por IA Generativa

El éxito de esta campaña radica en su capacidad para evadir los filtros de lenguaje natural de las pasarelas de correo seguro (SEG). Los atacantes emplean modelos de lenguaje avanzados para redactar señuelos adaptados al rol corporativo específico de la víctima. Un analista financiero recibirá un señuelo sobre una “Discrepancia en la Auditoría Q1”, mientras que un ingeniero de planta verá un “Protocolo de Seguridad de Manufactura Urgente”.

Esta hiper-personalización elimina las faltas de ortografía y los errores gramaticales que históricamente delataban al phishing. Al alinearse perfectamente con la jerga y los flujos de trabajo internos de la organización, el phishing de código de dispositivo logra tasas de clics significativamente superiores a las de campañas genéricas.

El avance técnico: Generación dinámica y bypass de TTL

Uno de los mayores obstáculos para los atacantes en el flujo de dispositivos de OAuth 2.0 es que el código generado tiene una vida útil (TTL) de apenas 15 minutos. En campañas antiguas, el código se incluía estáticamente en el cuerpo del correo; si el usuario tardaba 20 minutos en abrirlo, el ataque fracasaba. La campaña de 2026 ha resuelto esto mediante la generación dinámica de códigos.

Cuando la víctima hace clic en el enlace malicioso, no es dirigida a una página estática. En su lugar, el clic activa un script en segundo plano (generalmente alojado en AWS Lambda o Cloudflare Workers). Este script realiza una solicitud en tiempo real al servicio de identidad de Microsoft para obtener un código de dispositivo fresco en ese preciso instante. Esto garantiza que el contador de 15 minutos comience a correr justo cuando la víctima está frente a la pantalla, maximizando la ventana de oportunidad para el compromiso.

Uso de infraestructura de confianza: Railway y AWS Lambda

Para evitar que las herramientas de seguridad bloqueen los dominios maliciosos, los atacantes han migrado sus operaciones a plataformas de Platform-as-a-Service (PaaS) de alta reputación. El uso de Railway.com, Vercel y AWS Lambda permite que el tráfico de phishing se mezcle con el tráfico legítimo de la nube empresarial.

1. Redirecciones multi-salto: El enlace inicial en el correo suele ser un dominio comprometido de buena reputación.
2. Nodos intermedios: El tráfico pasa por Cloudflare Workers que actúan como proxies para ocultar la IP del servidor de comando y control (C2).
3. Landing Page en Railway: La página final, donde se muestra el código generado dinámicamente, se aloja en infraestructuras como Railway, que a menudo están en la “lista blanca” de las organizaciones por ser herramientas de desarrollo comunes.

Post-compromiso: El rol de Microsoft Graph API y la Persistencia

Una vez que la víctima introduce el código en la página legítima de Microsoft (microsoft.com/devicelogin) y completa el MFA, el atacante recibe un token de acceso y un token de actualización (refresh token). En este punto, el atacante ya no necesita la contraseña del usuario. El token le otorga acceso directo a la identidad del sujeto.

Inmediatamente después del acceso inicial, la automatización entra en juego a través de Microsoft Graph API. Los atacantes realizan un reconocimiento interno rápido pero profundo:

• Enumeración de buzones: Búsqueda de correos con palabras clave como “transferencia”, “pago”, “factura” o “confidencial”.
• Creación de reglas de bandeja de entrada: Se crean reglas para desviar correos entrantes de departamentos de seguridad o TI hacia carpetas ocultas (como la papelera), permitiendo que el atacante opere sin que el usuario reciba alertas.
• Registro de nuevos dispositivos: En los casos más sofisticados, el atacante utiliza el token robado para registrar un dispositivo controlado por él en el Microsoft Entra ID de la víctima. Esto le permite generar un Primary Refresh Token (PRT), lo que garantiza persistencia a largo plazo incluso si el usuario cambia su contraseña.

El peligro de los tokens persistentes

El phishing de código de dispositivo es especialmente peligroso porque el token obtenido es independiente de la contraseña. Si la organización se limita a obligar a un cambio de contraseña tras detectar una anomalía, el atacante puede seguir utilizando el refresh token para generar nuevos tokens de acceso y mantener el control de la cuenta. La única solución efectiva es la revocación total de todas las sesiones y tokens activos del usuario afectado.

Estrategias de mitigación frente al Phishing de código de dispositivo

La defensa contra este tipo de ataques requiere un cambio de paradigma, pasando de la detección basada en firmas a una arquitectura de Confianza Cero (Zero Trust) robusta. Los equipos de seguridad deben implementar las siguientes medidas críticas:

1. Implementar MFA resistente al phishing: El uso de contraseñas y códigos SMS ya no es suficiente. Se debe priorizar el uso de llaves de seguridad físicas (FIDO2) o certificados en dispositivos, los cuales vinculan criptográficamente la sesión de autenticación al hardware del usuario, impidiendo que un código de dispositivo sea útil para un tercero.
2. Restringir el flujo de código de dispositivo: A través de Políticas de Acceso Condicional en Microsoft Entra ID, las organizaciones deben deshabilitar el flujo de “device code” para todos los usuarios, excepto para aquellos que operen dispositivos específicos sin navegador (como equipos de salas de conferencias).
3. Monitoreo de telemetría de identidad: Configurar alertas para inicios de sesión exitosos que utilicen el flujo de código de dispositivo desde direcciones IP inusuales o proveedores de hosting como Railway y AWS.
4. Educación continua: Capacitar a los empleados para que reconozcan que Microsoft nunca les pedirá ingresar un código de 8 caracteres a menos que ellos mismos hayan iniciado explícitamente una sesión en un dispositivo limitado.

En conclusión, el phishing de código de dispositivo representa la culminación de la automatización maliciosa y el abuso de protocolos legítimos. Mientras los atacantes sigan refinando sus capacidades con IA generativa, la única defensa real será la eliminación de las superficies de ataque heredadas y la adopción de métodos de autenticación que no dependan de la interacción humana con códigos transferibles. La seguridad de la identidad en 2026 ya no se trata de quién tiene la contraseña, sino de quién controla el flujo del token.