Campañas de phishing contra Microsoft 365 descubiertas tras error humano.
Un escaneo fortuito dejó al descubierto una campaña activa de phishing dirigida a Microsoft 365 cuando un servidor Python con listado de directorios expuesto reveló la herramienta completa de un operador. La empresa francesa Lexfo analizó los archivos accesibles (registros, configuraciones de phishing, instaladores RMM, listas de credenciales y repositorios públicos) y atribuyó la infraestructura principal al actor identificado como "codemado", además de conectar dos forks activos del proxy Evilginx operados por otros dos autores conocidos como "mail-argenta" y "saroula01". En conjunto se trataron tres campañas que explotaron dos mecanismos distintos para hacerse con accesos a cuentas corporativas: (1) proxy inverso tipo Evilginx que captura cookies y sesiones (Adversary-in-the-Middle) y (2) abuso del flujo de código de dispositivo OAuth de Microsoft, que induce a la víctima a completar la autenticación legítima en microsoft.com/devicelogin y autorizar la sesión del atacante.
La primera técnica (Evilginx/reverse proxy) consigue tokens y cookies que, si tienen un TTL largo, pueden sobrevivir a cambios de contraseña; por ejemplo, una variante puso un TTL de un año sobre cookies capturadas. La segunda técnica (device code flow) no viola MFA: la víctima autoriza legítimamente la sesión en infraestructura de Microsoft, por lo que métodos basados en FIDO2 o passkeys no bloquean el abuso. Ambos enfoques mostraron uso de repositorios públicos y, en varios casos, piezas de código y documentación generadas con ayuda de modelos de IA.
Lexfo documentó que uno de los operadores mantuvo campañas por más de un año y que los kits provienen de forks públicos en GitHub, lo que disminuye la barrera de entrada para nuevos abusadores. Los artefactos contenían tokens activos configurados para auto-refresh, con registros de cuentas corporativas capturadas y refrescadas repetidamente por bots. Los investigadores también encontraron un host de radiación en Budapest y dominios de phishing asociados (picis.net, romnor.ca). El informe subraya que protegerse contra uno de los vectores no basta: una organización endurecida contra proxy-reverse phishing puede seguir siendo vulnerable al abuso del flujo de código de dispositivo si no aplica políticas específicas.
Recomendaciones
- Inventariar el uso del flujo de código de dispositivo y bloquearlo mediante políticas de Conditional Access donde no sea estrictamente necesario; probar en modo report-only antes de aplicar.
- Implementar políticas de Conditional Access basadas en ubicación y habilitar Continuous Access Evaluation (CAE) para reevaluar tokens sospechosos fuera de rangos permitidos.
- Priorizar MFA resistente a phishing (FIDO2/passkeys) para mitigar ataques por proxy; recordar que esto no detiene el abuso del device-code flow.
- Monitorizar en Entra/Sign-in logs concesiones de refresh-token y eventos del client ID d3590ed6-52b3-4102-aeff-aad2292ab01c cuando no corresponda a uso legítimo; buscar IPs inusuales y el campo "Original transfer method".
- En endpoints, buscar instalaciones y tareas programadas relacionadas con herramientas RMM (por ejemplo agentes XEOX y patrones *XEOX*Agent*Watchdog*) y contener/quarantine los hosts comprometidos.
- Revisar repositorios públicos y credenciales reutilizadas.
- Preparar detecciones para capturas de tokens y tráfico hacia proxies de captura.
Taxonomía
| ID Táctica | Nombre Táctica | Técnicas Relacionadas |
|---|---|---|
| TA0001 | Initial Access |
|
| TA0006 | Credential Access |
|
| TA0008 | Lateral Movement |
|
Referencias
https://thehackernews.com/2026/07/misconfigured-server-reveals-three.html
