La cadena de fallo del phishing en Microsoft 365: de Evilginx y repos públicos al abuso del device code

Un descubrimiento aparentemente trivial —un servidor Python público con el listado de directorios activado y un .bash_history legible— descorrió la cortina sobre tres campañas de phishing dirigidas a Microsoft 365 y permitió a los investigadores reconstruir una cadena completa de herramientas, operadores y tácticas. Ese pequeño fallo operacional es la moraleja: la seguridad no suele romperse por un único exploit sofisticado, sino por una combinación de código disponible públicamente, mala higiene operacional y automatización que baja la barrera de entrada para atacantes poco experimentados.

En los casos analizados se usaron dos mecanismos técnicamente distintos para capturar accesos a cuentas corporativas: por un lado, proxies de adversary-in-the-middle construidos sobre forks del proyecto Evilginx (un proxy que preserva la página real para engañar al usuario y captura cookies de sesión) y, por otro, un abuso legítimo del flujo OAuth conocido como device code flow, que obliga a la víctima a completar el inicio en microsoft.com/devicelogin y donde el atacante “polling” toma el token cuando el usuario lo autoriza. Ambos enfoques son peligrosos, pero requieren defensas diferentes: la primera se mitiga con MFA resistentes a phishing (FIDO2/passkeys) y binding de origen; la segunda exige políticas de acceso condicional que bloqueen o limiten el device code flow.

Es relevante que todos los marcos usados por los operadores fueran forks públicos o binarios precompilados distribuidos en GitHub, algunos con mejoras diseñadas para evadir detección y prolongar la validez de las cookies o tokens. Eso confirma una tendencia: la comercialización del phishing como servicio y la reutilización masiva de código disponible en repositorios públicos hacen que campañas efectivas se puedan montar con poco coste y por actores que no desarrollan la infraestructura desde cero. El repositorio original de Evilginx sigue siendo un recurso conocido y accesible: https://github.com/kgretzky/evilginx2.

Las consecuencias prácticas para un equipo de seguridad de Microsoft 365 son claras y urgentes. Primero, no contar con políticas de acceso condicional que restrinjan el device code flow deja una puerta abierta que no se cierra con la mera implantación de FIDO2. Microsoft, por su parte, documenta el device code flow y sus usos legítimos en desarrollos: https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-device-code. Para mitigar el abuso, la palanca operativa es Conditional Access: inventorya qué aplicaciones necesitan realmente ese flujo, prueba una política en modo solo informe y luego prohíbe el flujo donde no sea necesario. La guía general de Conditional Access y sus capacidades está disponible aquí: https://learn.microsoft.com/azure/active-directory/conditional-access/overview.

En paralelo, la defensa contra proxies de tipo AiTM exige desplegar MFA resistente a phishing y controles que validen el origen del inicio de sesión. FIDO2 y passkeys son efectivos para bloquear el Evilginx clásico porque asocian la autenticación a un origen legítimo; sin embargo, no son suficientes por sí solos para cubrir device code abuse. Además, Microsoft recomienda añadir Continuous Access Evaluation para forzar reevaluaciones de sesiones cuando un token robado aparece desde ubicaciones o condiciones anómalas: https://learn.microsoft.com/azure/active-directory/continuous-access-evaluation-overview.

Desde la detección y la caza de amenazas, hay señales concretas que priorizar. Revisen los registros de inicio de sesión de Entra (Azure AD) en busca de concesiones de refresh token asociadas al client ID del cliente de Office desktop d3590ed6-52b3-4102-aeff-aad2292ab01c cuando ese cliente no es parte de la base de uso normal. Crucialmente, rastreen el campo Original transfer method y no sólo el evento de autenticación actual, porque las sesiones iniciadas por device code pueden conservar ese rastro aunque la autenticación posterior ya no lo muestre explícitamente.

En endpoints, busquen artefactos de persistencia que los operadores dejan tras su pivot, incluyendo herramientas RMM que suelen desplegarse para mantener accesos. En los casos investigados apareció un agente llamado XEOX (por ejemplo C:\\Program Files (x86)\\XEOX\\xeox-agent_x64.exe) y tareas programadas con patrones que pueden ser detectables. Estas huellas varían, así que combinen telemetry EDR con búsquedas de firmas y alerta sobre ejecutables desconocidos o nuevos relojes de persistencia.

También hay una lección operativa para desarrolladores y administradores de infraestructura: nunca expongas listado de directorios ni información sensible en servidores públicos, limpia los historiales de shell y no almacenes contraseñas en texto claro en paneles o ficheros versionados. Si un repositorio público contiene secretos o binarios precompilados expone a la operación completa: aprende a eliminar datos sensibles del historial de Git y a girar credenciales comprometidas; GitHub explica cómo tratar repositorios con información sensible aquí: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository.

En respuesta inmediata ante una sospecha: revoquen tokens y sesiones afectadas, fuerzen la expiración de refresh tokens comprometedores, apliquen la política de Conditional Access que bloquee device code flow si no es imprescindible, pongan en cuarentena y forenseen los endpoints detectados con RMM, y notifiquen a Microsoft y a los proveedores de los servicios comprometidos para coordinar mitigación y bloqueos de infraestructura rotativa. Considérenlo un ejercicio de “contención + endurecimiento”; bloquear IPs y dominios es útil, pero insuficiente si no se corrigen las políticas que permiten la técnica.

La conclusión editorial es que la protección efectiva frente a estas campañas requiere dos capas simultáneas: políticas técnicas que cierren vectores protocolarios (bloquear device code donde no se necesita y aplicar CAE) y mejoras operacionales que cierren fugas y malas prácticas (control de repositorios, limpieza de historiales, rotación de secretos). Mientras el ecosistema de phishing siga siendo comercial y modulable —con forks pulidos, binarios listos y generación asistida por modelos—, las organizaciones que crean que desplegar MFA y treinamiento de usuarios es suficiente estarán expuestas. Defender Microsoft 365 hoy significa combinar MFA resistente, Conditional Access bien diseñado, detección de anomalías en tokens y buenas prácticas de seguridad en servidores y repositorios.