La empresa francesa Lexfo descubrió tres campañas de phishing activas contra Microsoft 365, aprovechando un error de uno de los operadores: este dejó en el servidor de ataque un servidor web Python con listado de directorios abierto. Las campañas utilizaban dos métodos fundamentalmente distintos para eludir la autenticación multifactor (MFA): el proxy de sesiones mediante Evilginx y el abuso del flujo legítimo OAuth device code. Es de importancia crítica que estos dos vectores requieren medidas defensivas diferentes: las llaves FIDO2 bloquean el primero, pero son ineficaces frente al segundo. Las organizaciones que utilizan Microsoft 365 deben revisar sus directivas de Conditional Access para comprobar la existencia de un bloqueo del device code flow.
Cómo se descubrió la infraestructura
Según los investigadores de Lexfo, a finales de abril de 2026, durante un escaneo rutinario de Internet, se detectó un servidor en la dirección 185.163.204[.]7 (Budapest), en el que se ejecutaba un servidor web de Python, lanzado con el comando python3 -m http.server 8080, que también se conservaba en el archivo .bash_history. El listado abierto de directorios contenía configuraciones de phishing, registros de credenciales interceptadas, instaladores de herramientas de administración remota (RMM), listas combinadas de contraseñas, archivos de copias de seguridad y archivos de sesiones de Telegram del operador. En el mismo host funcionaban el proxy Evilginx (adversary-in-the-middle) y la consola de acceso remoto SimpleHelp.
A partir de este hallazgo, los investigadores identificaron tres campañas distintas, cada una de las cuales utilizaba su propia modificación de Evilginx, clonada de repositorios públicos en GitHub. Según Lexfo, la más extensa de ellas llevaba operando más de un año, y alrededor del 94 % de las cuentas comprometidas pertenecían a buzones de correo corporativos.
Dos métodos para eludir la MFA
Adversary-in-the-middle mediante Evilginx
El primer método es un proxy clásico: una versión modificada de Evilginx intercepta la sesión de autenticación entre la víctima y Microsoft, obteniendo las cookies de sesión después de que el propio usuario complete la MFA. Una de las modificaciones detectadas (los investigadores la denominan «red-queen») incluía una serie de mejoras técnicas: el cambio de nombre de los atributos HTML crossorigin e integrity para eludir las comprobaciones de Subresource Integrity, un motor de reescritura de URL en http_proxy.go para evitar la detección basada en rutas, así como el autocompletado de la dirección de correo electrónico de la víctima para reducir la tasa de abandono.
Resulta especialmente llamativa la configuración del TTL de las cookies de sesión de Microsoft interceptadas en 31 536 000 segundos (un año). Según la estimación de Lexfo, esto significa que una sesión interceptada puede sobrevivir incluso a un restablecimiento de contraseña y permanecer activa durante meses, en ausencia de una directiva de Continuous Access Evaluation (CAE). En el repositorio se encontró una cookie interceptada de Microsoft 365 con fecha de expiración hasta el 30 de junio de 2027. En el mismo lugar se encontraba el binario precompilado evilginx2.exe, que permite al comprador lanzar el ataque sin necesidad de realizar ninguna compilación.
Abuso del OAuth device code flow
El segundo método es fundamentalmente distinto y representa una amenaza mayor para las organizaciones que han implantado FIDO2 o passkeys. La tercera modificación («black-queen») ni siquiera intercepta contraseñas. En su lugar, explota un mecanismo legítimo de Microsoft: OAuth device code flow, pensado para dispositivos sin una interfaz de entrada completa.
El ataque funciona así: el backend genera un device code real, lo envuelve en una página de phishing con el aspecto de Microsoft Authenticator y dirige a la víctima a la página auténtica microsoft.com/devicelogin. La víctima introduce el código, supera la autenticación MFA real en el sitio legítimo de Microsoft y, de ese modo, autoriza la sesión del atacante. El backend consulta el endpoint de tokens y recoge el token en el momento en que finaliza la autenticación.
El punto clave: aquí una llave FIDO2 o un passkey no sirven de ayuda, porque la víctima se autentica en la infraestructura legítima de Microsoft. La vinculación al dominio (origin binding), que detiene a Evilginx, funciona correctamente, ya que el origin pertenece realmente a Microsoft. Microsoft documentó esta técnica en febrero de 2025 en el contexto de la campaña Storm-2372, que se vinculó a Rusia con un nivel moderado de confianza. Desde entonces, la técnica se ha extendido mucho más allá de las operaciones estatales.
Según Lexfo, en los registros del bot de Telegram de esta campaña se documentaron 218 cuentas comprometidas de una decena de países en el periodo de junio de 2025 a julio de 2026. En el historial del repositorio git se encontró un archivo con 97 tokens activos de Microsoft, vinculados a tres víctimas, todos con el flag autoRefresh; algunos se renovaron hasta 25 veces. El framework mantenía las sesiones activas de forma automática.
Contexto: ecosistema y alcance
Los tres operadores utilizaban modificaciones de Evilginx disponibles públicamente, en lugar de desarrollos propios. Los investigadores detectaron indicios de uso de IA en el desarrollo del código auxiliar: en dos commits de uno de los operadores figura como coautora la familia de modelos Claude; otro dejó en el repositorio un archivo instructions.txt, una transcripción literal de una sesión con un asistente de IA que documenta la creación de la función de reescritura de URL. Microsoft documentó por separado el uso de IA en campañas similares de device code phishing en abril de 2026.
En junio de 2026, la empresa SOCRadar describió un ecosistema de «phishing como servicio» denominado The Quarry, que, según sus estimaciones, daba servicio a unos 200 operadores. Las herramientas descubiertas en esta investigación aparecían en los canales de este ecosistema, lo que apunta a vínculos con el proveedor, aunque no es posible confirmar su pertenencia directa.
Recomendaciones prácticas
Estos dos vectores de ataque requieren dos líneas de defensa diferentes:
- Contra Evilginx (proxy AiTM): implantar una MFA resistente al phishing, como llaves FIDO2 o passkeys. La vinculación de la autenticicación al dominio hace que el proxy resulte inútil.
- Contra el device code phishing: bloquear el device code flow mediante una directiva de Conditional Access en todos aquellos casos en los que este flujo no sea necesario. Las excepciones son los dispositivos Teams Rooms y algunas herramientas CLI. Antes de aplicarla, pruebe la directiva en modo report-only.
- Limitación por IP y CAE: configure directivas de Conditional Access basadas en la ubicación y habilite Continuous Access Evaluation, de modo que un token utilizado desde una IP no autorizada se someta a una nueva comprobación, en lugar de ser válido durante todo su tiempo de vida.
Para la detección:
- Supervise en los registros de inicio de sesión de Entra ID la emisión de refresh tokens por parte del identificador de cliente de Microsoft Office
d3590ed6-52b3-4102-aeff-aad2292ab01c, especialmente si ese cliente de escritorio no se utiliza en la organización. Correlacione estos eventos con direcciones IP de origen atípicas. - Utilice el campo
Original transfer methoden los registros de inicio de sesión: una sesión iniciada mediante device code flow conserva esta etiqueta en las renovaciones posteriores del token, incluso si el protocolo de autenticación actual no la muestra. - En los endpoints, busque el agente XEOX en la ruta
C:\Program Files (x86)\XEOX\xeox-agent_x64.exey tareas programadas con el patrón*XEOX*Agent*Watchdog*; esta herramienta RMM se utilizó para establecer persistencia.
Indicadores de compromiso del informe: la dirección IP 185.163.204[.]7, los dominios picis[.]net y romnor[.]ca. La infraestructura rota con frecuencia, por lo que estos IOC deben considerarse un medio de localización y no una protección a largo plazo.
La principal conclusión de esta investigación no reside en operadores concretos, sino en un problema sistémico: una organización totalmente protegida frente al phishing AiTM gracias a los passkeys sigue siendo vulnerable al device code phishing si no se bloquea el flujo de autenticación correspondiente. Verifique que existe una directiva de Conditional Access que bloquee el device code flow para todos los usuarios, excepto para quienes lo necesiten objetivamente: se trata de una única directiva que cierra un vector que ni siquiera FIDO2 puede mitigar.
