En WhiteRabbit se enumeraron subdominios. Se analizo el codigo fuente de Uptime Kuma para descubrir los ‘Status Page’, observamos dos nuevos subdominios: WikiJs y GoPhish. En el primero se describe un Workflow de n8n, se indica una vulnerabilidad SQLi la cual es “mitigada” con un signature. Se incluye un archivo json donde indica el query y el ‘secret’. Se creo un tamper para sqlmap el cual nos permitio explotar la vulnerabilidad donde, se descubrio acceso a restic y posteriormete aacceso SSH en contenedor docker. Con un servidor restic se obtuvo acceso a SSH. Encontramos un generador de contrasenas en base a tiempo, sabiendo el tiempo de ejecucion, se generaron contrasenas en un rango de tiempo lo que permitio acceder a un nuevo usuario. Finalmente se ejecuto sudo para cambiar a root.
| Nombre | WhiteRabbit |
|---|---|
| OS | Linux |
| Puntos | 50 |
| Dificultad | Insane |
| Fecha de Salida | 2025-04-05 |
| IP | 10.10.11.63 |
| Maker | |
|
Recon
nmap
nmap muestra multiples puertos abiertos: http (80) y ssh (22, 2222).
|
|
Web Site
El sitio web nos redirige al dominio whiterabbit.htb el cual agregamos al archivo /etc/hosts.
|
|
Los headers del sitio muestran un servidor Caddy.
|
|
El sitio describe una ’empresa’ enfocada en servicios de Pentesting.

Se muestran distintas tecnologias y herramientas: n8n, GoPhish, Stalwart Mailserver y Uptime Kuma.

Directory Brute Forcing
feroxbuster unicamente muestra imagenes del sitio.
|
|
Subdomain Discovery
Tras ejecutar ffuf este muestra el subdominio status.
|
|
status.whiterabbit.htb
El subdominio muestra un formulario de login a Uptime Kuma.

Directory Brute Forcing
Tras ejecutar feroxbuster este muestra directorios y direcciones existentes pero tambien muestra multiples que no existen.
|
|
Uptime Kuma
Uptime Kuma es una herramienta de monitoreo, es open source por lo que realizamos la clonacion del repositorio y basandonos en el uso de la ultima version realizamos una busqueda de endpoints que nos permitan obtener informacion.
|
|
De los ’endpoints’ ya conocidos, por el codigo fuente, se muestra que son accesibles tras autenticarse.
|
|
Enumeramos las rutas, encontramos que existe una api: /api/badge/ retorna una imagen svg. Tanto /status/:slug como /api/status-page/:slug, retornan informacion de monitoreo. La primera renderiza la informacion en HTML, en el caso de la api retorna la informacion en formato json.
|
|
Status Pages
Ejecutamos ffuf en el endpoint status/ y encontramos que existe temp/.
|
|
Temp Page
Tras visitar la pagina observamos una lista de sitios siendo ‘monitoreados’. Se muestran dos nuevos subdominios GoPhish y WikiJs (Dev), ambos se agregaron a /etc/hosts.

Asi mismo la api muestra la misma informacion en formato json. Por lo que una enumeracion en la API podria ser /api/status-page/FUZZ
|
|
ddb09a8558c9.whiterabbit.htb
El subdominio de GoPhis redirecciona directamente al login.
|
|

a668910b5514e.whiterabbit.htb
WikiJs muestra directamente una pagina ‘ToDo’ escrita por el administrador.

GoPhish - SQL Injection
En el post GoPhish Webhooks se describe el ‘workflow’ de como la informacion de GoPhish es procesada.

Se explican los datos que son aceptados en el webhook y el mecanismo de ‘seguridad’ que tiene este. Este ultimo se describe en el header x-gophish-signature donde se incluye el ‘Signature HMAC’ del cuerpo, se menciona que este es utilizado para mitigar el riesgo de inyecciones SQL.
Se muestra un ejemplo de una solicitud POST hacia el webhook con los datos y el header con el signature. Ademas se descubre el subdominio 28efa8f7df.whiterabbit.htb el cual se agrego al archivo /etc/hosts.
|
|
Tambien, se incluye el archivo del workflow completo: gophish_to_phishing_score_database.json.
En este archivo encontramos el query que se ejecuta para verificar el score del email en la base de datos. Se especifica mariadb por lo que la base de datos podria ser MySQL.
|
|
Tambien el secret con el cual se calcula el signature o firma del cuerpo.
|
|
El subdominio muestra el login de n8n.

Se realizo una solicitud POST al webhook, este muestra un error donde indica que no se encontro la ‘signature’.
|
|
Como sabemos el workflow muestra que se verifica el email a traves de un query SQL el cual es posible ‘modificar’ ya que lo toma directamente del cuerpo de la solicitud por lo que podria ser vulnerable a SQL Injection. Para modificar el email es necesario crear el signature del cuerpo de la solicitud.
Body Signature
Para recrear el signature tomamos el cuerpo de la solicitud y el hash.
|
|
Escribimos un script en Python para recrear la signature exacta para el cuerpo de ejemplo.
|
|
Tras ejecutar el script logramos recrear el mismo signature del body, por lo que ahora es posible modificar el email para explotar la posible vulnerabilidad SQL Injection.
|
|
Tamper - SQLMap
Creamos un tamper para sqlmap donde toma el payload, lo agrega al body y genera una signature en base a este, tambien, reemplaza las comillas dobles (") por simples (') ya que esto generaria un error en la estructura JSON, finalmente se agrega la signature al header x-gophish-signature. Se agrego el tamper al directorio /usr/share/sqlmap/tamper/.
|
|
SQL Injection
Ejecutamos sqlmap especificando los parametros donde se especifico el tamper recien creado, tambien la base de datos MySQL. Tras la ejecucion sqlmap muestra que la base de datos es MySQL >= 5.0 (MariaDB fork).
|
|
Especificamos --dbs para obtener la lista de bases de datos, se observan tres.
|
|
En la base de datos phishing unicamente existe la tabla victims donde encontramos una lsita de correos.
|
|
En la base de datos temp encontramos una lista de comandos los cuales indican un repositorio backup de restic, se observa una contrasena que parece pertenecer a restic. Tambien vemos algun tipo de generador de contrasenas.
|
|
Restic - Backup
Siguiendo la documentacion de restic especificamos la contrasena y repositorio, tras ello listamos las snapshots, observamos que existe una.
|
|
Restauramos el snapshot especificando el ID y el directorio.
|
|
Protected File
Dentro del directorio encontramos que existe un archivo 7z, intentamos extraer los archivos pero este esta protegido por contrasena.
|
|
Ejecutamos 7z2john para obtener el hash.
|
|
Cracking the Hash
Tras ejecutar john al hash del archivo este encontro la contrasena.
|
|
SSH Files
Tras extraer los archivos encontramos tres.
|
|
Todos pertenecen a SSH: clave privada de bob, publica y el archivo de configuracion donde se especifica el puerto 2222 y el usuario.
|
|
User - Bob (container)
Utilizamos la clave privada con SSH por el puerto 2222 para bob, logrando acceder por este servicio.
|
|
El archivo .dockerenv indica que es un contenedor de docker.
|
|
Observamos que este usuario puede ejecutar como root el comando restic.
|
|
Rest Server
Compilamos y ejecutamos rest-server localmente para poder crear backups en nuestra maquina para luego acceder a estos.
|
|
Bob Rest Repository
Creamos un nuevo repositorio en nuestro servidor especificando un nombre y contrasena.
|
|
Con el repositorio creado especificamos un nuevo backup agregando el archivo /etc/shadow.
|
|
Tras listar estos se observa que se creo un snapshot del archivo.
|
|
Tras restaurar el backup observamos el contenido del archivo.
|
|
Creamos un nuebo backup apuntando al directorio /root.
|
|
Restauramos el backup en el directorio actual.
|
|
Observamos la clave privada y publica del usuario morpheus.
|
|
User - morpheus
Utilizamos la clave privada por el servicio SSH en el puerto 22 logrando acceder a este y la flag user.txt.
|
|
User - Neo
Anteriormente encontramos una lista de comandos en esta se observa la ejecucion de neo-password-generator junto con passwd, es posible que se haya utilizado este comando para generar la contrasena de neo.
|
|
Realizamos la copia de este ejecutable localmente.
|
|
Password Generator
Ejecutamos Ghidra y obtuvimos las funciones que generan la contrasena: main y generate_password.
|
|
Con la ayuda de deepseek se genero el codigo fuente basados en el codigo anterior. El codigo indica una contrasena de 20 caracteres y el uso de “tiempo” Epoch por el uso de gettimeofday, se define el seed el uso de milisegundos.
|
|
Dentro de la base de datos se especifica la fecha y hora de la “ejecucion” del comando, por lo que tenemos un rango de tiempo en el que se haya generado la contrasena.
|
|
Con la ayuda de DeepSeek se genero codigo en base a tiempo para generar contrasenas cada milisegundo en un rango de tres segundos, similar al programa anterior.
|
|
Compilamos y ejecutamos, se observa una larga lista la cual la enviamos a un “wordlist”.
|
|
SSH Bruteforce
Utilizamos hydra con el wordlist creado anteriormente especificando al usuario neo, luego de unos minutos se encontro la contrasena del usuario neo.
|
|
Shell
Utilizamos la contrasena en la sesion SSH existente y logramos cambiar a este usuario.
|
|
Privesc
neo puede ejecutar cualquier comando como root lo que nos permitio elevar privilegios y obtener nuestra flag root.txt.
|
|
Dump Hashes
Realizamos la lectura del archivo /etc/shadow.
|
|