Use anonymous or authenticated FTP file access
Needs: Anonymous login allowed or a valid FTP identity; data-channel connectivity and object-specific read/write rights
Anonymous access
# Baseline: anonymous access
ftp TARGET
Then
# Then
status
pwd
ls -la
binary
get FILE
quit
Decisive output: code
230accepts the login; directory listings and successfulRETRestablish read access. Inspect downloaded backups, configuration, keys and source locally. Store target artifacts outside this public repository.
If login succeeds but listing/transfer fails, use the client's
passivecommand to toggle data-channel mode and retry once before changing credentials.
Authenticated FTP
# Variant — authenticated FTP
ftp TARGET
# 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
# Variant — focused Nmap helpers
nmap -sV -p PORT --script ftp-anon,ftp-syst TARGET
Omit
--userfor 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.
Failure cues:
530means that login was rejected, not that FTP has no other usable identity. A listing failure after230may 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.
Verify → Retrieve recognizable bytes or independently verify an uploaded canary; distinguish listing, read and write rights.
If it fails → Login succeeds but transfers hang: diagnose the data path. A writable upload directory alone does not establish command execution. More detail ↓
Explanation & examples
Use anonymous or authenticated FTP file access
- USE WHEN
- An FTP banner or accessible listing
- STARTING ACCESS
- A confirmed reachable application; anonymous context or one identified credential
- RESULT
- Retrieved files, configuration or a verified writable location
Recognize the clue
After identifying FTP, test the allowed anonymous context or one known credential and inspect its directory namespace.
curl -v ftp://TARGET/
curl -v --user 'USER:PASSWORD' ftp://TARGET/
230 Login successful
LIST: application.conf; backups/
RETR application.conf: 226 Transfer completeMeans: A listing identifies candidate artifacts; a completed RETR with recognizable bytes establishes read access.
Confirm: Validate the account context, file contents, data-channel reachability and any separate write/consumer conditions.
- After validation
- The relevant file is readable and contains a current typed secret: follow credential classification.
- Ruled out in this context
- Anonymous login is denied: rule out anonymous access, retaining authenticated FTP as a separate possibility.
- Still inconclusive
- Login works but data transfer hangs: inspect active/passive data routing before concluding file access is denied.
Troubleshooting: Login succeeds but transfers hang: diagnose the data path. A writable upload directory alone does not establish command execution.
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
At the prompts, try user anonymous and an email-like password. Then:
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
230accepts the login; directory listings and successfulRETRestablish read access. Inspect downloaded backups, configuration, keys and source locally. Store target artifacts outside this public repository.
Variant — authenticated FTP
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
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
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:
530means that login was rejected, not that FTP has no other usable identity. A listing failure after230may 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.
Why it works
FTP authentication and directory listing do not guarantee downloads or uploads. Passive/active data channels can fail independently of the control connection; uploaded bytes need a separate execution consumer.
Worked example · hypothetical
Observation: anonymous login succeeds. Test: list and download one relevant readable configuration. Illustrative output: an application username is present. Interpretation: classify its credential context and test only a compatible service.
New identity, privilege, host or route? Re-enumerate → All topic tasks →