FTP Authentication Attacks

FTP authentication attacks focus on abusing or bypassing authentication mechanisms to gain unauthorized access to the FTP service. This includes anonymous access abuse, credential validation, password spraying, and controlled brute-force attacks. FTP transmits credentials in cleartext. Any successful login is also a chance to capture other users' credentials on the same network.

Anonymous Login Abuse

Some FTP servers allow login using the anonymous account without credentials or with a generic password. This is common on misconfigured internal servers and file distribution hosts. A 230 Login successful response confirms anonymous access. A 530 Login incorrect response means anonymous login is disabled. Once logged in, run ls to list available files and get to download them. Check for readable configuration files, backup archives, and credential files left by administrators. Some servers allow anonymous write access, which opens additional attack paths such as uploading web shells or replacing existing files.

Test a Specific Credential Pair

This technique validates a known or suspected username and password pair against the FTP service. Use it to validate credentials found in config files, captured cleartext traffic, or OSINT. Default credentials are worth testing first. Common defaults include admin:admin, ftp:ftp, and admin:password. A 230 Login successful response confirms valid credentials. A 530 Login incorrect response indicates failure. After a successful login, check the home directory for sensitive files and test write access with put. Note which directories are accessible, since the account may be jailed to a specific path.

Password Spraying

Password spraying tests one common password across multiple user accounts, reducing the risk of account lockouts. Use this when you have a list of valid usernames and want to test a seasonal password, a company default, or a policy-minimum password. Hydra outputs each valid credential pair on a successful attempt. Look for lines marked with a [SUCCESS] tag. If no credentials match, try a different password candidate before escalating to brute-force. Build your username list from FTP banner enumeration, OSINT, or previous enumeration phases.

Password Spraying with Hydra

Password Spraying with NetExec (nxc)

nxc outputs a [+] marker for valid credentials and a [-] marker for failures. Valid logins are easier to spot in nxc output than in Hydra when the user list is long. Run this after Hydra if you want a second confirmation or cleaner output.

Controlled Bruteforce Attacks

Brute-force attacks attempt multiple passwords against FTP user accounts. This technique is high risk and should only be used when explicitly allowed. Use a targeted wordlist rather than a full dictionary. Start with rockyou.txt or a curated list based on the organization's password policy. Hydra prints each valid credential pair as it finds them. The -t flag controls the thread count. Lower it if the server drops connections. A value of 4 is a safe starting point for FTP. If the service becomes unresponsive, reduce threads further or add delays with -W.

Bruteforce with Hydra

Bruteforce with NetExec (nxc)

nxc supports concurrent workers. Use --threads to control the rate if the server throttles connections. The --no-bruteforce flag pairs each user with the corresponding password from the list instead of testing all combinations. Use it when you have credential pairs to validate rather than running a full cross-product attack.

The --continue-on-success flag allows continued testing after a valid credential is found. Without it, nxc stops at the first match. Use this flag when testing for credential reuse across multiple accounts. After finding valid credentials, log in manually with the FTP client to confirm access and explore available directories.

Risks of Bruteforcing

• Account lockouts

• Service disruption

• Security alert triggering

Use brute-force attacks only when:

• No lockout policies exist

• Scope explicitly allows aggressive attacks

FTP servers often have no native lockout mechanism. A WAF or IDS in front of the service may block your source IP after repeated failures. If attacks stop returning responses, check connectivity to the target first. Some servers silently accept login attempts but always return a failure code past a threshold. Reduce concurrency or rotate source IPs if you suspect rate-limiting. On Windows FTP servers running IIS, account lockout follows the domain policy. Three to five failed attempts may lock a domain account. Know the lockout threshold before running any automated attack against a domain-joined FTP server.