martes, 14 de julio de 2026
Ciberseguridad

Descubren tres campañas de phishing dirigidas a usuarios de Microsoft 365 tras identificar un servidor con configuración deficiente

Un servidor mal configurado ha permitido descubrir tres operaciones activas de phishing dirigidas contra Microsoft 365 que combinan Evilginx y el abuso del flujo OAuth Device Code. El análisis de este incidente revela que passkeys y FIDO2 detienen el ataque de proxy inverso, pero no neutralizan por sí solos el vector de Device Code si no se complementan con Acceso Condicional y una gestión rigurosa de tokens.

La exposición accidental de un servidor web ha sacado a la luz tres campañas activas de phishing dirigidas a cuentas de Microsoft 365, con información suficiente para reconstruir su infraestructura, herramientas y operativa. El fallo no provino de una vulnerabilidad sofisticada, sino de una mala práctica elemental: ejecutar un servicio con python3 -m http.server 8080 y permitir listados de directorios. El acceso a artefactos y al archivo .bash_history facilitó el seguimiento del rastro técnico de las campañas.

El material identificó tres actores distintos: codemado, mail-argenta y saroula01, que operaban de forma independiente utilizando bifurcaciones de Evilginx obtenidas de repositorios públicos. Dos técnicas concentraban el mayor riesgo. La primera, phishing AiTM con proxy inverso, permite interponerse entre la víctima y el servicio legítimo, capturar cookies de sesión y eludir la MFA tradicional en flujos interactivos. La segunda, más discreta, explota el flujo OAuth Device Code que utiliza microsoft.com/devicelogin para obtener tokens sin necesidad de clonar la pantalla de inicio de sesión ni robar credenciales en una página señuelo.

En una variante denominada red-queen, los operadores modificaron atributos HTML para evitar Subresource Integrity, implementaron reescritura de URL y establecieron un TTL de un año para las cookies capturadas. En los artefactos analizados aparecieron cookies con fecha de caducidad del 30 de junio de 2027, evidenciando cuánto tiempo puede mantenerse una sesión sin controles adicionales. 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, indicativo de automatización para mantener sesiones activas en segundo plano.

El incidente también ilustra la evolución del robo de credenciales hacia el control continuado. El actor codemado desplegó herramientas RMM para persistencia y gestión posterior, incluyendo SimpleHelp, ScreenConnect y XEOX, además de droppers y robacredenciales. Cuando un atacante consigue un token reutilizable, el correo corporativo deja de ser únicamente un objetivo para convertirse en una plataforma de movimiento lateral dentro de la organización.

Las defensas deben distribuirse según los vectores de ataque. Frente al phishing con proxy inverso, la MFA resistente al phishing, como FIDO2 o passkeys, reduce significativamente la eficacia de la captura de cookies en inicios de sesión interactivos. Para el abuso de Device Code, la aproximación cambia: conviene bloquear el flujo en Microsoft Entra ID cuando no existe una necesidad operativa genuina, dejando excepciones mínimas y acotadas a dispositivos o herramientas que lo requieran.

La higiene de seguridad pasa por políticas sólidas de Acceso Condicional, restricciones por ubicación e IP, y la activación de Continuous Access Evaluation para reducir la vida útil efectiva de tokens robados en cargas compatibles. La telemetría resulta fundamental: auditar concesiones de tokens vinculadas a Device Code, identificar sesiones cuyo origen refleje este 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 previsible el uso del cliente de Office de escritorio, cotejándolo con IPs o ASN inusuales.

Si aparece actividad sospechosa, la respuesta debe ir más allá del cambio de contraseñas. Es necesaria 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. En los endpoints, resulta importante buscar RMM no autorizadas, especialmente 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 este servidor ha expuesto no solo una campaña, sino cómo se encadenan hoy el engaño, los tokens y la persistencia en entornos cloud.

Con Información de unaaldia.hispasec.com

Editor

Redacción.

Deja tu comentario