Un atacante que ejecutaba una operación de phishing en vivo contra Microsoft 365 dejó un servidor web Python escuchando en un puerto público con el listado de directorios activado. El comando 'python3 -m http.server 8080' aún permanecía en el archivo .bash_history legible. A partir de ese error, la firma de seguridad francesa Lexfo obtuvo todo el conjunto de herramientas del operador y descubrió otros dos operadores de phishing, totalizando tres campañas. Cada una ejecutaba una bifurcación personalizada del proxy open-source Evilginx, clonado desde GitHub público.
La campaña más grande había estado activa más de un año, y sus víctimas eran abrumadoramente buzones corporativos. Las tres lograron eludir la autenticación multifactor (MFA) de dos formas mecánicamente diferentes: una mediante proxy del inicio de sesión en vivo, y otra abusando de un flujo legítimo de inicio de sesión de Microsoft. Ambas requieren defensas distintas, lo cual es crucial para quienes administran Microsoft 365.
El origen de los kits
El operador, rastreado como codemado, no construyó el framework que utilizaba, sino que lo clonó. Su servidor contenía cuatro variantes de Evilginx obtenidas de otros dos desarrolladores de GitHub, quienes resultaron ser operadores activos. La primera bifurcación, red-queen, proviene de un operador nigeriano llamado mail-argenta. Su fork renombra los atributos HTML crossorigin e integrity para eludir las comprobaciones de integridad de subrecursos, añade un motor de reescritura de URL en http_proxy.go para esquivar la detección basada en rutas, y pre-rellena la dirección de correo electrónico de la víctima para reducir el abandono.
mail-argenta fue descubierto de la misma forma que sus víctimas: Lexfo encontró su correo electrónico y contraseña en registros de infostealers. Esa contraseña coincidía con la codificada como contraseña MySQL en su panel Kraken y reutilizada en sus cuentas.
El operador silencioso
La tercera bifurcación, black-queen, registró muchas más capturas que las otras dos y nunca toca una contraseña. Su autor, identificado solo como saroula01, la construyó en torno al flujo de código de dispositivo OAuth de Microsoft, una ruta de inicio de sesión legítima para dispositivos con entrada limitada. El ataque genera un código de dispositivo real, lo envuelve en una página de señuelo con temática de Authenticator e indica a la víctima que lo introduzca en el sitio genuino microsoft.com/devicelogin. La víctima inicia sesión en una página real de Microsoft y completa la MFA por sí misma. Saroula01 sondea el endpoint de token y lo toma en cuanto la víctima lo autoriza.
La versión de saroula01 operó silenciosamente durante más de un año. Lexfo contó 218 cuentas distintas capturadas en los registros del bot de Telegram de la campaña entre junio de 2025 y julio de 2026, aproximadamente el 94% de ellas buzones corporativos. Un archivo de token que fue subido y luego eliminado del repositorio, pero aún legible en el historial de git, contenía 97 tokens vivos de Microsoft vinculados a tres de esas víctimas, todos configurados con autoRefresh y algunos actualizados hasta 25 veces.
Ambos dominios de phishing, picis[.]net y romnor[.]ca, estaban fuera de línea cuando The Hacker News los verificó antes de la publicación, aunque la línea de tiempo del informe muestra que picis[.]net aún aprovisionaba nuevos subdominios hasta mayo de 2026. El equipo de CTI de Lexfo indicó que los dominios ya habían caído antes de que tomaran alguna acción, interpretando esto como una rotación de infraestructura o retirada por parte de los operadores, aunque no pueden confirmarlo.
Construido con ayuda
El informe encontró señales de desarrollo asistido por IA en las tres operaciones. Saroula01 dejó dos commits de git coautorados por modelos Claude. Mail-argenta subió un instructions.txt que es una copia textual de una sesión de codificación con IA, incluyendo referencias a prompts anteriores, documentando cómo se construyó la función de reescritura de URL. Codemado es más leve: uno de sus scripts acredita a CyberNeurova, una API de generación de código 'sin censura' de pago, que se promociona con el prompt 'Build me a keylogger in Python'.
Lo que los defensores pueden hacer realmente
Las dos técnicas no comparten una solución única. La MFA resistente al phishing (FIDO2 o passkeys) sigue bloqueando el lado de Evilginx al vincular el inicio de sesión al dominio real, pero no detiene el abuso del código de dispositivo. Para ello, la palanca es Conditional Access. Microsoft recomienda bloquear el flujo de código de dispositivo donde sea posible, inventariar los usos legítimos mediante registros de inicio de sesión, y probar las políticas en modo solo informe antes de aplicarlas.
Se deben aplicar políticas de ubicación basadas en IP y Continuous Access Evaluation para que un token robado desde fuera de los rangos permitidos sea reevaluado en lugar de agotar su vida útil. Para detección, el informe señala que las concesiones de tokens de actualización del ID de cliente de Microsoft Office d3590ed6-52b3-4102-aeff-aad2292ab01c en los registros de inicio de sesión de Entra son dignas de vigilancia, especialmente si ese cliente de escritorio no está en uso normal. Se deben cruzar con direcciones IP de origen desconocidas.
En los endpoints, se debe buscar las herramientas RMM que estos operadores utilizan para persistencia; el kit de codemado busca XEOX, por lo que se debe comenzar con el agente en C:\Program Files (x86)\XEOX\xeox-agent_x64.exe y tareas programadas que coincidan con *XEOX*Agent*Watchdog*. Los dominios e IPs están en el informe, pero esa infraestructura rota, por lo que debe tratarse como contención, no como solución.
