FTP

The File Transfer Protocol (FTP) is one of the oldest application-layer protocols on the Internet, standardized in RFC 959 (October 1985). It uses a dual-channel design: a persistent control connection on TCP port 21 for commands and replies, and separate data connections for file transfers and directory listings.

FTP transmits credentials and data in cleartext, making it trivially sniffable on any shared network segment. It should only be encountered on assessments as a legacy artifact — modern alternatives include SFTP (SSH File Transfer Protocol, an entirely different protocol riding ssh) and FTPS (FTP over TLS, standardized in RFC 4217). ^{1 2}

Core commands

The control connection speaks a simple text protocol. Common commands (sufficient for basic operations):

Command	Purpose
USER	Specify the username
PASS	Specify the password
LIST	List contents of a directory (or FTP root)
RETR	Retrieve (download) a file
STOR	Store (upload) a file
PASV	Switch to passive mode
TYPE	Switch between ASCII (A) and binary (I) transfer modes
SYST	Return system “type” information (OS fingerprinting)
STAT	Return connection/server information
QUIT	End the session

Active vs. passive mode

FTP’s dual-channel architecture is the source of most operational quirks:

• Active mode: The client opens a random port and tells the server via PORT. The server then initiates the data connection from port 20 back to the client. Active mode fails through NAT/firewalls because the server cannot reach the client’s listening port.
• Passive mode: The client sends PASV. The server opens a random port above 1023 and tells the client to connect to it. Passive mode works through NAT because both connections are client-initiated.

Manual file retrieval with netcat

You cannot retrieve files over a single netcat session — the data connection is separate from the control connection. However, you can retrieve files using two sessions:

1. Connect to port 21 with nc $TARGET 21 and authenticate (USER/PASS).
2. Issue PASV. The server replies with a string of the form (o1,o2,o3,o4,p1,p2) where o1–o4 are the server’s IP octets and p1–p2 are the high and low bytes of the port.
3. Calculate the decimal port: (256 × p1) + p2. For example, p1=117, p2=85 → port 30037.
4. Open a second netcat connection to that IP and port.
5. Issue RETR filename in the first session. The file data arrives on the second connection.

This is tedious but sometimes the only option when no FTP client is available on a target.

FTPS

FTPS (FTP over TLS, RFC 4217) wraps FTP in TLS encryption. Implicit FTPS uses port 990 by default; explicit FTPS starts on port 21 and upgrades with AUTH TLS. FTPS has been largely supplanted by SFTP, which is simpler to firewall (single connection on port 22) and more widely deployed. ³

Shell escape via sudo

If the ftp binary is permitted via sudo with NOPASSWD, it can be used to escape to a root shell: ftp accepts !/bin/sh as a command, which spawns a subshell with the privileges of the invoking process (root). This is a classic GTFOBins entry. ⁴

Sources

• RFC 959 — File Transfer Protocol
• RFC 4217 — Securing FTP with TLS
• GTFOBins — ftp

Related: netcat, ssh, sudo

Footnotes

1. RFC 959 — File Transfer Protocol ↩

2. RFC 4217 — Securing FTP with TLS ↩

3. RFC 4217 — Securing FTP with TLS ↩

4. GTFOBins — ftp ↩