FTP is a protocol from a different era, and its fundamental insecurity is that it transmits credentials in the clear.
Let’s see this in action. Imagine a user logging into an FTP server.
220 (vsFTPd 3.0.3)
USER anonymous
331 Anonymous access allowed, send your email address or a random string
anonymous@example.com
230 Anonymous access granted, restrictions apply
If you were capturing this traffic with Wireshark, you’d see the USER and the subsequent login information sent as plain text over the network.
Here’s what that looks like in a Wireshark capture, assuming the capture filter was ftp:
Frame 1: 192.168.1.100 -> 192.168.1.200, FTP, 66 bytes
Source: 192.168.1.100
Destination: 192.168.1.200
Protocol: FTP
[GET_DATA]:
Command: USER
Username: anonymous
Frame 2: 192.168.1.200 -> 192.168.1.100, FTP, 60 bytes
Source: 192.168.1.200
Destination: 192.168.1.100
Protocol: FTP
[REPLY_CODE]: 331 Anonymous access allowed, send your email address or a random string
Frame 3: 192.168.1.100 -> 192.168.1.200, FTP, 80 bytes
Source: 192.168.1.100
Destination: 192.168.1.200
Protocol: FTP
[GET_DATA]:
Command: PASS
Password: anonymous@example.com
In this simplified example, the username and password are both "anonymous@example.com". The key takeaway is that if a user is logging in with a username and password (not anonymous access), the PASS command will carry the password in plain text.
The problem FTP solves is file transfer. The way it works is via two channels: a control connection (usually on port 21) for commands and responses, and a data connection (which can be on various ports, depending on whether it’s active or passive mode) for the actual file transfers. Authentication happens over the control connection.
The primary lever you have when dealing with FTP traffic is the ability to capture network packets. By capturing traffic on the network segment where FTP communication is occurring, you can then use Wireshark to dissect these packets. Wireshark’s built-in dissectors for FTP automatically identify the commands and arguments, including the username and password in the USER and PASS commands.
If you want to find these credentials within a capture file, you can use Wireshark’s display filters. A common filter to find FTP login attempts is ftp.user or ftp.pass. For example, ftp.pass will show you all packets containing an FTP password field. To see the actual password value, you’d then examine the packet details pane.
The most surprising thing about extracting FTP credentials, even today, is how often it’s still possible because administrators haven’t migrated to secure alternatives like SFTP or FTPS. Many systems still expose FTP services, and users, either out of convenience or ignorance, continue to use plain FTP for file transfers.
When Wireshark analyzes FTP traffic, it recognizes the standard FTP command structure. The USER command is followed by the username, and then the PASS command is followed by the password. Wireshark’s dissector parses these commands and presents the username and password as distinct fields in the packet details pane, making them easily readable. It’s not some complex decryption; it’s just reading what’s sent in the open.
The next logical step after discovering these cleartext credentials is to understand the security implications and the path forward, which often involves migrating to secure file transfer protocols.