TokenFlare y la nueva generación de AiTM serverless: cuando el phishing se convierte en infraestructura
Durante años, el phishing ha sido tratado como un problema “humano”: concienciación, banners, simulaciones internas y poco más. Sin embargo, el auge de los Adversary-in-the-Middle (AiTM) ha cambiado por completo el paradigma. Ya no estamos ante simples páginas falsas que roban credenciales, sino ante infraestructuras activas que participan en el proceso de autenticación legítimo.
El proyecto TokenFlare, publicado por JUMPSEC Labs, es un excelente ejemplo de esta evolución. No por introducir técnicas radicalmente nuevas, sino por demostrar lo trivial que resulta hoy desplegar AiTM sofisticado usando arquitecturas serverless, con muy poco coste, muy poca fricción y una superficie de detección sorprendentemente reducida.
Los frameworks AiTM clásicos (como Evilginx o Modlishka) requieren servidores propios configurados con TLS, scripts proxy complejos, gestión manual de dominios, certificados y anti-bot y, en definitiva, días de configuración para integrarse bien al IdP objetivo.
TokenFlare sin embargo es un frameword AiTM para Entra ID/M365 que rompe este molde aprovechando Cloudflare Workers, moviendo toda la lógica de proxy AiTM a un modelo serverless distribuido, donde Cloudflare gestiona TLS, CDN, routing y DDoS, la lógica de phishing se reduce a unas ~530 líneas de JavaScript y la infraestructura se despliega con un simple CLI (tokenflare.py) en < 60s.
Según los autores, esto reduce el tiempo de setup de días a minutos, eliminando casi todo el overhead operacional previo.
Arquitectura de TokenFlare: el flujo AiTM en acción
A alto nivel, el flujo de un ataque AiTM con TokenFlare es el siguiente:
- El usuario recibe un lure URL que apunta al Worker de TokenFlare.
- El Worker inicia el flujo OAuth contra login.microsoftonline.com.
- La víctima ve la página legítima de Microsoft (con branding si se configura).
- Tras introducir credenciales y completar MFA, Microsoft responde con cookies de sesión (ESTSAUTH, ESTSAUTHPERSISTENT).
- El Worker captura estas cookies y las envía a un webhook definido por el operador.
- La víctima es redirigida a su destino esperado — sin notar nada sospechoso.
- Abre un navegador nuevo (o una ventana de incógnito) sin sesiones de Microsoft existentes.
- Ve a cualquier servicio de Microsoft 365; office.com funciona bien.
- Haz clic en "Iniciar sesión" y deja que te redirija a login.microsoftonline.com.
- Abre DevTools, borra las cookies existentes de ese dominio.
- Importa las cookies ESTSAUTH y ESTSAUTHPERSISTENT capturadas.
- Actualiza la página: ya está autenticado como víctima.

.png)
Comentarios
Publicar un comentario