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:

  1. El usuario recibe un lure URL que apunta al Worker de TokenFlare.
  2. El Worker inicia el flujo OAuth contra login.microsoftonline.com. 
  3. La víctima ve la página legítima de Microsoft (con branding si se configura). 
  4. Tras introducir credenciales y completar MFA, Microsoft responde con cookies de sesión (ESTSAUTH, ESTSAUTHPERSISTENT). 
  5. El Worker captura estas cookies y las envía a un webhook definido por el operador. 
  6. La víctima es redirigida a su destino esperado — sin notar nada sospechoso. 
Una vez conseguidas las cookies de sesión, éstas pueden ser inyectadas en un navegador limpio para obtener acceso a cualquier servicio de M365 sin solicitar MFA adicional.
  1. Abre un navegador nuevo (o una ventana de incógnito) sin sesiones de Microsoft existentes.
  2. Ve a cualquier servicio de Microsoft 365; office.com funciona bien.
  3. Haz clic en "Iniciar sesión" y deja que te redirija a login.microsoftonline.com.
  4. Abre DevTools, borra las cookies existentes de ese dominio.
  5. Importa las cookies ESTSAUTH y ESTSAUTHPERSISTENT capturadas.
  6. Actualiza la página: ya está autenticado como víctima.

Cómo empezar en un minuto

# 0. Clone the repo. 
# Dependencies - python3.7+, Node.js 20+, and globally installed Wrangler CLI
git clone https://github.com/JumpsecLabs/TokenFlare.git

# 1. Initialise for your domain - this domain is for deploying on your VPS
python3 tokenflare.py init yourdomain.com

# 2. Configure your campaign (interactive wizard)
python3 tokenflare.py configure campaign

# 3. Set up CloudFlare credentials - i.e. for deploying on Cloudflare
python3 tokenflare.py configure cf

# 4. Deploy to CloudFlare Workers
python3 tokenflare.py deploy remote

# 5. Check your lure URL
python3 tokenflare.py status --get-lure-url

Eso es todo. Infraestructura AiTM funcional, con SSL, protección contra bots y captura de credenciales en el webhook que prefieras ;)

Comentarios