FTP Bounce Attack: What It Is, How It Works, and How to Prevent It

FTP Bounce Attack: What It Is, How It Works, and How to Prevent It #

FTP bounce is a technique that uses an insecurely configured FTP server to trick it into making connections to another host. This way, the FTP server can be used as an intermediary to verify the reachability of ports and systems that the client cannot reach directly—for example, because they are blocked by a firewall.

This is a historical technique (from the 90s), rare on properly configured modern servers, but still relevant during authorized assessments on legacy systems that expose FTP.

What is the PORT command and why is it central? #

FTP uses two separate connections:

1. Control connection (port 21): the client sends commands to the server (LIST, RETR, STOR, etc.)
2. Data connection (variable port): Data and directory listings pass through here

In active mode (PORT mode), the client tells the server where to open the data connection, with the command:

PORT <IP_bytes>,<port_bytes>

Example:

ftp> PORT 192,168,1,100,13,80

The last two numbers encode the port: primo_byte × 256 + secondo_byte. In the example: (13 × 256) + 80 = 3408The command tells the server: “open a connection to 192.168.1.100:3408 and send me the data there.”

The command PORT It therefore allows the client to tell the server the address and port to which to establish the data connection. An insecurely configured server may accept a destination other than the host that opened the control connection—and it is precisely this condition that creates the vulnerability underlying FTP bounce.

How the attack works #

If the FTP server does not verify the IP specified in the command PORT matches the connected client, an attacker can:

1. Connect to a vulnerable FTP server (e.g. 10.10.20.50)
2. Send PORT towards a third host (e.g. 10.10.20.100:80)
3. The FTP server attempts a TCP connection to that destination
4. Depending on the success or failure of the connection, the FTP server returns a different message.

The result is an indirect port scan: the target sees the connection coming from the FTP server, not the attacker. However, this doesn't equate to stealth. The target sees the connection coming from the FTP server, while the actual origin of the request remains separate from the connection to the target—but the activity can still be correlated and logged in FTP logs, firewalls, IDS/IPS, and NetFlow. This isn't an anonymous attack; it's an attack with a different origin to trace.

Is FTP Bounce still a real vulnerability? #

In everyday practice, this is rare. Modern FTP servers (vsftpd, ProFTPD, and the updated Pure-FTPd) check that the address in the command PORT matches the client that opened the control connection, and reject the request otherwise. FTP itself has largely been replaced by SSH/SFTP.

It remains relevant in two concrete cases: authorized assessments on legacy infrastructures (embedded devices, systems that haven't been updated for years) and as an educational reminder of what happens when a protocol blindly trusts client input.

Requirements for an FTP Bounce Attack #

1. Vulnerable FTP server accessible, often via anonymous access
2. Unpatched server: Does not verify the origin of commands PORT
3. A target reachable by the FTP server (same network segment or internal routing), even if not directly reachable by the attacker

How to Check if an FTP Server is Vulnerable #

The reliable way to test for vulnerability is with a dedicated assessment tool, not by manually observing FTP response codes—the exact behavior varies depending on the server, transfer mode, and destination.

With Nmap NSE (recommended method) #

nmap --script ftp-bounce --script-args ftp-bounce.username=anonymous,ftp-bounce.password=anonymous -p 21 <FTP_SERVER_IP>

• --script ftp-bounce: runs the script that tests the vulnerability
• --script-args: pass username/password for FTP login
• -p 21: limit scanning to the standard FTP port

Output if vulnerable:

| ftp-bounce: 
|_  bounce working! -- I can use the server to bounce scans off another host

Indicative manual verification (via telnet) #

It can give a preliminary indication, but it is not a substitute for testing with Nmap:

telnet <FTP_SERVER_IP> 21

USER anonymous
PASS anything@example.com
PORT 192,168,1,100,0,80
LIST

An answer 150/226 It's an indication of permissive behavior, not a definitive confirmation. An error 500 Illegal PORT command Instead, it indicates a server that checks the address for correspondence, and is therefore not vulnerable to this technique.

Scanning with Nmap FTP Bounce (-b) #

With the vulnerability confirmed, Nmap can be used to scan through the bounce server:

nmap -v -Pn -p 22,80,443,3306 -b anonymous:ftp@10.10.20.50:21 10.10.20.100

• -Pn: skip ping (often blocked by firewalls to the internal target)
• -p 22,80,443,3306: specific ports instead of a full scan
• -b anonymous:ftp@10.10.20.50:21: credentials and FTP server used as bounce
• 10.10.20.100: target to scan

Even an entire subnet:

nmap -v -Pn -p 80,443 -b anonymous:ftp@192.168.1.50:21 192.168.50.0/24

Bounce scanning is slower than a direct scan because each connection goes through the FTP server—it's a trade-off between reduced visibility and speed.

Metasploit: Automated Scanner #

msfconsole -q
use auxiliary/scanner/ftp/ftp_bounce
set RHOSTS <FTP_SERVER_IP>
set RPORT 21
set FTP_USERNAME anonymous
set FTP_PASSWORD anything
run

The module connects to the server, automatically tests a set of common ports, and reports which ones are open on the target.

Typical scenario #

[Attaccante] --firewall blocca scansioni dirette--> [Rete interna]
                                                        |
                                              [Server FTP vulnerabile]
                                                        |
                                              [Target interno non raggiungibile direttamente]

The attacker cannot scan the internal target directly, but the internal FTP server is reachable (for file transfer) and can be used as an intermediary to reach segments otherwise blocked by the firewall.

A concrete case still observable in assessments on dated infrastructures: embedded devices (printers/multifunction devices with integrated FTP service) that have remained unupdated for years.

FTP Bounce vs Proxy vs Pivot #

Three concepts often confused by beginners:

• FTP bounce: the FTP server makes a connection to a destination indicated by the client, using the command PORT. It is specific to the FTP protocol.
• proxy: forwards traffic between client and destination according to an explicit proxying model (e.g. SOCKS, HTTP proxy).
• Pivot: Uses a compromised or otherwise accessible system as an intermediate point to reach an otherwise unreachable network. pivoting.

FTP bounce does not automatically equate to having access to the internal network: the technique allows you to use the FTP server to make certain connections to other hosts, but what is actually reachable depends on routing, firewall and configuration of the FTP server itself.

How to Detect an FTP Bounce Attack #

On the defensive side, the signals to monitor are:

• commands PORT to IP addresses external to the client that opened the control connection
• Connections originating from the FTP server to hosts or ports that are unusual compared to normal traffic
• Correlation between FTP logs and firewall/NetFlow data over the same time window
• Repeated attempts to many destinations or many ports in sequence (scan pattern)
• IDS/IPS Alert on Commands PORT anomaly

Example of indicative rule (pseudocode):

alert ftp any any -> any 21 (msg:"FTP PORT command verso IP esterno"; content:"PORT"; sid:1000001;)

How to Prevent FTP Bounces #

• Upgrade your FTP server to a recent version: Modern servers check that the address in the command PORT match the control connection client
• On vsftpd, explicitly disable PORT mode (port_enable=NO) if it is not needed
• Internal Network Segmentation: Limiting What a Compromised FTP Server Can Actually Achieve
• Active monitoring of FTP logs for commands PORT to addresses not belonging to the expected internal network

FAQ #

Is FTP Bounce invisible? No. It hides the source of the connection to the target from the target, but the activity remains traceable via FTP logs, firewalls, and IDS/IPS.

What's the difference between FTP bounce and SSH dynamic forwarding? SSH forwarding requires valid SSH credentials on the intermediate host. FTP bounce only requires a vulnerable FTP server, often accessible anonymously.

Can I use FTP bounce if my firewall blocks port 21? No. You need to be able to reach the FTP server on its control port; if that's blocked, this technique won't work.

What if the FTP server requires authentication? You need valid credentials to pass to the command (-b username:password@host). Without credentials, the technique cannot be used on that server.

Is FTP bounce legal? It's a form of port scanning, so it falls under the category of activities that require explicit authorization (e.g., a penetration testing contract that includes it). Without authorization, it's unauthorized access.

External resources #

• Nmap – FTP Bounce Scan: official documentation on the flag -b
• RFC 2577 – FTP Security Considerations: RFC that standardizes bounce attack mitigations
• SecForce – FTP Bounce Network Scanning: real-world case study on vulnerable embedded device
• The Hacker Recipes – FTP Bounce: Operational guide with commands and NSE scripts
• Hackviser – FTP Pentesting Guide: Complete FTP assessment, including bounce

Conclusions #

FTP bounce is an old attack, rare today, but useful to know for two reasons: it demonstrates concretely what happens when a protocol is trusted without verifying client input, and it remains a real vector on legacy systems encountered during authorized assessments. If you find an open FTP server in a test, checking for vulnerability with Nmap takes just a few seconds.