Autor: Oscar | Senior Platform Engineer / SRE
Plataforma: TheHackersLabs | Dificultad: Principiante | SO: Linux

Sobre este CTF

Este CTF lo diseñé para TheHackersLabs con una idea muy concreta: mostrar cómo una cadena de fallos pequeños, pistas mal protegidas y credenciales expuestas puede terminar en compromiso total del sistema.

No es una máquina pensada para meter ruido ni para esconder la solución detrás de trucos absurdos. El objetivo es que quien la resuelva entienda algo importante: muchas intrusiones no empiezan con una vulnerabilidad sofisticada, sino con malas decisiones básicas en publicación de contenido, autenticación y administración.

En este writeup explico la resolución completa de la máquina, desde el reconocimiento inicial hasta la obtención de acceso como root, y dejo claro qué error representa cada paso dentro de un escenario realista.

Información técnica

Reconocimiento

Verificación de conectividad

Antes de enumerar servicios, comprobamos que la máquina responde en red desde nuestro entorno de trabajo.

ping -c 1 10.10.10.37

Salida:

PING 10.10.10.37 (10.10.10.37) 56(84) bytes of data.
64 bytes from 10.10.10.37: icmp_seq=1 ttl=64 time=1.87 ms

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

Conectividad confirmada. A partir de aquí ya podemos pasar a la enumeración de servicios.

Escaneo y enumeración

Para identificar puertos abiertos, versiones de servicios y pistas útiles, realizamos un escaneo completo con Nmap:

nmap -sVC -p- -T4 10.10.10.37

Resultado:

PORT      STATE SERVICE               VERSION
22/tcp    open  ssh                   OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
8088/tcp  open  http                  Apache httpd 2.4.62 ((Debian))
10000/tcp open  ssl/snet-sensor-mgmt?
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=debian/countryName=US
| Subject Alternative Name: DNS:debian, DNS:localhost
| Not valid before: 2024-12-09T08:17:52
|_Not valid after:  2029-12-08T08:17:52
| fingerprint-strings:
|   GetRequest, HTTPOptions:
|     HTTP/1.0 200 Document follows
|     Server: MiniServ
|     Auth-type: auth-required=1
|     Set-Cookie: redirect=1; path=/; secure; httpOnly
|     Set-Cookie: testing=1; path=/; secure; httpOnly
|     X-Frame-Options: SAMEORIGIN
|     Content-type: text/html; Charset=UTF-8

Análisis inicial

Este escaneo ya nos deja una ruta bastante clara:

• Puerto 22: SSH disponible, pero sin credenciales todavía.
• Puerto 8088: servidor web en Apache. Probable punto de entrada inicial.
• Puerto 10000: servicio MiniServ, que encaja con una instalación de Webmin.

A nivel ofensivo, esto ya dibuja una posibilidad razonable: encontrar una credencial en la web y reutilizarla en otro servicio administrativo.

Revisión de los servicios web

1. Sitio en el puerto 8088

Al revisar la web del puerto 8088, a simple vista no aparece nada especialmente sensible. Sin embargo, al inspeccionar su contenido se observan varios fragmentos codificados en Base64.

Uno de ellos:

echo "Q2FtcGFuYSBzb2JyZSBjYW1wYW5hCgpZIHNvYnJlIGNhbXBhbmEgdW5hCgpBc8OzbWF0ZSBhIGxhIHZlbnRhbmEKClZlcsOhcyBlbCBuacOxbyBlbiBsYSBjdW5hCg==" | base64 -d

Resultado:

Campana sobre campana

Y sobre campana una

Asómate a la ventana

Verás el niño en la cuna

Otro fragmento:

echo "Q2FtcGFuYSBDYW1wYW5hIENhTXBBTkEgQ2FNcGFOYQo=" | base64 -d

Resultado:

Campana Campana CaMpANA CaMpaNa

Comentario

Aquí no hay una vulnerabilidad técnica compleja. Hay una mala práctica clara: dejar pistas semiescondidas que terminan exponiendo un posible nombre de usuario.

La palabra campana aparece con demasiada insistencia como para ignorarla. En una máquina de nivel principiante, eso suele ser suficiente para orientar el siguiente paso.

Fuzzing sobre el sitio web

Como la revisión manual no muestra todo el contenido expuesto, ampliamos superficie con dirsearch:

dirsearch -u http://10.10.10.37:8088

Resultado relevante:

[200] /shell.php

La ruta /shell.php devuelve una página de autenticación. Eso cambia por completo la lectura del escenario: ya no estamos solo ante una web con pistas, sino ante un portal potencialmente sensible.

Análisis

Este hallazgo es importante porque el sistema ya nos ofrece dos piezas encadenables:

1. Un posible usuario: campana
2. Un formulario de login accesible en /shell.php

Cuando una aplicación expone un panel de acceso adicional y además deja pistas de identidad en el contenido público, el siguiente paso lógico es comprobar la solidez de las credenciales.

Fuerza bruta sobre shell.php

Probamos autenticación contra el formulario usando Hydra, con el usuario campana y el diccionario rockyou.txt:

hydra -l campana -P rockyou.txt 10.10.10.37 -s 8088 http-post-form "/shell.php:username=^USER^&password=^PASS^:Username or password invalid"

Resultado:

[8088][http-post-form] host: 10.10.10.37   login: campana   password: lovely

Credencial válida obtenida:

• Usuario: campana
• Contraseña: lovely

Comentario

El fallo aquí no es Hydra. El fallo real es otro:

• usuario predecible
• contraseña débil
• formulario accesible públicamente
• mensaje de error lo bastante claro como para automatizar el ataque sin dificultad

Es la clase de cadena que sigue apareciendo en entornos mal cuidados. Nada sofisticado. Solo controles básicos ausentes.

Acceso a shell.php

Accedemos al portal con las credenciales obtenidas y comprobamos que no se trata de un panel cualquiera, sino de un ejecutor de comandos.

Esto ya supone una ruptura clara del sistema, porque nos da capacidad de explorar el host sin necesidad de shell interactiva inicial.

Tras revisar directorios y contenido disponible, aparece un punto especialmente interesante dentro de /opt.

ls /opt

En ese directorio encontramos un archivo con información útil para el siguiente salto:

cat /opt/Webmin.txt

Contenido relevante recuperado:

• Usuario: santaclaus
• Contraseña: FelizNavidad2024

Análisis

Este paso representa otro error clásico: secretos administrativos almacenados en rutas accesibles desde componentes inseguros.

Una vez que un panel web permite ejecución de comandos, cualquier credencial dejada en texto plano dentro del sistema pasa a ser material de explotación directa.

Acceso a Webmin

Con las credenciales encontradas, accedemos al servicio del puerto 10000, que corresponde a Webmin.

Dentro del panel, tras revisar sus secciones, encontramos una funcionalidad crítica dentro de herramientas administrativas: ejecución de comandos, y además con contexto privilegiado.

Eso cierra la cadena de explotación. Ya no dependemos de un usuario intermedio ni de un truco local. La propia consola de administración nos entrega ejecución como root.

Comentario

Aquí la máquina enseña algo muy simple y muy real:

No basta con tener un panel de administración protegido con usuario y contraseña. Si esa credencial acaba expuesta en el sistema, el panel deja de ser una medida de seguridad y pasa a ser una vía directa de compromiso total.

Obtención de shell como root

Para operar con más comodidad, levantamos un listener desde nuestra máquina atacante:

nc -lvnp 1234

Después, desde la consola de comandos de Webmin, enviamos una reverse shell hacia nuestro host.

En el listener recibimos conexión:

connect to [10.10.10.20] from (UNKNOWN) [10.10.10.37] 37494

Comprobación:

whoami
id
ls

Resultado:

root
uid=0(root) gid=0(root) groups=0(root)
root.txt
webmin-1.920
webmin-1.920.tar.gz

Ya tenemos acceso completo al sistema.

Notas del autor

Aunque esta máquina es de nivel principiante, no está pensada para regalar una shell sin más. Está diseñada para enseñar una secuencia muy concreta de errores que aparecen con demasiada frecuencia:

Mi intención con esta máquina fue clara: demostrar que no hace falta una cadena compleja de CVEs para comprometer un sistema. A veces basta con juntar una pista pública, una contraseña mala y una administración descuidada.

Recursos y referencias

• Nmap
• Hydra
• Dirsearch
• Webmin