En 05-01 escalamos privilegios y en 05-02 entendimos —de forma controlada— cómo se mantiene el acceso en un host. Pero el compromiso de TechNova no se mide en una sola máquina. El host que hemos tomado (por ejemplo, el servidor web expuesto en la DMZ) suele tener acceso a segmentos internos que desde nuestra posición de atacante externo no eran alcanzables directamente: la red 10.10.10.0/24 con el servidor interno Linux, el controlador de red, las estaciones. El pivoting es la técnica de usar el host comprometido como trampolín para llegar a esas redes; el movimiento lateral es desplazarse de un host a otro dentro de ellas usando las credenciales y accesos obtenidos. Aquí es donde un hallazgo pasa de "comprometieron un servidor web" a "desde ese servidor se alcanzaba toda la red interna" —justo el tipo de impacto que el informe necesita.

El encuadre sigue firme: todo dentro del scope autorizado de TechNova y las RoE. El pivoting es especialmente delicado porque amplía el alcance del compromiso a nuevos sistemas, así que solo se toca lo que esté explícitamente dentro del alcance —saltar a una red o a un host no autorizado, aunque sea técnicamente posible, es salirse del contrato. Como siempre, cada técnica ofensiva va con su contrapartida defensiva (segmentación, microsegmentación, detección de tráfico lateral), porque el objetivo es que TechNova entienda por qué su red plana es un riesgo y cómo contenerlo. Y no cubrimos la cobertura de huellas (05-04): aquí nos centramos en llegar, no en borrar rastro.

Contenido

  1. Por qué pivotar: la red interna tras el foothold
  2. Túneles y reenvío de puertos (SSH)
  3. Proxychains y proxy SOCKS dinámico
  4. Pivoting con Metasploit (autoroute)
  5. Movimiento lateral con credenciales obtenidas
  6. Contrapartida: segmentación y detección lateral
  7. Errores comunes y consejos
  8. Ejercicios
  9. Conclusión

  1. Por qué pivotar: la red interna tras el foothold

Desde fuera, el atacante solo veía la superficie expuesta de TechNova: tienda.technova.lab y poco más. Una vez dentro del servidor web, la perspectiva cambia por completo: ese host tiene una segunda pata en la red interna y ve máquinas que nosotros no veíamos. El pivoting aprovecha esa doble conectividad.

flowchart LR
    K[Kali<br/>pentester] -->|unico acceso| W[Host comprometido<br/>web DMZ]
    W -. pivote .-> S[srv interno<br/>10.10.10.20]
    W -. pivote .-> DC[controlador red<br/>10.10.10.10]
    W -. pivote .-> PC[estaciones<br/>10.10.10.30+]
    K -. sin acceso directo .-x S

Kali solo alcanza el host de la DMZ; la red 10.10.10.0/24 está tras él. El pivoting convierte ese host en una pasarela para que nuestras herramientas lleguen a la red interna. Primer paso, ya dentro: descubrir qué hay en el nuevo segmento (interfaces del host, tabla de rutas, un barrido de puertos contenido) para saber a qué se puede pivotar —siempre dentro del alcance.

  1. Túneles y reenvío de puertos (SSH)

SSH es la navaja del pivoting: permite tunelizar tráfico a través del host comprometido sin instalar nada raro. Tres modos, del más simple al más flexible:

Modo Qué hace Cuándo se usa
Local (-L) Un puerto local tuyo → un host:puerto alcanzable desde el pivote Llegar a un servicio interno concreto
Remoto (-R) Un puerto en el pivote → un host:puerto de tu lado Traer de vuelta una conexión (p. ej. el pivote no puede salir)
Dinámico (-D) Un proxy SOCKS local que enruta cualquier destino por el pivote Explorar toda la red interna con muchas herramientas

Reenvío local — acceder a un servicio interno puntual, por ejemplo la base de datos MySQL del servidor interno 10.10.10.20:3306, que desde Kali no se ve:

# Desde Kali: abre el puerto local 3306 y lo reenvia, A TRAVES del host pivote
# (10.10.10.5, ya comprometido), hasta 10.10.10.20:3306 de la red interna
ssh -L 3306:10.10.10.20:3306 [email protected]

# Ahora, en OTRA terminal de Kali, conectas a "localhost" y sales por el pivote:
mysql -h 127.0.0.1 -P 3306 -u lectura_lab -p   # llegas al MySQL interno

El -L 3306:10.10.10.20:3306 dice: "lo que llegue a mi puerto local 3306, mándalo por la sesión SSH hasta 10.10.10.20:3306". Así alcanzamos un servicio interno sin exponerlo y sin tocar más de la cuenta. Reenvío remoto (-R) hace lo inverso, útil cuando el pivote no puede iniciar conexiones hacia nosotros.

  1. Proxychains y proxy SOCKS dinámico

Para explorar la red interna con muchas herramientas, un único túnel a un puerto se queda corto. El túnel dinámico (-D) monta un proxy SOCKS local que enruta cualquier destino por el pivote; combinado con proxychains, hace que herramientas que no saben de proxies (como nmap) salgan por él.

# 1) Desde Kali: proxy SOCKS en el puerto 1080, con salida por el pivote
ssh -D 1080 [email protected]

# 2) Configurar proxychains para usar ese SOCKS
#    /etc/proxychains4.conf -> ultima linea:  socks5 127.0.0.1 1080

# 3) Lanzar herramientas A TRAVES del pivote hacia la red interna
#    -sT (TCP connect) y -Pn son obligatorios: SOCKS no tunela SYN crudos ni ICMP
proxychains nmap -sT -Pn -p 22,80,445 10.10.10.20

Con esto, un nmap lanzado desde Kali llega a 10.10.10.20 como si estuviera dentro de la red interna, saliendo por el host pivote. Notas importantes: SOCKS solo tunela TCP, así que hay que usar -sT y -Pn, y conviene acotar los escaneos (pocos puertos, sin ruido innecesario) —un barrido masivo por un túnel es lento y muy visible. Escanea solo lo que esté en alcance.

  1. Pivoting con Metasploit (autoroute)

Si el foothold se obtuvo con Metasploit (Módulo 4), el framework integra el pivoting mediante rutas dentro de la sesión Meterpreter: autoroute añade la red interna a la tabla de enrutamiento de Metasploit, de modo que sus módulos alcanzan esa red a través de la sesión existente.

# Con una sesion Meterpreter en el host pivote (10.10.10.5):
meterpreter > run autoroute -s 10.10.10.0/24   # enruta la red interna por esta sesion

# Volver a la consola y usar modulos contra la red interna a traves del pivote
msf6 > background
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 10.10.10.20
msf6 > set PORTS 22,80,445
msf6 > run    # el escaneo sale por la sesion del pivote, no directamente desde Kali

autoroute -s 10.10.10.0/24 le dice a Metasploit "para llegar a esa red, pasa por esta sesión". A partir de ahí, escáneres y módulos auxiliares funcionan contra la red interna sin conexión directa. Se puede añadir un socks_proxy para que herramientas externas se beneficien de la misma ruta. Igual que antes: acotado y dentro del alcance.

  1. Movimiento lateral con credenciales obtenidas

Pivotar nos da alcance de red; el movimiento lateral usa las credenciales recogidas por el camino (de la escalada de 05-01, de volcados, de configuraciones) para autenticarse en otros hosts del segmento. Dos técnicas de alto nivel, sin recetas ofensivas detalladas:

  • Pass-the-Hash (PtH): en entornos Windows, ciertos protocolos aceptan el hash NTLM de la contraseña en lugar de la contraseña en claro. Si en la escalada obtuvimos el hash de una cuenta administrativa, puede autenticarse en otros hosts que confíen en ella sin conocer la contraseña real. Es el motor del movimiento lateral en dominios Windows.
  • Ejecución remota autenticada (PsExec / WinRM): con credenciales válidas (o un hash válido), herramientas legítimas de administración remota permiten ejecutar comandos en otro host. Es el mismo mecanismo que usan los administradores; por eso el movimiento lateral es difícil de distinguir del trabajo normal de TI.
# Movimiento lateral a alto nivel, dentro del alcance, a traves del pivote:
# validar UNA credencial obtenida contra otro host y demostrar acceso, sin mas
proxychains crackmapexec smb 10.10.10.31 -u 'svc-admin' -H '<hash_NTLM_obtenido>'
# [+] 10.10.10.31  (Pwn3d!)  -> demuestra que la credencial vale ahi; se documenta y para

La marca (Pwn3d!) demuestra que la credencial es válida en ese host: eso es la evidencia. No hace falta desplegar payloads ni tomar la máquina entera; basta demostrar el alcance del reuso de credenciales. La clave metodológica: el movimiento lateral en un pentest es demostrativo —se prueba que "con esta credencial se llegaba hasta aquí" y se documenta la cadena, no se conquista host por host por deporte.

flowchart LR
    A[Credencial/hash<br/>obtenido en 05-01] --> B[Pivote da alcance<br/>a la red interna]
    B --> C[PtH / WinRM<br/>autenticacion en otro host]
    C --> D[Demostrar acceso<br/>y documentar cadena]

  1. Contrapartida: segmentación y detección lateral

El mensaje para TechNova. El pivoting y el movimiento lateral prosperan en redes planas donde, una vez dentro, se llega a todo. Las defensas atacan justo eso:

  • Segmentación de red: separar la DMZ de la red interna con cortafuegos que solo permitan los flujos estrictamente necesarios. Si el servidor web no necesita hablar con las estaciones, que no pueda —eso corta el pivote de raíz.
  • Microsegmentación: llevar la segmentación al nivel de host/carga de trabajo, de modo que cada máquina solo se comunique con las que debe. Contiene el movimiento lateral incluso dentro de un mismo segmento.
  • Mínimo privilegio y modelo administrativo por niveles (tiering): que una cuenta administrativa de una estación no sea válida en el controlador de red. Esto rompe el pass-the-hash entre niveles.
  • Detección de tráfico lateral (este-oeste): monitorizar no solo el tráfico que entra/sale (norte-sur) sino el que va entre hosts internos. Un servidor web escaneando la red interna o autenticándose contra muchas estaciones es una señal clarísima.
  • Higiene de credenciales: LAPS (contraseñas de admin local únicas), Credential Guard y rotación reducen el valor de un hash robado para saltar a otros hosts.

  1. Errores Comunes y Consejos

  • [Ético] Pivotar a redes o hosts fuera del alcance. El pivoting hace técnicamente alcanzable lo que la segmentación separaba; que puedas llegar no significa que puedas tocarlo. Solo lo que el scope autorice —cada nuevo host debe estar dentro del contrato.
  • Barrer la red interna a lo bruto por el túnel. Un nmap masivo por SOCKS es lento, muy ruidoso y arriesga saturar el pivote. Acota puertos y objetivos; usa -sT -Pn.
  • Olvidar -sT/-Pn con proxychains. SOCKS no tunela SYN crudos ni ICMP; sin esas opciones el escaneo falla o miente. Es el error técnico más común.
  • Tratar el movimiento lateral como conquista. El objetivo es demostrar el alcance del compromiso y documentar la cadena, no tomar cada máquina. Valida el acceso y para.
  • No documentar la cadena de pivote. El informe necesita el camino completo: "desde X (DMZ), vía túnel, se alcanzó Y, y con la credencial Z se llegó a W". Esa cadena es el impacto.
  • Dejar túneles o rutas abiertos al terminar. Cierra las sesiones SSH, retira las rutas de Metasploit y anótalo. Enlaza con la regla de oro de 05-02: no dejar accesos vivos.
  • Consejo: dibuja el mapa de la red interna a medida que pivotas. Un buen diagrama de la cadena de compromiso vale más en el informe que diez capturas sueltas.

  1. Ejercicios

Ejercicio 1. Has comprometido el servidor web de la DMZ de TechNova (10.10.10.5, accesible por SSH) y necesitas llegar al MySQL del servidor interno (10.10.10.20:3306), que desde Kali no ves. Escribe el comando de reenvío que lo permite, explica qué hace cada parte y por qué esto demuestra un fallo de segmentación. ¿Qué control de red lo habría impedido?

Ejercicio 2. Quieres escanear puertos concretos de varios hosts de la red interna 10.10.10.0/24 desde Kali, a través del pivote, con nmap. Describe el montaje con túnel dinámico y proxychains, indica las dos opciones de nmap imprescindibles y por qué, y una medida de detección que TechNova podría usar para verte.

Ejercicio 3. Durante la escalada obtuviste el hash NTLM de una cuenta svc-admin. Explica, a alto nivel, en qué consiste el movimiento lateral por pass-the-hash, cómo lo demostrarías de forma demostrativa (sin conquistar hosts) y dos contrapartidas que romperían esta técnica en TechNova.

Soluciones

Solución 1. Comando: ssh -L 3306:10.10.10.20:3306 [email protected]. Partes: -L 3306:10.10.10.20:3306 abre en Kali el puerto local 3306 y reenvía todo lo que le llegue, a través de la sesión SSH con el pivote 10.10.10.5, hasta 10.10.10.20:3306 (el MySQL interno); después se conecta con mysql -h 127.0.0.1 -P 3306. Demuestra un fallo de segmentación porque el host de la DMZ tiene conectividad directa al puerto de base de datos de la red interna: un compromiso en la DMZ alcanza datos internos. Lo habría impedido un cortafuegos de segmentación que no permitiera al servidor web hablar con el 3306 interno (solo los flujos estrictamente necesarios), o aislar la base de datos en su propio segmento.

Solución 2. Montaje: (1) túnel dinámico ssh -D 1080 [email protected], que crea un proxy SOCKS en 127.0.0.1:1080 con salida por el pivote; (2) configurar proxychains con socks5 127.0.0.1 1080 en /etc/proxychains4.conf; (3) proxychains nmap -sT -Pn -p 22,80,445 10.10.10.20 (acotando puertos y objetivos). Opciones imprescindibles: -sT (TCP connect, porque SOCKS no tunela paquetes SYN crudos) y -Pn (no hacer descubrimiento ICMP, que tampoco pasa por SOCKS); sin ellas el escaneo falla o da resultados falsos. Detección: monitorización de tráfico este-oeste —un host de la DMZ escaneando puertos de la red interna es un patrón anómalo que un IDS interno o el NDR de TechNova deberían alertar.

Solución 3. El pass-the-hash aprovecha que algunos protocolos de autenticación de Windows aceptan el hash NTLM de la contraseña en lugar de la contraseña en claro; con el hash de svc-admin obtenido en la escalada, uno puede autenticarse en otros hosts que confíen en esa cuenta sin conocer su contraseña real. Demostración demostrativa: validar la credencial contra un host del alcance (p. ej. proxychains crackmapexec smb 10.10.10.31 -u svc-admin -H <hash>) y, con la confirmación de acceso (Pwn3d!), documentar la cadena y parar, sin desplegar payloads ni tomar la máquina. Contrapartidas: (a) modelo administrativo por niveles —que la cuenta admin de una estación no sea válida en el controlador ni en otros hosts, rompiendo el reuso—; (b) LAPS/Credential Guard —contraseñas de admin local únicas y protección de credenciales en memoria—, que reducen el valor del hash robado; complementadas con detección de autenticaciones laterales anómalas.

Conclusión

Hemos medido el alcance del compromiso más allá del primer host. El pivoting convierte una máquina comprometida en pasarela hacia segmentos internos inaccesibles desde fuera —con túneles SSH (local, remoto y dinámico), proxychains y el autoroute de Metasploit— y el movimiento lateral usa las credenciales obtenidas (pass-the-hash, WinRM/PsExec a alto nivel) para demostrar hasta dónde llega el reuso de accesos, siempre de forma demostrativa, documentando la cadena y sin salir del alcance autorizado. La contrapartida fue constante y es el mensaje para TechNova: segmentación, microsegmentación, tiering administrativo, higiene de credenciales y detección de tráfico lateral —romper la red plana que hace posible llegar a todo desde un único punto.

Con la escalada (05-01), la persistencia controlada (05-02) y ahora el alcance en la red (05-03), el impacto del compromiso está prácticamente medido y documentado. Queda una última pieza del módulo, y la abordaremos con el lado defensivo como protagonista: qué haría un atacante para borrar su rastro y, sobre todo, cómo garantiza el defensor la integridad y la trazabilidad de sus registros. Es 05-04 Cobertura de Huellas y Anti-Forense, donde además recordaremos que el pentester profesional hace justo lo contrario: deja un rastro auditable de todo lo que ha hecho.

© Copyright 2026. Todos los derechos reservados