metasploitable-vulnerability-analysis

Network security lab focusing on Nmap scanning methodologies and environment isolation using VMware

Objective:

To establish a secure & isolated sandbox environment using VMware & perform network reconnaissance using Nmap.

Environment Setup:

• Hypervisor: VMware Workstation
• Attacker Machine Kali Linux (IP: 192.168.117.128/24)
• Target Machine Metasploitable 2 Linux (IP: 192.168.117.129/24)
• Network Mode: VMnet1 Host-only (This is to properly isolate the VM's from the internet)

Phase 1: Environment Verification

Before perfoming the Nmap scan, I had verrified the connectivity within the isolated subnet to esnure that the attacking machine could only communicate with the target machine without external interfernce.

Phase 2: Network Reconnaissance

After verifying the connectivity, I then performed a comprehensive service and vulnerability scan using Nmap.

Method:

I had executed a Nmap scan within Linux to identify any potential open ports, active services, and the target's operating system.

Scan Command

sudo nmap -sV -sC -O -oN initial_scan.txt 192.168.117.129

Findings summary

After the scan had succesfully ran, I had identified serveral critical services running on the target machine, including the following:

• FTP (Port 21): Running vsftpd 2.3.4
• SSH (Port 22): OpenSSH 4.7p1
• Telnet (Port 23): Linux telnetd
• HTTP (Port 80): Apache httpd 2.2.8
• Samba (Port 445): Samba 3.0.20-Debian

The full output scan is located within /scans folder.

Risk Anaylsis

• FTP (Port 21-vsftpd 2.3.4): This specific version contains a rather famous backdoor that allows potential attackers to gain a shell by simply sending a smiley face :) in the username.
• SSH (Port 22 OpenSSH 4.7p1): After doing more research upon this specific port's vulnerability, I had discovered that the specific Debian 8ubuntu1 package of OpenSSH 4.7p1 has a huge flaw where it would use predictable random number generation to create SSH keys. Which would then lead to weak 1024 bit DSA keys.
• Telnet (Port 23): This is a unencrypted protocol. Anyone on the network could see your login credentials in cleartext.
• HTTP (Port 80 Apache httpd 2.2.8): This is a rather old protocol that hasn't recieved any updates, which makes it rather vulnerable to a various types of attacks due to a lack of security fixes for known Common Vulnerabilities and Exposures (CVEs).
• Samba (Port 445): This is frequently used for file sharing but is often vulnerable to remote code execution (RCE). This would be a primary target to gain initial access to the system.

Lessons Learned & Troubleshooting

Syntax precision: During the reconnasiance phase, I had truly learned how precise command syntaxes need to be within Linux's terminal as I had made a minor grammatical error when trying to execute the Nmap command, it left me scratching my head far longer than it shoudl've

Environment isolation: With this being my first ever hands on project to transfer my knowledge from my Security+ study guide, I had taken many steps to ease my mind that I had properly isolated both VM's within VMware to have a proper sandbox. I had achieved this by using a "Host-Only" adapter, I then ensured that the vulnerable Metasploitable 2 VM remained isolated from the internet and my local home network, preventing any "leakage" of vulnerabilities.

Documentation Habits: I utilized this lab as an opportunity to learn GitHub for professional technical documentation. I prioritized recording critical environment data early—such as the attacker (192.168.117.128) and target (192.168.117.129) IP addresses to ensure a clear chain of custody and repeatable results throughout the reconnaissance process.

Next projects

Explotation: After succesfully identifying some of the more commonly known vulnerabiliteis I aim to utilize the Metasploit Framework to test the exploitability of the vsftpd 2.3.4 backdoor found on port 21.

Vulnerability Research: I aim to also cross reference any identified service versions with the CVE to find specific exploit code.

Phase 3: Exploitation (Python & Metasploit)

As the title suggested in this phase, I had transitioned from the reconnaissance to active exploitation. When in this new phase I had utilized both custom built tools as well as industry standard tools such as the metasploit framework to verify the vulnerabilities previously identified in Phase 2

Lab 3: Automated vsftpd backdoor triger (Python)

During this lab I had wanted to brush up on some older knowledge from my college Python experience. I viewed it as an oppurtinity to get back into the scripting side of things as well as bridge that experience with cybersecurity, I then developed a custom script to automate the "trigger" for the vsftpd 2.3.4 backdoor.

You can fully view this here! View Python Script

Methodology The script I made establishes a TCP connection to Port 21, it performs a banner grab to verify the version (vsFTPd 2.3.4), and then sends the magical string :) within the username field.

Results The script had succesfully triggered a listener onto Port 6200, which then allowed me to utilize Netcat (nc) to establish a bind shell which confirmed my root access through the whoami command.

Verification command

nc -nv 192.168.117.129 6200

Key learning moments Doing this scripting exercise help me learn the usage of Python's 'socket' library, specically with handling raw bytes (b"") as well as managing network timeouts through try/except blocks.

Lab 3.1: Samba 2.0.20 RCE (Metasploit)

For the second exploitation lab, I wanted to use a more industry based tool which led me to utilizing the Metasploit Framework to target the Samba "Username Map Script" vulnerability on Port 445.

Module: exploit/multi/samba/usermap_script

Payload: cmd/unix/reverse_netcat

Result: I had Successfully established a reverse shell from the Metasploitable VM back to my Kali Linux machine. This granted immediate root privileges without requiring a password like the Python script.

Comparison While the Python script posed as a rather insightful experience into the manual triggering process, the Metasploit very clearly demonstrated efficiency by using a professional exploitation database for well known CVEs.

Phase 4: Network sniffing & Credential Harvesting

The goal of this phase was for me to demonstrate the risks assosciated with unencrypted management protocols by intercepting cleartext credentials using Wireshark after establishing our foothold through the vsFTPd 2.3.4 backdoor.

Methodology:

While maintining the root shell I had established within phase 3, I had utilized Wireshark to monitor the visual network inerface. I then initiated a remote Telnet session to observe how legacy protocols handle sensitive data during the authentication process.

Technical setbacks & Troubleshooting:

This phase has so far been the most problematic process so far, while proving to be difficult it gave me the most significant learning curve when it comes to real world network analysis.

• Protocol Handshake Mismatch: My first attempts to utilize Netcat to connect to Port 23 had resulted in what I found out to be malformed binary data. Which is a series of dots and hashtags which I realized is the ASCII representations of binary Telnet negotiation commands, I had learned that Netcat is a "raw" tool and it can't perform the complex option negotiation required by a Telnet server, which resulted in a failed handshake between the two. The entire conversation within the capture is only 16 bytes which is a small size, proving that the connection was being dropped by the server before any readable (such as the login banner) could be sent. This mismatch highlights the difference between Layer 4 (Transport) connectivity where Netcat successfully opened a port, and Layer 7 (Application) compatibility, where the protocol negotiation failed.

• Interface isolation: I had initially attempted to capture traffic on the loopback (lo) interface using the telnet localhost command. I had discovered that Wireshark must be listening to the specific interface where the traffic resides. The traffic on the lo is invisible to a sniffer targeting the eth0 wire. In the capture below you can see how the terminal on the left shows an active session where I had logged in as msfadmin. However, Wireshark had kept showing me an empty capture window. I had identified that the telnet localhost command keeps the traffic entirely within the target machine's interal loopback (lo) interface. Because of this my Wireshark instance was monitoring the eth0 interface (the virtual wire) between the two VM's. It was physically impossible for it to see the internal traffic. I resolved this by targeting the remote IP 192.168.117.129 to force the data across the wire

• Capture Timing & persistence: I had encountered serveral empty captures because I had initiated the login sequence before htting the start button in Wireshark. This reinforced the forensic principle in packet sniffing is a live process and not retroactive. As seen in the following capture, the systems logs show a successful loging at 17:05:31. But the Wireshark session hadn't initalized until 17:04:14. This four minute discrepancy explains as to why the capture window had remained empty, highlighting the absolute necessity of precise timing and log correlation when attempting to reconstruct network events.

• Connectivity Validation: To break out of this troubleshooting loop (this took longer than I'd like to admit) I had utilized the ping command to verify layer 3 connectivity. This finally allowed me to see the ICMP packets in Wireshark which confirmed my "net" was finally working allowing me to focus on fixing the Telnet filter. As shown in the capture below, running ping -c 4 192.168.117.129 generated immediate, visible traffic, providing the affirmation I can return to Telnet analysis. This step follows the CompTIA troubleshooting theory, more specifically "Establishing a theory of probable cause" by testing a lower layer of the OSI model. Specifically Layer 3 (Network) which I was able to rule out network hardware or IP config issues before re-examining Layer 7 (Application) protocols.

Results

By switching to a standard Telnet client and targeting the remote IP, I had successfully captured the full login sequence.

• Banner grabbing: The unencrypted stream had finally revealed the Metasploitable 2 welcome banner, providing a clear OS fingerprint.

• Cleartext Credentials: Using Wireshark's "Follow TCP Stream" feature, I was able to reconstruct the conversation and view the msfadmin username and msfadmin password in plain readable text.

Key learning moments

• Credential Security: This lab provided a prime example as to why protocols like Telnet and FTP are so unsecure in modern environments

• The OSI Model in Action: Troubleshooting in this phase require moving up the layers ranging from Layer 3 (IP/Ping) to Layer 4(TCP/Port 23) to lastly Layer 7 (Application/Telnet) to full understand why the data was appearing as random data.