Skip to main content

FTP

FTP is one of the oldest services you’ll meet on an engagement, and one of the most generous when misconfigured. Anonymous logins, world-readable files, writable web roots, and chatty banners make it a reliable first foothold.
Protocol: TCP · Port: 21 (data on 20)

FTP vs TFTP

FTP (File Transfer Protocol) transfers files between a client and server over TCP port 21, with user authentication and a full set of commands. TFTP (Trivial File Transfer Protocol) is the stripped-down cousin. It runs over UDP, has no authentication, no password-protected login, and no directory listing. In practice it only operates on globally readable/writable files, so it should only ever appear on local, protected networks — and when you find it exposed, that’s already a finding. A few core TFTP commands: Remember: unlike FTP, TFTP can’t list directories — you have to already know the filename you want.

Default Configuration

One of the most common FTP servers on Linux is vsFTPd, configured in /etc/vsftpd.conf. It’s only one of many FTP servers, but it’s the one you’ll see most often. Key settings in a default vsftpd.conf:
There’s also /etc/ftpusers, which denies specific users access to FTP even if they exist on the system. For example, listing guest, john, and kevin there blocks those accounts from logging in:

Dangerous Settings

The setting that matters most to an attacker is anonymous access. In vsftpd.conf, the anonymous-related options look like this:
anonymous_enable=YES combined with write_enable=YES or anon_upload_enable=YES is the dangerous pairing — it means anyone can not only read files but drop their own. On an FTP server tied to a web root, that’s a path to a web shell.
When you connect, the server greets you with response code 220 and a banner — which often discloses the service description and even its version. Even when you can’t download anything, just listing the directory contents can hand you names and intel for another angle of attack.

Footprinting the Service

Anonymous Login

The first thing to try is logging in as anonymous (any password, often blank):

Get an Overview with status

To see how the server is configured at a glance, use status:

Reveal More with debug and trace

Turning on debug and trace makes the server show you more of what’s happening under the hood — useful for understanding its behavior:

Spotting hide_ids and ls_recurse_enable

If hide_ids=YES is set, the UID/GID of files is overwritten (shown as ftp or 0), making it harder to tell what rights files were written with. Conversely, if ls_recurse_enable=YES is set — common on vsFTPd for convenience — you can list the entire directory tree in one shot:

Download Everything

When the server has a large folder structure, you can mirror the whole thing at once with wget. Be aware this is noisy — nobody legitimately downloads an entire FTP server in one go:
wget creates a directory named after the target’s IP and stores everything there for offline inspection.

Test Upload Access

Check whether you can upload — especially valuable when the FTP server is tied to a web server, since developers often sync files between them. Upload access there can mean dropping a web shell and getting code execution:
Upload access to an FTP server connected to a web root is one of the cleanest paths to a reverse shell. Drop a web shell, browse to it, and you’ve turned a file server into command execution.

Scanning FTP

Network scanners make footprinting easier and can find FTP even on non-standard ports. Nmap’s NSE scripts are the standard approach. First, the FTP-related NSE scripts live in /usr/share/nmap/scripts/ and can be found with:
Run the default FTP scripts with version detection:
To watch what the NSE scripts are doing at the network level, add --script-trace. It shows the commands Nmap sends, the ports used, and the server’s responses — including the banner returned to one of the parallel NSE connections:

Interact Manually with netcat / telnet

You can also talk to the server directly:

TLS/SSL FTP with openssl

If the server runs with TLS/SSL (FTPS), you need a client that speaks it. openssl works and has the bonus of showing you the SSL certificate, which can itself contain useful information:

Quick Reference

The footprinting flow: anonymous login → status for config → recursive listing → download everything → test upload → fall back to nmap/openssl for banner and version intel.
Next: SMB — shares, null sessions, and pulling files off Windows file servers.