First Blood: Backdoor to Cracked Credentials on Metasploitable

Part two of the Proxmox cyber-range series: the first real attack. Connecting to a root
backdoor left listening on Metasploitable, stealing the password file over the target's
own web server, and cracking six of seven hashes in seconds with John the Ripper. A
complete recon-to-credential-access chain, and a hard look at why weak passwords plus
fast hashes equal instant compromise.

$ cat table_of_contents.txt

A NY2Honolulu / “Intelligence from Paradise” build log — Part 2. The cyber range from the last post is standing; this is what happens when you actually attack it. A full chain, start to finish: nmap finding an open backdoor, a root shell with no exploit, the password database stolen off the box over its own web server, and six of seven passwords cracked in about three seconds.

Companion to Building a Cyber Range Inside Proxmox. If the lab isn’t built yet, read that one first.

What this is

Last time I built the range: Kali and Metasploitable 2 on an isolated Proxmox bridge, and an nmap scan that turned up 23 open ports. One of those lines mattered more than the rest:

1524/tcp  open  bindshell  Metasploitable root shell

That’s a root shell already listening — a backdoor someone left running. This post walks the whole chain that grows out of it:

scan → connect to backdoor → root → dump /etc/shadow → exfiltrate → crack passwords.

No exploit code is written or fired anywhere in this. The “attack” on the backdoor is just connecting to it. That is exactly the point: this is what a post-compromise foothold looks like, and why finding an unexpected listening port on a real scan is a five-alarm fire.

Prerequisites

  • The isolated range from Part 1: Metasploitable (VM 100) and Kali (VM 101) on vmbr1, reachable from each other. In my lab: Kali 192.168.100.3, Metasploitable 192.168.100.10.
  • Tools used on Kali (all preinstalled): nc (netcat), wget, ftp, and John the Ripper (john, unshadow).

Resuming the lab after a reboot

If you shut the range down cleanly last session, bringing it back is short. The one thing that doesn’t survive a reboot is Metasploitable’s IP (I set it by hand; Kali’s is permanent via NetworkManager).

1. SSH into Proxmox and start both VMs:

bash

ssh root@192.168.95.134
qm start 100
qm start 101
qm status 100      # want: running
qm status 101      # want: running

2. Re-set Metasploitable’s IP (in its console — Proxmox web UI → double-click VM 100 → log in msfadmin/msfadmin):

bash

sudo ifconfig eth0 192.168.100.10 netmask 255.255.255.0 up
ifconfig eth0      # confirm inet addr:192.168.100.10

3. Confirm the link from Kali:

bash

ping -c 4 192.168.100.10      # want: 0% packet loss

Two replies-per-notes from doing this: the first ping is slow (ARP lookup), the rest fast; and ttl=64 on every reply confirms same-network, no router between them.

The attack, clean version

1. Walk through the backdoor

From Kali:

bash

nc 192.168.100.10 1524

nc (netcat) opens a raw TCP connection — no protocol, just a pipe from your keyboard to whatever is listening. On 1524 that’s a root shell. The screen goes quiet with no new prompt — that’s correct, you’re already inside. Prove it:

bash

id
root@metasploitable:/# id
uid=0(root) gid=0(root) groups=0(root)

Read the prompt: root@metasploitable:/#. root@ = the superuser, metasploitable = the target (not Kali), # = the universal root prompt. uid=0 is root. First blood — no exploit, no password, no Metasploit. You connected to a door and root was standing there.

2. Steal the password database

As root you can read the file normal users can’t — every account’s hashed password:

bash

cat /etc/shadow

Each line is username:hash:…. The hashes here start with $1$, which is MD5-crypt — 2000s-era, fast to compute, weak by modern standards. Accounts showing * or ! instead (like daemon:*) have login disabled and nothing to crack.

3. Stage and exfiltrate over the target’s own web server

The hashes are only on-screen so far; get them onto Kali. Anonymous FTP turned out to be jailed to its own directory (couldn’t reach /tmp), so the clean route is HTTP — Metasploitable’s Apache serves from /var/www.

Still in the root shell, copy both files under the web root:

bash

cp /etc/passwd /var/www/p.txt
cp /etc/shadow /var/www/s.txt
exit

Back on Kali, pull them down:

bash

wget http://192.168.100.10/p.txt
wget http://192.168.100.10/s.txt

200 OK and matching byte counts (saved [1581/1581], saved [1207/1207]) mean the whole files arrived, not an error page. Sanity-check:

bash

head -3 s.txt      # want to see: root:$1$...

Staging loot in a writable directory and pulling it out over a service the box already exposes is textbook exfiltration. Note for the defensive side: those two wgets left GET /p.txt and GET /s.txt lines in /var/log/apache2/access.log on Metasploitable — exactly the kind of thing a SIEM (Wazuh) should flag.

4. Merge and crack

John needs the usernames (passwd) and the hashes (shadow) stitched together:

bash

unshadow p.txt s.txt > hashes.txt

Then turn it loose, telling it the hash type we identified:

bash

john --format=md5crypt hashes.txt

John runs “single” mode first (guessing the username as the password — which is why the worst accounts fall instantly), then its wordlist. Metasploitable’s passwords are weak by design, so cracks appear in seconds. Press any key for a status line; press q or Ctrl+C to stop.

Stop it once it reaches incremental mode. After the wordlist, John brute-forces character by character (Proceeding with incremental:ASCII). On a hash that isn’t a dictionary word that can run for days. It has already saved every crack, so stopping costs nothing.

5. Read the results

bash

john --show hashes.txt

The loot

Six of seven fell in about three seconds:

AccountCracked passwordWhy it fell
useruserpassword = username
postgrespostgrespassword = username
msfadminmsfadminpassword = username (full sudo account)
serviceservicepassword = username
sysbatmandictionary word
klog123456789number sequence
root(not cracked)not in the wordlist; would need brute force or a bigger list

root‘s password wasn’t in John’s default list, so it survived the wordlist pass. It doesn’t matter — msfadmin is a full sudo account, so the box is already owned. If you want root’s specifically, point John at a bigger wordlist later:

bash

john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt   # gunzip rockyou.txt.gz first

Why it worked (the real lesson)

Six passwords fell in three seconds, and it wasn’t magic — it was two compounding failures:

  1. Weak passwords. Four accounts used the username itself. No wordlist even needed — John’s “single” mode guesses the username first.
  2. Fast hashes. $1$ MD5-crypt is cheap to compute, so a laptop tries millions of guesses per second.

Fix either and the attack collapses. Strong, non-dictionary passwords beat the wordlist. Slow modern hashes — $6$ SHA-512, bcrypt, argon2 — make even weak passwords take years instead of seconds. Defense in depth means fixing both, plus not letting the file leak in the first place (least privilege, no stray root backdoors, monitoring the exfil path).

Gotchas I hit (so future-me can skip the pain)

SeaBIOS boot menu again. A stray keypress during Kali’s startup dropped it into the “Select boot device” menu. Press 2 (the hard disk), never 1 (the installer ISO). Worth detaching that ISO from the virtual DVD drive eventually so it can’t be booted by accident.

Ran sudo ifconfig … on the wrong machine. sudo: command not found and ifconfig: command not found from Proxmox = I typed the target’s command into the host’s SSH session. The fix is the habit: read what’s after the @ in the prompt before typing. @promox = host, @metasploitable = target, @kali = attacker.

Anonymous FTP is jailed. cd /tmp over anonymous FTP → 550 Failed to change directory. vsftpd locks anonymous logins into /home/ftp; /tmp is outside the jail. That’s FTP behaving securely — the workaround was HTTP via Apache instead.

Dots vs. slashes vs. commas in filenames. cp /tmp/p/txt … and cp /tmp/p,txt … both failed (cannot stat) before cp /tmp/p.txt … worked. Easy fat-finger; the errors are harmless, just retype.

John never “finishes” on its own. It transitions to endless incremental brute force. Know to stop it with q.

Clean shutdown

Same as always — guests first, then the host, then VMware, then the desktop:

bash

# on Proxmox (SSH):
qm shutdown 100        # if it times out: qm stop 100  (Metasploitable ignores ACPI)
qm shutdown 101
qm status 100 ; qm status 101    # want both: stopped
shutdown -h now        # SSH drops — that's the sign it worked

Then power off the Proxmox VM in VMware if it isn’t already, close VMware, shut down the desktop. (ERR_ADDRESS_UNREACHABLE on the web UI = Proxmox is off, not an error.)

Study connections

Black Hat Python. Step 1 — nc host port — is exactly what the book’s Chapter 2 TCP client does in code. The natural “prove I get it” exercise: replace nc with your own ~15-line Python socket client and land the same root shell on 1524. The FTP/HTTP file grab in Step 3 is the same socket primitive wrapped in a real protocol.

AWS DVA-C02. This whole chain is the argument for why managed identity exists. There is no /etc/shadow to steal from a managed AWS service — IAM handles authentication, and access keys are long random strings no wordlist will ever guess. Dump → exfiltrate → crack is an attack path that managed identity designs out of existence. Seeing it work by hand makes the exam’s “why” concrete: the reason you don’t manage OS-level password files on managed services is sitting right there in the six cracked hashes.

Next step — the defensive chair (Wazuh). Everything here left tracks: the 1524 connection, and two GET requests in Apache’s access log for suspiciously-named files. Reviewing your own footprints from the defender’s side is the best possible way into detection engineering.

References / further reading