Black-box penetration test contra HackSudo Thor : CVE-2014-6271 Shellshock RCE a través de Apache mod_cgi, encadenado con una mala configuración de sudo e inyección de eval de bash para la escalada de privilegios completa. Incluye herramientas personalizadas de fuerza bruta conscientes de CSRF y automatización de Metasploit RPC.
heventafese/penetration-testing-walkthrough-hacksudo-thor
Objetivo: HackSudo Thor de VulnHub
Objetivo: Obtener acceso root y leer/root/proof.txt
Entorno: Laboratorio aislado de VirtualBox segmentado por un firewall pfSense
Este repositorio documenta una prueba de penetración de caja negra parcial realizada en HackSudo Thor, una máquina virtual intencionalmente vulnerable publicada en VulnHub por Vishal Waghmare. El objetivo era simular un ataque del mundo real donde un atacante externo intenta comprometer un sistema interno aislado con el objetivo principal de obtener acceso root y leer el contenido de /root/proof.txt.
La evaluación sigue el ciclo completo de pruebas de penetración: reconocimiento pasivo, descubrimiento de red, enumeración, evaluación de vulnerabilidades, explotación, escalada de privilegios, post-explotación y cobertura de huellas.
Las herramientas principales utilizadas fueron Nmap para el escaneo de red, Nessus para la evaluación de vulnerabilidades y Metasploit Framework como la principal plataforma de explotación y post-explotación. Se utilizaron John the Ripper, Hashcat y tablas Rainbow en línea durante la etapa de craqueo de contraseñas, aunque todos los intentos fueron finalmente infructuosos debido a la fortaleza del algoritmo hash en uso.
El laboratorio virtual fue construido completamente en VirtualBox y diseñado para simular una red empresarial realista con tres zonas de seguridad distintas, todas gestionadas por un firewall pfSense 2.7.2. Las tres redes NAT se configuraron de la siguiente manera: una zona WAN que simula Internet público donde reside la máquina atacante Kali, una zona DMZ que alberga la máquina objetivo, y una zona LAN interna que contiene máquinas fuera del alcance.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Zonas de seguridad de la topología lógica de red gestionadas por pfSense*
La interfaz WAN recibió `10.0.2.8/24` por DHCP, la interfaz LAN se configuró como `10.0.3.1/24`, y la interfaz OPT1 (DMZ) se configuró como `10.0.4.1/24`. Para introducir una mala configuración deliberada en el laboratorio, se dejó intencionalmente expuesto el puerto 80 en la interfaz WAN de pfSense, simulando una exposición común de panel de administración en el mundo real que sirvió como punto de entrada principal a la red interna.
---
## Resumen de la Cadena de Ataque```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Antes de realizar cualquier contacto con el entorno objetivo, se recopiló información exclusivamente de fuentes públicas. Las dos fuentes principales fueron la página oficial de entrada en VulnHub para HackSudo Thor y el perfil público de GitHub del autor.
La página de VulnHub confirmó que el objetivo era un sistema basado en Linux, clasificado como de dificultad fácil a media, con el objetivo de encontrar la bandera proof.txt. Revisar el perfil de GitHub del autor proporcionó información adicional. Vishal Waghmare diseña constantemente máquinas Linux boot-to-root donde la escalada de privilegios es el desafío central en toda la serie HackSudo. Esto moldeó el modelo de amenazas al entrar en las fases activas: los servicios HTTP y SSH eran la superficie de ataque más probable, y se predijo que la ruta de escalada implicaría una mala configuración de sudo, abuso de binarios SUID o la explotación de un servicio personalizado.
Este tipo de análisis de patrones del autor también es importante en un compromiso real. Comprender cómo se diseñó probablemente un sistema y qué categorías de debilidad es probable que repita su administrador proporciona dirección antes de enviar un solo paquete.
Esta fase implicó realizar contacto activo directo con el entorno. El objetivo era identificar todos los hosts activos, comprender el límite de la red y construir una imagen de la superficie de ataque completa antes de centrarse en el objetivo principal.
Primero se ejecutó un barrido ping ligero de Nmap (-sn) contra la subred WAN (10.0.2.0/24) para descubrir hosts activos con el mínimo ruido. Se identificaron tres hosts: 10.0.2.1 y 10.0.2.2 eran direcciones estándar de infraestructura de VirtualBox, lo que dejó a 10.0.2.8 como el único host no perteneciente a la infraestructura. Esa máquina se convirtió en el foco inmediato.
Un escaneo SYN sigiloso completo contra 10.0.2.8 no devolvió ningún resultado. Esto era un comportamiento esperado, no un error. Los firewalls empresariales están diseñados para no responder a los escaneos de puertos, descartando paquetes silenciosamente en lugar de responder. La ausencia de resultados fue en sí misma la confirmación de que se trataba de un dispositivo de límite de red que filtraba activamente el tráfico.
Para confirmar qué servicios se estaban ejecutando realmente sin depender del escaneo de paquetes, se emitió una solicitud HTTP directa usando curl. Se adoptó este enfoque porque una solicitud web estándar tiene muchas menos probabilidades de ser filtrada que una herramienta de escaneo. La respuesta llegó como HTTP/1.1 200 OK con Server: nginx y un título de página pfSense, confirmando que el webConfigurator era accesible directamente en el puerto 80 desde la interfaz WAN.
Con la página de inicio de sesión confirmada, el siguiente paso fue intentar recuperar las credenciales. Inicialmente se seleccionó Hydra como herramienta de fuerza bruta, pero este intento falló por dos razones. La primera fue práctica: rockyou.txt contiene más de 14 millones de entradas, lo que lo hace poco práctico dentro del plazo de esta evaluación. La segunda fue técnica y más significativa: pfSense 2.7.2 implementa protección de tokens CSRF, generando un token criptográfico único en cada carga de página que debe enviarse junto con las credenciales. El módulo HTTP POST de Hydra envía un cuerpo de solicitud estático y no tiene ningún mecanismo para obtener dinámicamente un token nuevo por intento, por lo que cada envío fue rechazado antes de que se verificara la contraseña.
Para solucionar esto, se escribió un script Python personalizado que replica el proceso completo de inicio de sesión del navegador. Para cada intento de contraseña, el script abre una nueva sesión, carga la página de inicio de sesión, extrae el token CSRF actual del formulario HTML y luego envía las credenciales junto con ese token exactamente como lo haría un navegador. Se creó una lista de palabras personalizada usando CeWL para rastrear la página de inicio de sesión de pfSense y extraer términos relevantes, luego se complementó con fasttrack.txt para cubrir credenciales predeterminadas conocidas.
El script recuperó las credenciales: admin / pfsense, las predeterminadas sin cambios.
Script Python personalizado recuperando credenciales de pfSense
Con acceso al panel de control establecido, se revisó la configuración de la interfaz de pfSense para comprender la topología interna completa. Esto reveló dos subredes que habían sido invisibles desde la WAN: una LAN en 10.0.3.0/24 y una DMZ en 10.0.4.0/24. Luego se deshabilitaron las reglas del firewall WAN a través de la interfaz web y se agregaron dos reglas de paso para permitir el tráfico desde la IP del atacante hacia ambas subredes.
Los barridos ping de Nmap en ambas subredes identificaron seis hosts activos. Se enumeraron cuatro de ellos, excluyendo 10.0.4.1 y 10.0.3.1, que pertenecían a las interfaces de puerta de enlace de pfSense. Se ejecutó un escaneo combinado de enumeración de servicios con detección de versiones, scripts NSE predeterminados y huellas dactilares del SO contra los cuatro simultáneamente. Al cotejar los resultados con el reconocimiento pasivo se identificó cada máquina en la topología:
El objetivo se confirmó como 10.0.4.3. Toda la actividad posterior se centró exclusivamente en esta máquina.
Una vez identificado el objetivo, se realizó un análisis más profundo de sus servicios para mapear la superficie de ataque y determinar rutas de explotación viables. Se utilizó Metasploit Framework como plataforma principal para esta fase, específicamente porque su backend PostgreSQL persiste todos los resultados de escaneo entre sesiones: hosts, servicios y vulnerabilidades, todos almacenados en la base de datos y disponibles para consultar durante fases posteriores sin necesidad de reescanear.
Antes de comenzar, se inicializó Metasploit con msfdb init, se verificó la conexión a la base de datos con db_status, y todo el trabajo posterior se realizó desde dentro de msfconsole.
Se utilizó el comando db_nmap para ejecutar un escaneo completo contra 10.0.4.3: escaneo SYN sigiloso, detección de versiones de servicios, scripts NSE predeterminados, huellas dactilares del SO y los 65,535 puertos TCP. Los resultados se almacenaron automáticamente en la base de datos y se recuperaron con hosts y services. Se confirmaron tres servicios abiertos: FTP en el puerto 21 ejecutando Pure-FTPd, SSH en el puerto 22 ejecutando OpenSSH 7.9p1 y HTTP en el puerto 80 ejecutando Apache 2.4.38.
Cada servicio se enumeró posteriormente utilizando módulos auxiliares específicos de Metasploit. El servicio HTTP recibió la mayor atención. Los módulos dir_scanner y http_crawler se utilizaron para mapear todas las rutas y endpoints accesibles en el servidor web. El hallazgo más significativo de esto fue el directorio /cgi-bin/ y un script llamado shell.sh. Por separado, una revisión manual del código fuente HTML de news.php reveló un comentario oculto del autor que hacía referencia al directorio /cgi-bin/, una pista deliberada que apuntaba hacia una vulnerabilidad basada en CGI. Se verificó el servicio FTP para acceso anónimo (deshabilitado) y se anotó la cadena de versión para su referencia cruzada con CVE. Se recuperó el banner SSH con el mismo propósito.
Con la superficie de ataque completamente mapeada, se realizó una evaluación de vulnerabilidades estructurada utilizando dos enfoques: un escaneo automatizado con Nessus y el razonamiento manual del atacante aplicado a cada servicio.
Se creó una política personalizada de Nessus con el escaneo CGI y las pruebas de aplicaciones web explícitamente habilitadas, apuntando a los puertos 21, 22 y 80. Esta configuración no está habilitada por defecto y fue crítica aquí; sin ella, el endpoint CGI no habría sido probado. El escaneo se ejecutó durante aproximadamente 11 minutos y devolvió 41 hallazgos totales. Los hallazgos procesables fueron:
Los dos hallazgos de Shellshock en /cgi-bin/shell.sh fueron inmediatamente la prioridad. CVE-2014-6271 tiene una puntuación CVSS de 9.8 y permite la ejecución remota de código no autenticada, el hallazgo de mayor impacto en el escaneo. CVE-2014-6278 representa un parche incompleto de la misma vulnerabilidad, lo que significa que incluso los sistemas parcialmente parcheados siguen siendo explotables. La debilidad Terrapin en SSH se evaluó como no explotable sin una posición de intermediario (man-in-the-middle). Los hallazgos restantes no tenían un valor de explotación significativo en este compromiso.
Antes de pasar a la explotación, el hallazgo de Shellshock se verificó de forma independiente utilizando el script NSE http-shellshock de Nmap dirigido directamente a /cgi-bin/shell.sh. La verificación independiente antes de la explotación es un paso importante en la metodología, ya que confirma que la vulnerabilidad es real y no un falso positivo del escáner, y evita perder el tiempo intentando un exploit que no funcionará. El script NSE confirmó que el endpoint era vulnerable, y se seleccionó CVE-2014-6271 como vector de ataque principal.
Con Shellshock confirmado, comenzó la fase de explotación. La vulnerabilidad existe porque Apache mod_cgi pasa los encabezados de solicitud HTTP como variables de entorno a Bash cuando se invoca un script CGI. En una versión no parcheada de Bash, una definición de función especialmente manipulada en una variable de entorno hace que cualquier comando añadido después de la definición se ejecute inmediatamente. Al inyectar este payload en el encabezado User-Agent de una solicitud a /cgi-bin/shell.sh, se podían ejecutar comandos arbitrarios en el servidor sin ninguna autenticación.
El módulo de Metasploit exploit/multi/http/apache_mod_cgi_bash_env_exec automatiza todo esto. El módulo se configuró con RHOSTS establecido en 10.0.4.3, TARGETURI establecido en /cgi-bin/shell.sh, el payload establecido en linux/x86/meterpreter/reverse_tcp, y el listener apuntando de vuelta a la máquina Kali en el puerto 4444. Al ejecutar el módulo, se envió la solicitud maliciosa, el servidor ejecutó el payload y Metasploit recibió la conexión entrante, estableciendo una sesión de Meterpreter como www-data.
Exploit de Shellshock ejecutado y shell inversa de Meterpreter establecida como www-data
Comenzando desde www-data, inicialmente se desconocía el alcance del acceso al sistema. La prioridad inmediata era comprender la posición actual: quién era el usuario activo, qué otras cuentas existían y qué caminos estaban disponibles hacia privilegios más altos.
La sesión de Meterpreter se degradó a un shell del sistema sin procesar y se generó un pseudo-terminal utilizando el módulo pty de Python para crear una terminal interactiva adecuada. La lectura de /etc/passwd y el listado de /home/ confirmaron un usuario llamado thor en el sistema. Un ls -la /home/thor/ inicial devolvió "permiso denegado", por lo que se buscó en el sistema de archivos cualquier archivo propiedad de thor independientemente de los permisos del directorio usando find / -user thor 2>/dev/null. Esto localizó un binario anómalo en /usr/local/sbin/ls, un archivo llamado ls que no era el binario estándar del sistema. Su contenido reveló que era un script personalizado propiedad de Thor, que se anotó para su posterior investigación.
El paso posterior a la explotación estándar de verificar los permisos sudo del usuario actual se realizó con sudo -l. Esto reveló que www-data tenía permiso para ejecutar /home/thor/hammer.sh como el usuario thor sin necesidad de contraseña, una regla NOPASSWD sin justificación operativa legítima.
sudo -l confirmando que www-data puede ejecutar hammer.sh como thor sin contraseña
El acceso directo para leer hammer.sh estaba bloqueado por los permisos del directorio, por lo que se ejecutó primero con sudo -u thor /home/thor/./hammer.sh para observar su comportamiento. El script presentó dos indicaciones interactivas: una "Clave Secreta" y un "Mensaje Secreto". La primera indicación repetía la entrada como un saludo. La segunda procesaba la entrada y luego salía. La distinción entre estos dos comportamientos era significativa: si ambas indicaciones simplemente repetían la entrada, ninguna sería interesante. El hecho de que la segunda indicación procesara la entrada antes de responder sugería que estaba pasando el valor a un comando del shell, un patrón consistente con una declaración eval, que es una superficie de ataque de inyección de comandos bien documentada.
En una segunda ejecución, se pasó una entrada en blanco a la primera indicación. El payload de inyección bash -i se suministró a la segunda. Esto generó un shell interactivo como thor.
Payload bash -i inyectado en hammer.sh
Se ejecutó sudo -l nuevamente como thor. Esto reveló acceso NOPASSWD sin restricciones tanto a /usr/bin/cat como a service como root. La regla service fue la más significativa. La técnica sudo service de GTFOBins permite pasar una cadena de path traversal como argumento del nombre del servicio. Proporcionar ../../bin/bash hace que el binario service resuelva la travesía e invoque /bin/bash con privilegios de root.```bash
sudo service ../../bin/bash
Esto produjo una shell de root completa.
*Shell de root obtenida mediante GTFOBins - path traversal de servicio sudo confirmado*
## Fase 7: Post-Explotación
Con la identidad de root confirmada, la fase de post-explotación se centró en tres áreas: comprender el entorno del sistema, extraer datos sensibles y establecer acceso persistente.
### Información del Sistema y Flag
Primero se realizó una enumeración básica del sistema para confirmar la identidad del objetivo y establecer contexto para las recomendaciones de remediación, incluyendo la versión del kernel, la versión del sistema operativo y la configuración de red. Se confirmó que el sistema era Debian GNU/Linux 10 (Buster) ejecutando el kernel 4.19.0-17-686-pae en `10.0.4.3`.
Se listó el directorio home de root, que reveló `proof.txt` y `root.txt`. Se leyó el archivo `proof.txt` para capturar el flag principal, el objetivo declarado de este engagement.
*Contenido de proof.txt - flag principal capturado*
### Extracción de Credenciales y Craqueo de Contraseñas
Los archivos `/etc/shadow` y `/etc/passwd` se copiaron a `/tmp` y se descargaron a la máquina atacante mediante Meterpreter. Estos dos archivos juntos proporcionan las cuentas de usuario del sistema y los hashes de contraseñas necesarios para el craqueo offline.
Se intentaron varios enfoques de craqueo. John the Ripper identificó ambos hashes como SHA-512crypt con un factor de costo de 5.000 iteraciones. Un primer intento usando `rockyou.txt` se abortó tras ejecutarse durante horas sin resultados. El costo computacional de SHA-512crypt hace que los ataques de diccionario exhaustivos sean muy lentos sin aceleración por GPU. Un segundo intento con una lista de palabras personalizada y dirigida, construida a partir de inteligencia recolectada durante el reconocimiento, se completó rápidamente pero no devolvió coincidencias.
CrackStation se probó a continuación como un servicio online de tablas arcoíris, pero devolvió un formato de hash no reconocido para ambas entradas. Esto era de esperar: SHA-512crypt añade una sal aleatoria única a cada hash antes de aplicar el hash, lo que significa que la misma contraseña produce un hash diferente para cada cuenta. Las tablas arcoíris funcionan precomputando hashes para contraseñas conocidas, pero se necesitaría una tabla separada para cada valor de sal posible, lo que hace que el enfoque sea completamente impráctico contra hashes con sal.
Hashcat se usó para los intentos finales, con tres listas de palabras en sucesión: `fasttrack.txt` (agotado en 4 segundos), una lista personalizada dirigida (agotada sin coincidencia), y las 100.000 entradas principales de `rockyou.txt` (falló después de 3 minutos). Todos los intentos de craqueo de contraseñas no tuvieron éxito. El uso de SHA-512crypt con sal y un alto número de iteraciones es la razón: el algoritmo está diseñado para ser computacionalmente costoso, precisamente para resistir este tipo de ataque offline.
### Búsquedas de Claves SSH
También se realizó una búsqueda en el sistema de archivos de archivos de clave privada RSA y certificados PEM usando `find`. Cualquier clave privada encontrada podría otorgar acceso a otros sistemas que confíen en la clave pública correspondiente, una valiosa oportunidad de movimiento lateral. No se encontraron claves privadas pertenecientes a otros sistemas.
### Despliegue de Puerta Trasera
El acceso persistente se implementó inyectando una clave pública RSA en el archivo `authorized_keys` de la cuenta root. Se eligió la autenticación basada en clave SSH porque no depende de contraseñas y es difícil de detectar a menos que el archivo `authorized_keys` sea auditado específicamente. Se generó un par de claves RSA de 4096 bits en la máquina Kali, y la clave pública se añadió a `/root/.ssh/authorized_keys` en el objetivo, con los permisos de directorio y archivo correctos establecidos. Se estableció una conexión de vuelta al objetivo usando la clave privada para verificar que la puerta trasera era funcional.
*Acceso persistente de root confirmado mediante autenticación con clave privada*
### Automatización
También se desarrolló un script personalizado de Python para Metasploit RPC (`thor_full_chain.py`) para automatizar toda la cadena de post-explotación. El script se conecta a una sesión activa de Metasploit RPC y maneja la secuencia completa: estabilización de la shell de `www-data`, inyección de hammer.sh para escalar a thor, escalada GTFOBins a root, captura de flags, extracción de credenciales y despliegue de puerta trasera con registro de tiempo marcado guardado en un archivo local. Este fue un entregable adicional que demuestra la capacidad de automatización de la cadena de ataque utilizando la API de Metasploit RPC. Consulte `scripts/thor_full_chain.py` para la implementación completa.
## Fase 8: Cobertura de Rastros
La fase final implicó eliminar evidencia de la intrusión tanto del sistema objetivo como de la máquina atacante Kali. En el objetivo, el registro de acceso de Apache fue el archivo más crítico de limpiar, ya que contenía la solicitud HTTP cruda de Shellshock que desencadenó el exploit inicial. Se limpió el registro de autenticación, ya que almacenaba cada comando sudo utilizado durante la fase de escalada. El syslog, los registros binarios de inicio de sesión (`wtmp`, `btmp`, `lastlog`) y el historial de bash tanto de `root` como de `www-data` fueron sobrescritos y verificados vacíos.
En Kali, se eliminó el espacio de trabajo de Metasploit con `workspace -d default`, se eliminaron los archivos de credenciales descargados, se eliminó el par de claves SSH y se limpió el historial de bash. Cada paso fue verificado antes de pasar al siguiente.
Se hizo una excepción deliberada con la puerta trasera SSH, y sus archivos de clave asociados se conservaron en el objetivo y no se eliminaron en esta etapa, ya que eran necesarios para fines de demostración en la presentación de la evaluación.
## Vulnerabilidades Explotadas
| Vulnerabilidad | CVE | CVSS | Componente | Método |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + Bash sin parche | Metasploit con cabecera User-Agent maliciosa |
| Credenciales predeterminadas | — | — | pfSense webConfigurator | `admin / pfsense` sin cambios después de la instalación |
| Mala configuración de sudo (www-data) | — | — | `/etc/sudoers` | NOPASSWD `hammer.sh` ejecutable como thor |
| Inyección de comandos en hammer.sh | — | — | Script bash personalizado | Inyección de `eval` mediante payload `bash -i` |
| Mala configuración de sudo (thor) | — | — | `/etc/sudoers` | NOPASSWD `service` sin restricciones como root |
---
## Herramientas Utilizadas
| Herramienta | Propósito |
|------|---------|
| Nmap | Descubrimiento de hosts, escaneo de puertos, huella digital de SO, verificación NSE de Shellshock |
| Metasploit Framework | Enumeración respaldada por base de datos, explotación, Meterpreter, post-explotación |
| Nessus Essentials | Evaluación estructurada de vulnerabilidades con escaneo de CGI y aplicaciones web |
| Hydra | Intento inicial de fuerza bruta en pfSense sin éxito debido a la protección CSRF |
| CeWL | Generación de listas de palabras personalizadas mediante rastreo de la página de inicio de sesión de pfSense |
| Python 3 + BeautifulSoup | Script de fuerza bruta en pfSense consciente de CSRF |
| pymetasploit3 | Cliente de API de Metasploit RPC para automatización completa de la cadena de ataque |
| John the Ripper | Craqueo offline de hashes SHA-512crypt |
| Hashcat | Intentos de craqueo de SHA-512crypt acelerados por GPU |
| CrackStation | Consulta online de tablas arcoíris |
| GTFOBins | Referencia para la técnica de escalada de privilegios de service mediante sudo |
| curl | Verificación del servicio HTTP contra la WAN de pfSense |
---
## Recomendaciones
**Parchear Bash inmediatamente.** La vulnerabilidad Shellshock existe porque Bash nunca se ha actualizado en este sistema Debian 10. Ejecutar `apt-get update && apt-get upgrade bash` elimina la vulnerabilidad. Más allá del parcheo, si los scripts CGI no son necesarios operativamente, el directorio `/cgi-bin/` debe deshabilitarse por completo en la configuración de Apache, eliminando la superficie de ataque independientemente de la versión de Bash.
**Auditar y endurecer las reglas de sudo.** Dos reglas sudo NOPASSWD formaron toda la cadena de escalada de privilegios. Ninguna regla tiene una justificación legítima. El archivo `/etc/sudoers` debe ser revisado y ambas entradas eliminadas. El principio de privilegio mínimo debe regir cualquier configuración futura de sudo; las cuentas solo deben tener el acceso específico que realmente necesitan, nada más.
**Eliminar eval de los scripts de shell.** El script `hammer.sh` pasaba la entrada del usuario directamente a una sentencia `eval` sin ninguna validación o sanitización. Esto es lo que hizo posible la inyección de comandos. El uso de `eval` debe evitarse por completo en scripts de shell que aceptan entrada del usuario, ya que casi siempre es una superficie de ataque. La entrada debe validarse contra una lista blanca estricta antes de que ocurra cualquier procesamiento.
**Cambiar las credenciales predeterminadas de pfSense y restringir el acceso.** El webConfigurator estaba expuesto en la interfaz WAN usando las credenciales predeterminadas sin cambios `admin / pfsense`. Las credenciales predeterminadas deben cambiarse inmediatamente después de la instalación. El webConfigurator nunca debe ser accesible desde la WAN; el acceso debe restringirse solo a la LAN o a una interfaz de gestión dedicada.
**Implementar registro centralizado.** En la Fase 8, todos los registros locales se borraron en cuestión de minutos, sin dejar rastro de la intrusión en el sistema objetivo. Esto demostró que el objetivo no tenía gestión centralizada de registros. En un entorno de producción, los registros deben reenviarse en tiempo real a un SIEM remoto. Esto asegura que incluso si un atacante borra los registros localmente, la evidencia ya se ha conservado fuera del sistema y no puede ser manipulada.
---
## Estructura del Repositorio```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf ← Full penetration testing report
│
├── scripts/
│ ├── pfsense_brute.py ← CSRF-aware pfSense brute force script
│ └── thor_full_chain.py ← Metasploit RPC attack chain automation
│
└── screenshots/
├── network.PNG
│
├── Discovery/
│ └── pfsenselogin.png
│
└── exploit/
├── sheellockexploit.PNG
├── sudol.PNG
├── hammer.bash-i.PNG
├── privilage escaltiontoroot.PNG
├── proof.PNG
└── backdoor.PNG
Esta prueba de penetración se llevó a cabo exclusivamente dentro de un entorno de laboratorio virtual autónomo y aislado construido en Oracle VirtualBox. HackSudo Thor es una máquina CTF intencionalmente vulnerable publicada en VulnHub con el propósito explícito de educación y práctica en seguridad.
| Campo | Detalle |
|---|
| Objetivo | HackSudo Thor |
| Autor | Vishal Waghmare (@hacksudo) |
| Lanzamiento | 3 de agosto de 2021 |
| Dificultad | Fácil a Media |
| SO | Linux (Debian) |
| Formato | VirtualBox OVA |
| DHCP | Habilitado |
| Superficie de Ataque Prevista | HTTP, SSH, probable mala configuración de sudo |
| Dirección IP | Servicios Clave | SO | Identificado Como |
|---|
| 10.0.4.3 | SSH 7.9p1, Apache 2.4.38, FTP | Linux (Debian) | HackSudo Thor |
| 10.0.4.4 | Apache 2.4.29, DVWA v1.10 | Linux (Ubuntu) | DVWA |
| 10.0.3.4 | Microsoft IIS 5.1 | Windows XP/2003 | WinXP Cyberlab |
| 10.0.3.5 | vsftpd 2.3.4, SSH, Apache 2.2.8 | Linux (Ubuntu) | Metasploitable 2 |
| Gravedad | Hallazgo | CVE | CVSS v3 |
|---|
| CRÍTICO | Shellshock RCE | CVE-2014-6271 | 9.8 |
| CRÍTICO | Parche Incompleto de Shellshock | CVE-2014-6278 | 8.8 |
| MEDIO | Debilidad Terrapin en SSH | CVE-2023-48795 | 5.9 |
| MEDIO | Directorios Web Navegables | — | 5.3 |
| MEDIO | Clickjacking / Sin X-Frame-Options | CWE-693 | 4.3 |
| BAJO | Divulgación de Marca de Tiempo ICMP | CVE-1999-0524 | 2.1 |