Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: principiante

Sobre este CTF

THLPWN la diseñé como una máquina de iniciación, pero no como una suma de trucos sueltos ni como un recorrido artificial para llegar a root cuanto antes. La idea era construir una cadena muy simple y reconocible: exposición web mínima, una pista relacionada con virtual hosting, un binario distribuido de forma insegura y una configuración de privilegios claramente errónea.

El objetivo no era complicar la explotación, sino enseñar cómo varias decisiones aparentemente menores pueden encadenarse hasta comprometer por completo un sistema. Por eso cada fase está pensada para forzar una lectura concreta: primero entender que el servicio web no responde igual por IP que por nombre, después identificar contenido útil expuesto en el servidor y, por último, comprobar cómo una mala gestión de credenciales y una delegación insegura en sudo convierten un acceso limitado en control total.

El valor del laboratorio está ahí. No en completar la máquina, sino en reconocer una secuencia de fallos que también puede aparecer fuera de un entorno CTF: publicación de artefactos inseguros, credenciales embebidas y privilegios mal delegados.

Información técnica

Descubrimiento de la máquina

La enumeración inicial muestra una superficie muy pequeña, algo deliberado para que el foco no se disperse. La máquina expone únicamente SSH y HTTP:

sudo nmap -p- --open -sCV -Pn -n --min-rate 5000 <IP>

La salida relevante queda resumida así:

22/tcp open  ssh  OpenSSH 9.2p1 Debian 2+deb12u7
80/tcp open  http nginx 1.22.1
http-title: 403 Forbidden

Desde el diseño, esta fase pretende enseñar una idea básica pero importante: no hace falta una superficie amplia para construir una intrusión completa. Dos servicios bastan si el encadenado tiene sentido. SSH no es aquí el punto de entrada inicial, sino el destino de una credencial que todavía no debería estar disponible. HTTP, en cambio, actúa como mecanismo de exposición.

Reconocimiento del servicio web

Accediendo por IP, el servidor devuelve un 403 Forbidden. Esa respuesta no es ruido. Es una pista para orientar la enumeración hacia virtual hosting y obligar al jugador a salir del automatismo de atacar por IP y ya está.

La resolución pasa por añadir el nombre del sitio al archivo hosts local:

echo "<IP> thlpwn.thl" | sudo tee -a /etc/hosts

Con eso ya es posible acceder al sitio correcto en:

http://thlpwn.thl

Esta fase existe para enseñar que el contexto de la petición importa. En entornos normales siguen apareciendo configuraciones en las que un servicio responde de forma distinta según el Host HTTP, y una enumeración pobre puede dejar fuera contenido relevante simplemente por no usar el nombre adecuado.

Enumeración web

Una vez resuelto el virtual host, la siguiente etapa es descubrir contenido expuesto. La enumeración encuentra varias rutas interesantes:

gobuster dir -u http://thlpwn.thl/ \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -x html,txt,php \
  --exclude-length 4478

Resultado relevante:

/downloads
/admin
/assets
/api
/backup
/robots.txt

De todas ellas, la ruta importante en la cadena es /downloads. Ahí aparece un binario disponible para descarga acompañado de una descripción que ya sugiere su papel dentro del laboratorio: contiene problemas de seguridad y puede revelar credenciales SSH.

Esta parte está pensada para representar un error frecuente: publicar artefactos internos o utilidades auxiliares en un servidor accesible sin revisar qué información contienen. No hace falta una vulnerabilidad sofisticada si la propia organización expone material sensible a través de un recurso aparentemente inocuo.

Análisis del binario expuesto

Con el binario descargado, el siguiente paso consiste en inspeccionarlo con técnicas básicas. No hace falta ingeniería inversa avanzada para obtener valor si el artefacto ya arrastra errores de desarrollo evidentes.

La comprobación más directa es:

strings auth_checker

Entre la salida aparecen credenciales en texto plano, que después permiten autenticarse por SSH.

Aquí el aprendizaje es deliberadamente simple: un binario no deja de ser una fuente de información sensible por estar compilado. Muchas veces el problema no es una explotación compleja, sino la presencia de secretos embebidos que sobreviven al proceso de construcción y terminan distribuyéndose sin control. Quise que esta fase obligara a recordar esa idea desde el principio del aprendizaje ofensivo.

Obtención de acceso inicial

Con las credenciales recuperadas del binario, el acceso inicial se consigue a través de SSH:

ssh thluser@<IP>

La entrada al sistema no depende de una evasión complicada ni de una vulnerabilidad remota, sino de una cadena previa de exposición de información. Eso también forma parte del diseño: enseñar que muchas intrusiones no empiezan “rompiendo” un servicio, sino aprovechando secretos filtrados, materiales publicados donde no deben o controles mal separados entre desarrollo y producción.

Una vez dentro, se obtiene la primera bandera de usuario desde el entorno del propio thluser.

Escalada de privilegios

Tras el acceso inicial, la enumeración local muestra el siguiente permiso en sudo:

sudo -l

Salida relevante:

User thluser may run the following commands on thlpwn:
    (ALL) NOPASSWD: /bin/bash

La consecuencia es directa:

sudo /bin/bash

Con esa configuración, el usuario puede abrir una shell como root sin necesidad de contraseña.

Quise que la escalada fuera transparente porque el foco no está en esconder la técnica, sino en reforzar una mala decisión administrativa muy clara: delegar bash en sudo equivale, en la práctica, a entregar el control completo del sistema. En una máquina de iniciación conviene que esa relación entre permiso concedido e impacto quede completamente visible.

También permite introducir una lectura útil para defensa: no todos los fallos de privilegios requieren una cadena rebuscada. A veces basta con revisar qué binarios se han autorizado en sudo y entender qué capacidad efectiva entregan.

Lectura de la cadena completa

La máquina está construida para que cada fase alimente la siguiente sin saltos artificiales:

1. Un servicio web aparentemente pobre devuelve una pista útil.
2. El virtual host correcto expone contenido adicional.
3. Entre ese contenido hay un binario con información sensible embebida.
4. Esa información permite acceso por SSH.
5. El usuario comprometido tiene una delegación de sudo insegura.
6. El resultado final es una shell como root.

La intención era que la cadena se sintiera coherente incluso siendo sencilla. No hay piezas metidas “porque sí”. Cada una representa una categoría de error habitual: exposición innecesaria, gestión deficiente de secretos y privilegios mal definidos.

Qué quería enseñar al diseñar THLPWN

THLPWN está pensada para que quien la juegue entienda que el problema rara vez está en una única acción aislada. Lo que compromete el sistema es la suma de pequeñas decisiones malas que, encadenadas, eliminan barreras una detrás de otra.

La máquina fuerza tres aprendizajes muy concretos. El primero es que la enumeración tiene que adaptarse al comportamiento del servicio y no limitarse a lanzar herramientas de forma automática. El segundo es que distribuir software o utilidades internas sin revisar su contenido puede exponer secretos críticos. El tercero es que una política de sudo mal definida invalida cualquier contención previa.

En conjunto, THLPWN no pretende enseñar un truco concreto, sino una forma de leer una intrusión: observar cómo un fallo de exposición inicial termina conectando con un problema de credenciales y acaba rematado por una mala configuración local.

Recursos y referencias

• Nmap, para descubrimiento de servicios y versiones
• Gobuster, para enumeración de rutas en el virtual host
• strings, como verificación básica sobre binarios expuestos
• GTFOBins, como referencia para interpretar el impacto de binarios permitidos en sudo