FTP Enumeration

← Stage index · Cheatsheet | Strategy map | Study methods: Extract opportunities from services

Recognize: FTP usually appears on TCP/21, but trust an FTP banner or protocol response on any port. Goal: determine authentication, listable/readable content and effective write locations.

Baseline: anonymous access

ftp TARGET

At the prompts, try user anonymous and an email-like password. Then:

status
pwd
ls -la
binary
get FILE
quit

If login succeeds but listing/transfer fails, use the client's passive command to toggle data-channel mode and retry once before changing credentials.

Decisive output: code 230 accepts the login; directory listings and successful RETR establish read access. Inspect downloaded backups, configuration, keys and source locally. Store target artifacts outside this public repository.

Variant — authenticated FTP

ftp TARGET

Enter USER and the password when prompted. Enumerate from the authenticated root again; it may expose a different namespace than anonymous access.

Variant — curl listing, download and bounded write test

curl --list-only ftp://TARGET/
curl -o FILE ftp://TARGET/path/FILE
curl --user USER ftp://TARGET/
curl --user USER -o FILE ftp://TARGET/path/FILE
curl --user USER --upload-file ./probe.txt ftp://TARGET/path/probe.txt

Omit --user for anonymous access. Let curl prompt for an authenticated password instead of placing it in shell history. Upload only a harmless uniquely named probe when write validation is necessary and authorized; remove it through the FTP client after the test.

Variant — focused Nmap helpers

nmap -sV -p PORT --script ftp-anon,ftp-syst TARGET

ftp-anon checks anonymous login and may flag writable entries; ftp-syst asks for server/system information. Manually confirm useful access with a protocol client.

Failure cues: 530 means that login was rejected, not that FTP has no other usable identity. A listing failure after 230 may be a data-channel/passive-mode or authorization problem. A successful upload proves write access only; it does not prove that a web server, scheduled task or privileged process consumes that file.

Next action: inspect recovered files; record exact read/write boundaries; validate any new credential once against its likely service; send a writable-consumer hypothesis to the appropriate web, execution or privilege-escalation block.