Un servidor expuesto por una mala configuración ha permitido reconstruir tres operaciones activas de phishing contra Microsoft 365 que combinan Evilginx y el abuso del flujo OAuth Device Code. El caso deja una lección clara: las passkeys y FIDO2 frenan el proxy inverso, pero no cortan por sí solas el vector de Device Code si no se acompaña de Acceso Condicional y una gestión estricta de tokens.
La exposición accidental de un servidor web ha dejado al descubierto tres operaciones activas de phishing dirigidas a cuentas de Microsoft 365, con suficiente información como para reconstruir su infraestructura, sus herramientas y parte de su operativa. El fallo no vino de una vulnerabilidad sofisticada, sino de una mala práctica básica: levantar un servicio con python3 -m http.server 8080 y permitir listados de directorios. A partir de ahí, el acceso a artefactos y a un archivo tan revelador como .bash_history facilitó seguir el rastro técnico de las campañas.
El material apuntó a tres actores distintos, identificados como codemado, mail-argenta y saroula01, que trabajaban de forma independiente con bifurcaciones de Evilginx sacadas de repositorios públicos. Dos técnicas concentraron el grueso del riesgo. La primera, el phishing AiTM con proxy inverso, sirve para interponerse entre la víctima y el servicio real, capturar cookies de sesión y sortear la MFA tradicional en flujos interactivos. La segunda, más silenciosa, explota el flujo OAuth Device Code, el que utiliza microsoft.com/devicelogin, para conseguir tokens sin necesidad de clonar la pantalla de inicio de sesión ni robar la contraseña en una página señuelo.
En una variante apodada red-queen, los operadores retocaron atributos HTML para esquivar Subresource Integrity, añadieron reescritura de URL y fijaron un TTL de un año para cookies capturadas. En los artefactos analizados aparecieron cookies con caducidad tan lejana como el 30 de junio de 2027, un recordatorio incómodo de cuánto puede durar una sesión si el entorno no aplica controles adicionales. En paralelo, la campaña basada en Device Code acumuló 218 víctimas confirmadas en 12 países entre junio de 2025 y julio de 2026, con predominio de buzones corporativos. También se recuperaron tokens con autoRefresh y renovaciones repetidas, una pista de automatización para mantener sesiones vivas en segundo plano.
El caso también ilustra el salto del robo de credenciales al control continuado. El actor codemado desplegó herramientas RMM para persistencia y gestión posterior, entre ellas SimpleHelp, ScreenConnect y XEOX, además de droppers y robacredenciales. Cuando un atacante consigue un token reutilizable, el correo corporativo deja de ser solo un objetivo, se convierte en una plataforma para moverse por la organización.
En defensa, las prioridades se reparten por vectores. Para el phishing con proxy inverso, la MFA resistente al phishing, como FIDO2 o passkeys, reduce de forma drástica la eficacia de la captura de cookies en inicios de sesión interactivos. Para el abuso de Device Code, el enfoque cambia: conviene bloquear el flujo en Microsoft Entra ID siempre que no exista una necesidad operativa real y dejar excepciones mínimas, acotadas a dispositivos o herramientas que lo requieran.
A partir de ahí, la higiene pasa por políticas sólidas de Acceso Condicional, restricciones por ubicación e IP, y la activación de Continuous Access Evaluation para recortar la vida útil efectiva de tokens robados en cargas compatibles. La telemetría también ayuda: resulta clave auditar concesiones de tokens vinculadas a Device Code, buscar sesiones cuyo origen refleje ese método, y vigilar en los registros de Entra las concesiones de refresh token asociadas al client ID d3590ed6-52b3-4102-aeff-aad2292ab01c cuando no sea esperable el uso del cliente de Office de escritorio, cruzándolo con IPs o ASN inusuales.
Si aparece actividad sospechosa, la respuesta no debería quedarse en cambiar contraseñas. Hace falta una contención orientada a tokens: revocar sesiones y refresh tokens, forzar reautenticación con Acceso Condicional y acortar tiempos de reacción cuando se detecte Device Code en una cuenta comprometida. Y en los endpoints, conviene buscar RMM no autorizadas, en especial XEOX, con indicadores como C:\Program Files (x86)\XEOX\xeox-agent_x64.exe y tareas programadas compatibles con *XEOX*Agent*Watchdog*. La filtración de un servidor ha expuesto algo más que una campaña, ha enseñado cómo se encadenan hoy el engaño, los tokens y la persistencia en entornos cloud.
Más información
- The Hacker News – Misconfigured Server Reveals Three Evilginx Phishing Operations Targeting Microsoft 365 : https://thehackernews.com/2026/07/misconfigured-server-reveals-three.html
- Lexfo – One Misconfigured Server, Three Active Campaigns: Full exposure of three AiTM Phishing Operators : https://blog.lexfo.fr/opendir-to-phishing-operator.html
- Microsoft Security Blog – Inside an AI-enabled device code phishing campaign : https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/
Deja una respuesta