Liberamos nuestros honeypots de VPN: Citrix Gateway y Palo Alto GlobalProtect

A veces la mejor forma de entender cómo te están atacando es dejar una puerta falsa abierta.

Hace una semana alertamos a nuestros clientes de la explotación activa de un 0-day de Citrix NetScaler antes de que existiera un CVE publicado. Varias de nuestras fuentes de Threat Intelligence estaban viendo algo que todavía no tenía nombre. Cuando pasa eso, la pregunta útil no es «¿qué CVE es?», sino «¿cómo lo miro de cerca sin poner en riesgo infraestructura real?».

Hoy publicamos la respuesta: dos honeypots open source que simulan portales VPN y registran todo lo que un atacante hace contra ellos.

Qué acabamos de liberar

Por qué un honeypot de VPN y no otro

Las VPN son el punto de entrada favorito de cualquier campaña de acceso inicial: están expuestas a internet por diseño, concentran la autenticación de toda la empresa y suelen acumular CVE críticos. En los últimos años casi todos los incidentes grandes de acceso inicial han empezado en una: NetScaler, GlobalProtect, Pulse, Fortinet.

El problema es que la telemetría que tienes de esos intentos es pobre. El log de la VPN te dice que alguien falló un login. No te dice con qué credencial lo intentó, desde dónde, qué user-agent llevaba ni qué hizo antes y después. Un honeypot sí: cualquiera que llegue a él es, por definición, un atacante. No hay falsos positivos que filtrar.

Los dos que hemos liberado

Cada carpeta es autónoma: se puede copiar a un servidor y levantar ahí sin dependencias del resto. Los puertos de desarrollo son distintos a propósito, para poder tener los dos honeypots en marcha a la vez en la misma máquina.

Son clones 1:1, no maquetas

Un honeypot que se nota que es un honeypot no sirve para nada. Por eso no hemos maquetado una pantalla parecida: capturamos el portal real y lo servimos tal cual.

python3 download.py --host mi.empresa.com

Descarga la página de logon y todo lo que cuelga de ella —HTML, CSS, JS, imágenes, fuentes y los endpoints XML/JSON que consulta el cliente— y lo deja en static_cache/ con la misma estructura de rutas que el original. Sólo hace GET/POST pasivos del mismo host; los recursos de terceros (reCAPTCHA, CDN) se quedan apuntando fuera, como en el original.

A partir de ahí:

1. download.py captura el portal y guarda el host como marcador ``.
2. app.py sirve esa copia replicando el árbol de URLs, los códigos de estado y las cabeceras del original, reescribe `` al host de cada petición y guarda las credenciales.
3. run.sh monta el entorno (venv + requirements.txt) y arranca la app.

Los detalles que hacen que la copia aguante una inspección: las únicas cabeceras Server y Date que salen son las que pone app.py con la grafía del original —ni un Server: uvicorn—, porque uvicorn arranca con --no-server-header --no-date-header y por delante va el puente WSGI→ASGI de a2wsgi (el de asgiref rompe la segunda petición de cada conexión keep-alive).

Qué ves cuando alguien pica

Cada captura se escribe en JSON por línea, en dos ficheros:

{"ts": "2026-10-02T10:08:01Z", "event": "CREDENTIAL_CAPTURE",
 "path": "/nf/auth/doAuthentication.do", "ip": "203.0.113.7",
 "username": "ana.lopez", "password": "…",
 "extra_fields": {"savecredentials": "false"}, "geo": {"city": "Madrid"}}

Y el aviso que llega al Telegram del equipo, en el momento:

🎣 CREDENTIAL CAPTURED (GlobalProtect)
━━━━━━━━━━━━━━━━━━━━━━
👤 User: ana.lopez
🔑 Pass: …
🌐 IP: 203.0.113.7
🌍 Geo: Madrid, Spain (ES)
🏢 Org: Telefonica de Espana
🖥 UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64) …
📍 Path: /global-protect/login.esp
🕐 TS: 2026-10-02 11:22:01 UTC

El envío a Telegram es síncrono (con 5 s de timeout) a propósito: en serverless un hilo en segundo plano puede morir al terminar la respuesta, y perder una captura es lo peor que le puede pasar a un honeypot. Si Telegram lo rechaza —topic equivocado, bot fuera del grupo, token caducado— el motivo queda en el log.

Levantarlo en un minuto

git clone https://github.com/merabytes/vpn-honeypots.git

cd vpn-honeypots/globalprotect
bash run.sh --dev      # uvicorn en :8444 con autoreload
bash run.sh            # producción en :443, 4 workers

Lo mismo en citrix-gateway/, que por defecto usa el 8443 en desarrollo. Para que las alertas salgan del servidor, las tres variables de Telegram:

export TELEGRAM_BOT_TOKEN=123456789:AA...
export TELEGRAM_CHAT_ID=-1001234567890
export TELEGRAM_TOPIC_ID=42
bash run.sh

Antes de fiarte, comprueba que el bot puede escribir donde quieres:

curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
  -d chat_id=<CHAT_ID> -d message_thread_id=<TOPIC_ID> \
  -d text="prueba de alertas" | jq '{ok, description}'

Y para verificar que el honeypot se comporta como el original:

.venv/bin/python test_e2e.py     # 65 tests (citrix) / 49 (globalprotect)
.venv/bin/python tail_log.py     # capturas en vivo, ya formateadas

Tres decisiones de diseño que nos importan

1. Ninguna marca. Al capturar, el host original se sustituye por el marcador `` y en cada petición se reescribe al host por el que entren. El mismo static_cache/ sirve para cualquier dominio y el portal del que salió no aparece en ninguna parte del código ni de lo servido. Lo único que lo menciona es _meta.json, el registro de la captura.
2. Cero tráfico hacia el sistema original. No hay proxy: todo sale de static_cache/. El honeypot funciona aunque el portal real esté apagado en ese momento y nada de lo que haga el atacante llega al sistema de nadie.
3. Mismo servidor en dev y en producción. La diferencia entre development y producción es el puerto y los workers. El código que sirve el honeypot es el mismo, así que lo que pruebas es lo que despliegas.

En enterprise vamos un paso más allá

En nuestros despliegues enterprise la captura no se queda en un fichero ni en un mensaje de Telegram: capturamos la telemetría y los logs completos del honeypot y los integramos directamente en el panel del SOC, correlacionados con el resto de la telemetría del cliente.

Eso cambia la conversación. Un intento de autenticación contra la puerta falsa deja de ser un log suelto y pasa a ser el primer indicador de una campaña: si el mismo actor acaba de probar credenciales contra tu VPN falsa hace 20 minutos, tenemos contexto antes de que toque la de verdad.

Añadir tu propio portal VPN

El repo está pensado para crecer. Copia la carpeta que más se parezca a lo que quieras emular, cambia en download.py las semillas (los endpoints del portal) y en app.py la página de logon y las respuestas particulares del fabricante. El resto —crawler, reescritura de host, servidor estático y captura— es común.

Conclusión

No hace falta esperar al CVE para entender un ataque. Cuando varias fuentes de inteligencia apuntan a algo que todavía no tiene nombre, tener una puerta falsa abierta es la forma más barata de saber quién está llamando, con qué credenciales y desde dónde.

Ahora también puedes montarlo tú.

🔓 Open Source — github.com/merabytes/vpn-honeypots

#honeypot #citrix #netscaler #paloalto #globalprotect #vpn #threatintelligence #threathunting #opensource #merabytes

¿Quieres esta visibilidad sobre tu infraestructura, con la telemetría del honeypot integrada en un SOC 24/7? Hablamos.