Auditoria Pivoting con Ligolo + Persistencia - Ejercicio

Configuración de red

La infraestructura está configurada para representar el entorno con múltiples segmentos de red y sistemas operativos. Cada máquina está conectada a redes específicas (Vmnet) que permiten controlar el flujo de información.

1. Kali Linux (10.0.1.6) Conectado a Vmnet 1, actúa como la máquina atacante. Desde aquí se inicia el acceso inicial.

2. Windows 7 (10.0.1.4) Conectada simultáneamente a Vmnet 1 y Vmnet 2, actúa como puente entre redes. Es el primer sistema accesible desde Kali y permite el tránsito hacia otros segmentos.

A través de esta máquina se alcanza:

3. Ubuntu (10.0.36.3) Conectada a Vmnet 2, funciona como sistema final.

El primer paso fue verificar la configuración de red de la máquina desde la que estoy trabajando (Kali Linux). Usé el comando ip a para listar las interfaces disponibles y sus direcciones IP.

• La interfaz eth0 está activa y tiene asignada la IP 10.0.1.4/24, lo que indica que estoy dentro del segmento de red 10.0.1.0/24, y mi IP es: 10.0.1.6.

• También se muestra la dirección MAC 08:00:27:0e:8f:6b, útil para identificar el dispositivo en la red.

A continuación, ejecuté el comando netdiscover -r 10.0.1.0/24 que sirve para identificar qué otros dispositivos están activos en el mismo segmento de red.

El escaneo detectó 3 hosts activos:

• 
  

  • 10.0.1.1

  • 10.0.1.2

  • 10.0.1.4

    
    

Cada uno aparece con su dirección MAC y el fabricante del adaptador de red. Aunque no se identifican por nombre, puedo asumir que 10.0.1.1 y 10.0.1.2 son otras máquinas conectadas a Vmnet 1 con las que tengo comunicación directa.

Ping (comando para comprobar si una IP responde)

Para saber a qué IP debo acceder primero, lanzo un ping a 10.0.1.4. Esto me sirve para:

• Ver si la máquina responde.

• Ver el TTL (Time To Live) que devuelve, que me da pistas sobre el sistema operativo.

En este caso, el TTL es 128, lo que indica que el sistema es Windows. Si fuera Linux, el TTL típico sería 64.

Nmap (herramienta para escanear puertos y servicios)

Uso esta herramienta para escanear la IP 10.0.1.4 encontrada anteriormente.

• -sS: escaneo tipo SYN, rápido y discreto.

• -Pn: no hace ping, asume que el host está activo.

• -n: no resuelve nombres DNS, va directo por IP.

• -sVC: detecta versiones de servicios y lanza scripts útiles.

Lo que me salta a la vista aquí es que el sistema es Windows 7, y más concretamente la versión 7600, que es conocida por ser vulnerable a varios ataques, entre ellos:

• EternalBlue: exploit que aprovecha una vulnerabilidad en SMBv1 (puerto 445), usado en ataques como WannaCry

Para comprobar si el sistema Windows 7 que estoy analizando tiene la vulnerabilidad MS17-010, lancé el siguiente comando:

-p445: escanea el puerto 445, usado por SMB (protocolo de compartición de archivos en Windows).

• --script smb-vuln-ms17-010: ejecuta un script que detecta si el sistema es vulnerable a MS17-010, la vulnerabilidad que permite explotar EternalBlue.

• -Pn: no hace ping, asume que el host está activo.

• -n: evita resolver nombres DNS, va directo por IP.

  
  

El sistema devuelve un estado VULNERABLE, confirmando que es susceptible a la vulnerabilidad MS17-010, identificada como CVE-2017-0143. Esta vulnerabilidad permite ejecución remota de código a través de SMBv1, sin necesidad de autenticación.

Después de confirmar que el sistema Windows 7 es vulnerable a MS17-010, decidí utilizar una herramienta específica para explotar esa vulnerabilidad: Win7Blue, disponible públicamente en GitHub.

Win7Blue es una herramienta diseñada para explotar directamente la vulnerabilidad EternalBlue en sistemas Windows 7 sin parches. Permite ejecutar código remotamente aprovechando el fallo en SMBv1, sin necesidad de credenciales ni interacción del usuario objetivo.

Al ejecutar la herramienta Win7Blue, salen varios requisitos a completar…

RHOST: 10.0.1.4 → IP del sistema objetivo.

• LHOST: 10.0.1.6 → IP de mi máquina atacante (Linux).

• LPORT: 4040 → Puerto donde voy a recibir la conexión.

La herramienta genera el shellcode usando msfvenom (generador de payloads en Metasploit), que prepara el código malicioso que se ejecutará en el sistema remoto.

Mientras el exploit se creaba, abrí la escucha con nc (netcat, herramienta para recibir conexiones de red) en mi máquina tal y como se especifica

Esto me permitió recibir la reverse shell desde el sistema Windows 7. La conexión fue exitosa.

Esto significa que ya tengo acceso remoto al sistema, con permisos de usuario, directamente en su consola.

Después de recibir la reverse shell, verifico el nivel de acceso que obtuve en el sistema comprometido.

Al ejecutar whoami, el sistema devuelve:

nt authority\system

Esto confirma que tengo acceso como SYSTEM, el nivel más alto en Windows. Es equivalente a tener control total sobre el equipo, por encima incluso de los administradores.

Luego ejecuté ipconfig para ver la configuración de red del sistema comprometido. El resultado muestra:

• IP: 10.0.2.15

• Gateway: 10.0.2.2

Esto indica que el sistema tiene otra interfaz de red conectada a un segmento distinto (10.0.2.0/24), lo que abre la posibilidad de pivotar hacia esa red y explorar nuevos objetivos.

Desde mi máquina atacante (Linux), levanté un servidor HTTP en el directorio donde tengo Mimikatz (herramienta para extraer credenciales en Windows):

Esto me permite servir el binario de Mimikatz directamente al sistema comprometido, para ejecutarlo desde ahí y extraer hashes, contraseñas en texto plano, tickets Kerberos, etc.

Desde la shell remota, descargué el ejecutable de Mimikatz directamente desde mi máquina atacante usando el siguiente comando:

• certutil.exe: herramienta nativa de Windows para gestionar certificados, pero también útil para descargar archivos.

• -urlcache -f: fuerza la descarga desde una URL.

• Resultado: descarga completada correctamente.

Este comando activa privilegios especiales necesarios para acceder a la memoria del sistema y extraer credenciales

Este comando accede al Security Account Manager (SAM) y extrae los hashes de las contraseñas de los usuarios locales del sistema.

Con estos hashes puedo realizar ataques offline como pass-the-hash, crackeo con John the Ripper, o simplemente usarlos para autenticación en otros sistemas si el mismo hash se repite.

SAMKey: 9214b137a2bcfee4ba0c4bc3fa3b859a

• RID: 000001f4 (500) → Identificador del usuario Administrador.

• Usuario: Administrador

• Hash NTLM: 6ef4a9057cb6270d58d62677cf882200

  
  

Para asegurarme de que la cuenta Administrador está activa y lista para usarse, ejecuté:

Esto confirma que la cuenta está habilitada. Si estaba desactivada por políticas del sistema, ahora puede iniciar sesión o ser usada para autenticación remota.

Decidí probar si podía acceder al sistema usando ese hash directamente, sin necesidad de crackearlo. Para eso utilicé impacket-smbexec (herramienta para ejecutar comandos en sistemas Windows vía SMB usando credenciales o hashes).

• Administrador@10.0.1.4: usuario y IP del sistema objetivo.

• -hashes: opción que permite autenticarse usando el hash NTLM en lugar de la contraseña.

• Herramienta: smbexec lanza una shell semi-interactiva que permite ejecutar comandos en el sistema remoto.

• 
  

Esto es un ataque de tipo pass-the-hash, que funciona cuando el sistema permite autenticación NTLM sin restricciones.

Después de obtener acceso al sistema y confirmar que tengo privilegios SYSTEM, el siguiente paso fue preparar una reverse shell usando PowerShell. Para eso utilicé una herramienta online llamada Reverse Shell Generator, que permite generar payloads personalizados según el tipo de shell y sistema.

En mi máquina atacante (IP: 10.0.1.6), abrí un listener con Netcat (herramienta para recibir conexiones de red)

.

• -nlvp 4001: escucha en el puerto 4001.

• rlwrap: mejora la experiencia de uso permitiendo historial y edición de comandos.

En el generador, seleccioné PowerShell como tipo de shell, y configuré:

• IP: 10.0.1.6

• Puerto: 4001

Esto me genera un comando que, al ejecutarse en el sistema comprometido, conecta de vuelta a mi listener y me da una shell interactiva.

Aunque ya tengo una shell semi-interactiva con smbexec, quiero una reverse shell más estable y funcional, que me permita:

• Tener mejor control del entorno.

• Ejecutar comandos con salida completa.

• Usar herramientas más cómodamente desde el sistema comprometido

Después de generar el payload con Reverse Shell Generator en base64, utilizo netexec para lanzarlo:

netexec (antes CrackMapExec) es una herramienta para interactuar con servicios SMB, RDP, WinRM, etc.

• Permite autenticarse con usuario y contraseña o directamente con hash NTLM.

smb: Es el módulo de netexec que trabaja sobre el protocolo SMB, que opera por el puerto 445.

• 10.0.1.4: IP del sistema objetivo al que apunto.

• -u Administrator: Usuario con el que me estoy autenticando en el sistema remoto.

• -H 'hash_NTLM': Hash NTLM previamente extraido con Mimikatz. Permite hacer pass-the-hash sin conocer la contraseña real.

• -X '<payload PowerShell>': Comando que se ejecutará remotamente. En este caso, es el payload generado con Reverse Shell Generator, codificado en PowerShell para lanzar una reverse shell.­

• --local-auth: Indica que estoy autenticándome contra una cuenta local del sistema, no contra un dominio.

Se recibe la conexión correctamente:

LIGOLO

 https://github.com/nicocha30/ligolo-ng

Ligolo-ng permite crear una interfaz virtual (TUN/TAP) en el sistema atacante que enruta tráfico hacia la red interna del sistema comprometido. Es ideal para pentesting en entornos donde hay segmentación de red y necesitas moverte lateralmente.

Después de comprometer el sistema Windows 7 y obtener una reverse shell estable, el siguiente paso fue establecer un túnel para pivotar hacia otras redes internas.

Comando para iniciarlo:

sudo ip link delete ligolo Elimina cualquier interfaz previa llamada ligolo, por si ya estaba creada.

• sudo ip tuntap add user $USER mode tun ligolo Crea una nueva interfaz TUN llamada ligolo, asociada al usuario actual.

• sudo ip link set ligolo up Activa la interfaz para que pueda empezar a enrutar tráfico.

• sudo ip route add 10.0.36.0/24 dev ligolo Añade una ruta para que todo el tráfico destinado a la red 10.0.36.0/24 se envíe a través de la interfaz ligolo.

Esto significa que ahora puedo escanear, acceder y atacar máquinas dentro de esa red interna como si estuviera conectado directamente a ella.

Después de configurar la interfaz TUN con Ligolo-ng en mi máquina atacante, ejecuté el agente Ligolo desde el sistema comprometido (Windows 7) con el siguiente comando:

Esto establece una conexión entre el agente y el servidor Ligolo en mi máquina atacante. El agente se une correctamente y se inicia la sesión. Esto significa que el túnel está activo y puedo enrutar tráfico hacia redes internas a través del sistema comprometido.

Para comprobar que el pivoting funciona, lancé un ping desde mi máquina atacante hacia la IP interna encontrada previamente en la maquina Windows.

Esto confirma que tengo acceso a la red 10.0.36.0/24, que está detrás del sistema comprometido. El túnel Ligolo-ng está funcionando correctamente.

Escaneo básico para ver que puertos y servicios tiene abiertos la maquina objetivo:

Al ver que tiene abierto el puerto 80, accedí por web para ver si había alguna web a través de: http://10.0.36.3/

Para descubrir rutas ocultas en el servidor web, ejecuté el siguiente comando con Gobuster:

gobuster dir -u http://10.0.36.3/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50

• dir: modo de escaneo de directorios.

• -u http://10.0.36.3/: URL del objetivo.

• -w: especifica el wordlist a usar, en este caso uno medio de DirBuster.

• -t 50: usa 50 hilos para acelerar el escaneo

El escaneo devolvió varias rutas válidas con código 301 (redirección permanente):

• /uploads

• /data

• /scripts

• /index_files

  
  

Después de verificar manualmente cada ruta, encontré contenido interesante en /scripts/

Esta ruta contiene una página que menciona lo siguiente:

"El centro IFP ha creado un directorio llamado 'ifp' donde se ha almacenado información importante sobre la conexión a un servidor."

Después de identificar el directorio /scripts/ y leer el mensaje que mencionaba un subdirectorio llamado ifp, decidí comprobar si existía y qué contenía. Para ello, ejecuté:

El contenido HTML indica que no es una carpeta navegable, sino un enlace directo a un recurso. Dentro del código fuente encontré una referencia a un archivo llamado config.txt

Este comando usa curl, una herramienta para hacer peticiones HTTP desde la terminal, para descargar el contenido del archivo config.txt ubicado en el servidor web en la ruta /ifp/.

En este caso, estás accediendo directamente a un recurso expuesto públicamente en el servidor, sin necesidad de autenticación ni navegación web.

Esto te da acceso potencial a múltiples vectores de entrada, como conexión SSH directa

Usando las credenciales obtenidas previamente desde el archivo config.txt, intenté conectarme al sistema remoto por SSH.

Este comando inicia una sesión SSH con el usuario ifp en la IP 10.0.36.3. Al ingresar la contraseña (Examenifp123!), la conexión fue exitosa.

Este comando muestra información completa del kernel y arquitectura del sistema operativo. Es útil para identificar vulnerabilidades específicas según la versión del kernel.

Esto confirma que estoy dentro de la máquina Ubuntu objetivo con acceso como usuario ifp, listo para comenzar la fase de enumeración local y posible escalada de privilegios.

Al obtener acceso por SSH al sistema remoto como usuario ifp, confirmé que se trataba de una máquina Ubuntu 14.04.6 LTS con kernel 4.4.0-142-generic. Esta versión es antigua y potencialmente vulnerable a múltiples técnicas de escalada local.

En este tipo de entornos, una práctica común es revisar CVEs conocidos que afecten a servicios o componentes instalados por defecto en distribuciones Linux. Uno de los más relevantes es el CVE-2021-4034, también conocido como Polkit pkexec exploit.

• Polkit es un componente presente en muchas distribuciones Linux, incluido Ubuntu.

• El exploit no requiere configuración especial ni dependencias complejas.

• Es efectivo en sistemas con versiones antiguas de Polkit, como las que suelen encontrarse en entornos legacy.

• El sistema objetivo mostraba signos de estar desactualizado, lo que aumenta la probabilidad de que el exploit funcione.

El CVE-2021-4034 afecta a pkexec, una herramienta de Polkit que permite ejecutar comandos como otro usuario (similar a sudo). El problema está en cómo pkexec maneja sus argumentos y variables de entorno.

El fallo técnico

• Cuando pkexec se ejecuta sin argumentos, intenta acceder a una variable que no ha sido inicializada correctamente.

• Esto provoca una condición de escritura fuera de límites (out-of-bounds write) en la pila.

• El exploit aprovecha esta condición para inyectar código malicioso en la ejecución de pkexec.

En resumen: el exploit manipula el entorno de ejecución para que pkexec cargue y ejecute código arbitrario con privilegios de root.

Por eso decidí probar el PoC de este CVE como parte de la fase de escalada local.

https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555

Descargué el PoC desde el repositorio de GitHub en mi máquina Kali principal

Monté un servidor HTTP en mi máquina Kali con Python para servir el archivo al sistema comprometido

Desde la máquina víctima, lo descargué con:

Esto me dejó listo para compilar y ejecutar el exploit directamente desde la sesión SSH.

Después de descargar el PoC del exploit CVE-2021-4034, también conocido como PwnKit, lo compilé directamente en la máquina comprometida.

Este comando usa gcc para compilar el código fuente del exploit y generar un binario llamado pwn.

Al ejecutar el binario,el prompt cambió de $ (usuario normal) a # (superusuario), lo que indica que el exploit funcionó correctamente. Para confirmarlo, ejecuté “whoami”. Esto confirma que he escalado privilegios desde el usuario ifp a root, obteniendo control total sobre el sistema.

Obtención de la flag:

Para mantener acceso al sistema de forma más limpia y estable, decidí crear un nuevo usuario con privilegios administrativos:

1. Creación del usuario:

2. Se crea el usuario valeria junto con su grupo.

3. Se asigna contraseña y se configura el entorno inicial.

2. Elevación de privilegios:

3. Esto añade al usuario valeria al grupo sudo, permitiéndole ejecutar comandos como root.

- Esta técnica es útil para mantener acceso sin depender de exploits, y permite operar con privilegios elevados de forma legítima.

Después de crear el usuario valeria y añadirlo al grupo sudo, realicé una prueba de acceso remoto para confirmar que la persistencia estaba correctamente configurada:

Código

ssh valeria@10.0.36.3

La conexión fue exitosa, y el sistema mostró el banner de bienvenida de Ubuntu 14.04.6 LTS, confirmando que el entorno sigue siendo el mismo.

Escalada a root vía sudo

Una vez dentro, ejecuté:

Código

sudo su

Tras ingresar la contraseña de valeria, obtuve acceso root sin restricciones. Lo confirmé con:

Código

whoami → root

- Esto demuestra que mi usuario valeria tiene privilegios administrativos completos, lo que permite mantener acceso persistente al sistema sin necesidad de recurrir a exploits o shells temporales.