CuentaAtrás DockerLabs (Intermediate)
Contexto de la maquina
Trayectoria CuentaAtrás
Descripción
CuentaAtrás es una máquina Linux que combina varios vectores de ataque relacionados con aplicaciones web, autenticación débil, explotación de plugins vulnerables en WordPress y análisis forense de archivos.
El escenario comienza con una aplicación web que implementa un mecanismo de verificación mediante código numérico de cuatro dígitos. Debido a la falta de protecciones adecuadas contra intentos automatizados, este mecanismo puede ser explotado mediante fuerza bruta, permitiendo el acceso a funcionalidades ocultas del sistema.
Posteriormente, el reto continúa con la explotación de un plugin vulnerable de WordPress, lo que permite ejecutar comandos en el servidor. A partir de este punto se realizan varias escaladas de privilegios mediante credenciales expuestas, análisis de archivos y técnicas de esteganografía.
Objetivo del reto
El objetivo consiste en comprometer completamente el sistema:
Acceder al portal protegido
Obtener ejecución remota de comandos
Escalar privilegios entre varios usuarios del sistema
Obtener acceso final como root
Recuperar las flags del sistema
Tipo de máquina
Linux
Web Application
WordPress
Análisis forense / Esteganografía
Habilidades y técnicas evaluadas
Enumeración de servicios con Nmap
Ataques de fuerza bruta sobre códigos OTP
Enumeración de WordPress con WPScan
Explotación de plugins vulnerables
Ejecución remota de comandos (RCE)
Obtención de reverse shells
Fuerza bruta de credenciales SSH
Decodificación Base64
Análisis forense de archivos
Manipulación de cabeceras de archivos
Esteganografía en imágenes
Escalada de privilegios en Linux
Análisis de vulnerabilidades
Instalación
Cuando obtenemos el .zip nos lo pasamos al entorno en el que vamos a empezar a hackear la maquina y haremos lo siguiente.
Nos lo descomprimira y despues montamos la maquina de la siguiente forma.
Info:
Por lo que cuando terminemos de hackearla, le damos a Ctrl+C y nos eliminara la maquina para que no se queden archivos basura.
Escaneo de puertos
Info:
A partir del escaneo observamos que únicamente existen dos puertos abiertos:
22/tcp → SSH
80/tcp → HTTP
El puerto 80 aloja una aplicación web, por lo que procedemos a inspeccionarla accediendo desde el navegador.
Respuesta:
La página muestra un panel de login aparentemente sencillo. En la parte inferior se observa la opción de registro de usuario, por lo que decidimos crear una cuenta para analizar el comportamiento de la aplicación.
Al intentar registrarnos, el sistema nos redirige a un nuevo paso del proceso de verificación.
Fuerza bruta código
Durante el registro observamos que la aplicación solicita introducir un código de verificación enviado al número de teléfono proporcionado. Además, el sistema indica que disponemos de 5 minutos para introducir dicho código.
Sin embargo, como el número de teléfono introducido no existe, no tenemos forma de recibir el código de verificación.
Analizando la funcionalidad, podemos deducir que el código es un valor numérico de 4 dígitos, lo que implica un total de 10.000 combinaciones posibles (0000–9999).
Dado que el espacio de búsqueda es reducido, decidimos desarrollar un script de fuerza bruta en Python que pruebe aproximadamente 100 códigos por segundo, aprovechando múltiples hilos para acelerar el proceso.
El objetivo del script es detectar cuándo el código es correcto observando cambios en la respuesta del servidor, como por ejemplo una redirección HTTP o un cambio en el contenido de la página.
bruteNum.py
Una vez ajustado el script a nuestras necesidades, lo ejecutamos:
Respuesta:
El script detecta que el código 6272 produce un comportamiento distinto en la respuesta del servidor, lo que indica que es el código de verificación correcto.
Con este código podemos completar el proceso de registro e iniciar sesión en la aplicación.
Acceso al portal oculto
Una vez autenticados correctamente, el sistema nos muestra la siguiente página:
Aquí observamos que se revela una ruta oculta dentro de la aplicación, accedemos a dicha ruta::
Respuesta:
Al inspeccionar la página observamos que se trata de una instancia de WordPress.
Sabiendo esto, procedemos a realizar tareas de enumeración de usuarios y plugins para identificar posibles vectores de ataque.
Enumeración con WPScan
Para enumerar usuarios y plugins utilizamos la herramienta wpscan.
Respuesta:
Por lo tanto, tras esta enumeración obtenemos información relevante:
Usuario identificado:
admin_masterPlugins detectados:
akismetwpvivid-backuprestore(versión desactualizada)
Dado que uno de los plugins se encuentra desactualizado, el siguiente paso será investigar posibles vulnerabilidades asociadas a estos plugins, especialmente al plugin wpvivid-backuprestore, que podría proporcionar un vector de explotación.
Escalate user www-data
CVE-2026-1357
Si investigamos un poco más sobre el plugin identificado anteriormente, observamos que la versión 0.9.123 del plugin wpvivid-backuprestore es vulnerable a la vulnerabilidad CVE-2026-1357.
Esta vulnerabilidad permite realizar Remote Code Execution (RCE) en el servidor a través de una funcionalidad vulnerable del plugin. Para explotarla utilizaremos un Proof of Concept (PoC) disponible públicamente.
Repositorio del exploit:
URL = GitHub CVE-2026-1357 Exploit
Procedemos a clonarlo en nuestra máquina atacante.
Una vez descargado el repositorio, creamos un entorno virtual de Python para instalar las dependencias necesarias sin afectar al sistema global.
Con todas las dependencias instaladas, ejecutamos el exploit en modo check para comprobar si el sistema es vulnerable.
Respuesta:
Observamos que el exploit confirma que el sistema es vulnerable, ya que ha sido capaz de subir un archivo al directorio de uploads del servidor.
Ejecución de comandos
Ahora que sabemos que la vulnerabilidad es explotable, vamos a probar la ejecución remota de comandos utilizando el exploit.
Respuesta:
Esto confirma que podemos ejecutar comandos en el sistema como el usuario www-data, que corresponde al usuario del servidor web.
Obtención de Reverse Shell
Para obtener acceso interactivo al sistema, procederemos a crear una reverse shell.
Primero creamos un archivo que contenga la shell reversa.
rev.sh
Una vez creado el archivo, levantamos un servidor HTTP temporal con Python para que la máquina víctima pueda descargarlo.
Con el servidor activo, utilizamos el exploit para descargar el archivo en la máquina víctima utilizando wget.
Si observamos la salida del servidor Python veremos que el archivo ha sido descargado correctamente.
Ahora nos ponemos a la escucha en nuestra máquina atacante:
Finalmente ejecutamos el script desde el servidor víctima utilizando nuevamente el exploit.
Al hacerlo, recibiremos la conexión en nuestro listener.
Esto confirma que hemos obtenido acceso al sistema como el usuario www-data.
Sanitización de shell (TTY)
Escalate user bond
Una vez dentro del sistema comenzamos a enumerar los usuarios existentes.
Respuesta:
Observamos varios usuarios interesantes en el sistema.
Sin embargo, al revisar el directorio /home notamos que no todos los usuarios poseen directorio personal, lo que resulta llamativo en el caso del usuario webmaster.
Después de realizar varias tareas de enumeración sin resultados relevantes, decidimos intentar un ataque de fuerza bruta contra el servicio SSH utilizando los usuarios identificados.
Creamos un archivo con los posibles usuarios.
users.txt
Utilizamos la herramienta hydra para realizar el ataque.
Respuesta:
Observamos que el usuario bond utiliza una contraseña extremadamente débil 999999999 con estas credenciales nos conectamos al sistema mediante SSH.
Metemos como contraseña 999999999...
Hemos accedido correctamente al sistema como el usuario bond.
Finalmente leemos la flag correspondiente al usuario.
user.txt
Escalate user ethan
Después de un rato realizando tareas de enumeración en el sistema, encontré un archivo llamado:
Inicialmente lo pasé por alto varias veces, pero tras revisarlo con más detenimiento observé que contenía una petición HTTP completa, incluyendo una cookie sospechosa. Tras intentar reutilizar dicha cookie en diferentes contextos sin éxito, decidí analizar su contenido.
copy2321_.php
La cookie session_id parece estar codificada en Base64, por lo que procedemos a decodificarla.
Respuesta:
Observamos que el contenido decodificado corresponde a credenciales en texto plano, pertenecientes al usuario ethan.
Con esta información procedemos a cambiar de usuario.
Metemos como contraseña pfLmWVz2EGKGpRCmACTP...
De esta forma conseguimos escalar privilegios al usuario ethan.
Escalate Privileges
Tras acceder como ethan, observamos que cada cierto tiempo la sesión se cierra automáticamente mostrando el siguiente mensaje:
Esto indica que existe algún mecanismo de auto logout asociado a la shell utilizada.
Para evitar este comportamiento, intentamos iniciar rápidamente una shell alternativa utilizando sh.
Una vez dentro de esta shell observamos que la sesión ya no se cierra automáticamente, por lo que podemos continuar con la enumeración del sistema sin interrupciones.
Enumeración de directorios
Accedemos al directorio personal del usuario ethan y encontramos una carpeta llamada miscosas.
Dentro de ella observamos la siguiente estructura:
De todas las carpetas listadas, únicamente la carpeta fotos contiene un archivo.
En su interior encontramos una imagen llamada:
Transferencia del archivo
Para analizar el archivo en nuestra máquina atacante, levantamos un servidor HTTP temporal con Python.
Desde nuestra máquina atacante descargamos el archivo:
Análisis del archivo
Si intentamos abrir la imagen directamente observamos que no se comporta como una imagen válida.
Por ello analizamos el tipo de archivo con file.
Respuesta:
El sistema no reconoce el archivo como una imagen válida, por lo que procedemos a inspeccionar su cabecera en hexadecimal.
Respuesta:
Observamos que los primeros bytes corresponden a la cabecera de un archivo PNG:
Sin embargo, el archivo tiene extensión .jpg.
Esto ya indica que algo no encaja correctamente con el formato del archivo.
Análisis del final del archivo
Si analizamos los últimos bytes del archivo utilizando xxd, podemos observar cómo termina realmente el fichero.
Respuesta:
En esta parte observamos algo interesante: el archivo termina con los bytes FF D9, que corresponden al marcador de finalización (EOI — End Of Image) de un archivo JPEG.
Esto resulta extraño, ya que anteriormente habíamos visto que el archivo comenzaba con una cabecera de PNG (89 50 4E 47). Este comportamiento indica que el archivo probablemente está manipulado, mezclando elementos de diferentes formatos de imagen.
En otras palabras, todo apunta a que el archivo realmente es un JPG, pero se ha añadido una cabecera PNG falsa al inicio con el objetivo de confundir o dificultar el análisis.
Para comprobar si existe una cabecera válida de JPEG dentro del archivo, buscamos el marcador de inicio de este formato (FF D8).
Sin embargo, no encontramos ningún resultado. Esto puede ocurrir si el inicio del archivo ha sido sobrescrito o modificado.
Una técnica útil en estos casos es buscar el marcador FF DB, que corresponde a Define Quantization Table, una estructura típica que aparece al inicio de muchos archivos JPEG después de la cabecera.
Respuesta:
Observamos que el marcador aparece en la línea 6. Esto nos da una pista clara: el archivo contiene estructuras internas propias de JPEG.
Si FF DB aparece aproximadamente en el offset 0x5A, el marcador FF D8 debería encontrarse unos bytes antes. Sin embargo, en nuestro caso el archivo comienza con:
que corresponde a la cabecera de PNG.
Esto confirma que el archivo tiene una cabecera PNG falsa insertada delante de los datos reales del JPG.
En otras palabras, el archivo original JPEG sigue presente, pero su cabecera fue modificada para ocultar su formato real.
Reparación del archivo
Para recuperar la imagen original, vamos a reemplazar manualmente la cabecera incorrecta por una cabecera válida de JPEG.
Primero instalamos un editor hexadecimal:
Una vez dentro del editor, nos posicionamos al inicio del archivo y reemplazamos los primeros bytes por una cabecera estándar de JPEG (JFIF):
Respuesta:
Pasted image 20260312100517.png
Guardamos el archivo y verificamos nuevamente su tipo:
Respuesta:
Ahora el sistema reconoce correctamente el archivo como una imagen JPEG válida, lo que indica que la reparación ha funcionado.
Análisis de la imagen
Abrimos la imagen para inspeccionarla visualmente:
Respuesta:
A simple vista no parece haber nada especialmente relevante, por lo que el siguiente paso lógico es comprobar si la imagen contiene información oculta mediante esteganografía.
Esteganografía
Instalamos la herramienta steghide, que permite ocultar y extraer datos dentro de imágenes.
A continuación realizamos un ataque de diccionario utilizando la wordlist rockyou para intentar extraer contenido oculto.
Respuesta:
Una vez encontrada la contraseña correcta, analizamos el archivo extraído.
output_dinamo.txt
Observamos que el contenido corresponde a una cadena que parece ser una contraseña, por lo que probamos si puede utilizarse para acceder al usuario root.
Metemos como contraseña hGRjVqry0tcVYpgvVjzm...
Accedemos correctamente al usuario root, completando así la escalada de privilegios.
Al igual que antes, ejecutamos una shell con sh para evitar que la sesión se cierre automáticamente.
Finalmente leemos la flag del sistema.
root.txt
Last updated