Not-So-Common, Common-Sense Security: Anonymous FTP Shares

⚠️ Legal & Ethical Disclaimer The information presented in this post is provided for educational and informational purposes only. All techniques, tools, and examples discussed are intended to be used only in environments you own or have explicit authorization to test.

The author assumes no responsibility or liability for any misuse of the information contained herein. You are solely responsible for ensuring that your actions comply with applicable laws, regulations, and organizational policies.

Overview

File Transfer Protocol, or FTP, is one of the oldest protocols still in active use across enterprise environments. Originally designed for simplicity over security, it has no encryption by default and supports a feature that has persisted for decades: anonymous access.

When an FTP server has anonymous access enabled, any user with network access can connect using the username anonymous and an arbitrary password without valid credentials. This was once an intentional design choice for distributing public files. In modern environments, it is frequently overlooked rather than deliberately configured.

From an attacker's perspective, an FTP server with anonymous access enabled is a low-effort, high-value target. The tooling to interact with it is universally available, and the contents of improperly secured servers frequently include far more than was ever intended to be exposed.

Why Anonymous FTP Still Exists

Anonymous FTP access persists in enterprise environments for many of the same reasons anonymous SMB shares do. A server is stood up for a specific purpose, access is opened broadly for convenience, and nobody revisits the configuration once the immediate need is met.

Common origins include legacy file distribution systems that predate modern alternatives, vendor or partner access that was never formally decommissioned, default configurations on FTP server software that were never hardened, and internal tooling or deployment pipelines that rely on unauthenticated file retrieval. In some cases, the FTP service itself is running as part of a larger application stack and the team responsible for the application is unaware that the FTP component is exposed at all.

Enumerating Anonymous FTP with Nmap

Nmap is typically the first tool used when identifying FTP services on a target network. Beyond port discovery, Nmap's scripting engine includes scripts specifically designed to test for anonymous FTP access.

To scan for FTP services and check for anonymous login in a single command:

nmap -p 21 --script ftp-anon [TARGET]

The ftp-anon script attempts an anonymous login and, if successful, will report back that anonymous access is permitted along with a directory listing of the root FTP path. This immediately tells you both that the misconfiguration exists and what is visible at the top level of the share.

To scan across a subnet:

nmap -p 21 --script ftp-anon 192.168.1.0/24

This approach scales anonymous FTP discovery across an entire network segment, making it straightforward to identify whether the issue is isolated to a single host or present across multiple systems.

Enumerating Anonymous FTP with the Native FTP Client

The native ftp client is available on virtually every operating system and requires no additional tooling. While it lacks the automation capabilities of Nmap or Metasploit, it provides direct, interactive access to an FTP server and is useful for manually exploring share contents once access is confirmed.

To connect to a target FTP server:

ftp [TARGET]

When prompted for a username, enter anonymous. When prompted for a password, enter any value or leave it blank. Many FTP servers with anonymous access enabled will accept any input at the password prompt.

Name: anonymous
Password: anonymous@test.com

Once connected, standard FTP commands can be used to explore the server:

ls          # List directory contents
cd [DIR]    # Change directory
get [FILE]  # Download a single file

To download all files in the current directory, disable per-file prompting and use mget:

prompt OFF
mget *

prompt OFF disables per-file confirmation and mget * retrieves all files in the current directory.

Some FTP client implementations, including the native Linux ftp client on many distributions, support a recurse toggle that enables traversal into subdirectories:

recurse ON
prompt OFF
mget *

When recurse ON is set, mget * will descend into subdirectories and retrieve their contents as well. This is not part of the FTP protocol specification, however, and support varies by client — behavior should be verified against the specific client in use before relying on it.

For a guaranteed recursive download regardless of client, wget or lftp are more reliable choices:

wget -r ftp://anonymous:anonymous@[TARGET]/

lftp -e "mirror --parallel=5 . /local/path; quit" -u anonymous, ftp://[TARGET]

Both wget and lftp will traverse the full directory tree and download all accessible content in a single command, making them faster choices when a complete collection of the share is needed.

Enumerating Anonymous FTP with Metasploit

The Metasploit Framework includes an auxiliary module specifically designed to test for anonymous FTP access. This is particularly useful during engagements where you are already working within Metasploit or need to scan multiple targets systematically.

Launch Metasploit and load the module:

msfconsole
use auxiliary/scanner/ftp/anonymous

Configure the target or target range:

set RHOSTS [TARGET]
set RHOSTS 192.168.1.0/24

Run the scan:

run

The module will attempt an anonymous login against each target and report whether access was permitted. It will also indicate whether read and write permissions are available, which is particularly important. Write access to an FTP server with anonymous access enabled introduces a separate class of risk: an attacker can upload files, potentially including web shells if the FTP root overlaps with a web server directory.

What Attackers Look for Once They're In

As with anonymous SMB shares, gaining access is only the first step. The value of the finding depends on what the server contains.

In enterprise environments, FTP servers with anonymous access enabled frequently hold content that was never intended to be broadly accessible:

Configuration files and application properties: Database connection strings, API keys, and service account credentials often end up on FTP servers as part of deployment or backup workflows
Scripts and automation files: Batch files, shell scripts, and PowerShell scripts used for scheduled tasks or provisioning frequently contain hardcoded credentials
Backup archives: Compressed database dumps, configuration backups, and application state files are commonly staged on FTP servers before being moved elsewhere, and are frequently never cleaned up
Internal documentation: README files, setup guides, and network documentation left behind from initial deployments can reveal naming conventions, architecture details, and access procedures
Sensitive data files: In some environments, FTP servers are used as informal staging areas for reports, exports, or data transfers that contain personally identifiable information or financial data

Write Access

Write access should be treated as a critical finding. In addition to data exposure, it enables attackers to stage tools, plant malicious files for downstream systems, and, in environments where FTP directories are web-accessible, achieve remote code execution via web shells.

In environments where internal systems automatically retrieve files from FTP locations, anonymous write access introduces a supply chain risk — attackers can plant files that are later executed or processed by trusted systems. This shifts the risk from passive data exposure to active compromise of downstream infrastructure, often without any direct interaction with the target system.

Mitigation & Hardening Recommendations

Note: Any mitigation or hardening steps should be thoroughly tested in a non-production or staged environment prior to deployment to ensure there is no unintended impact to business operations or dependent services.

Audit and Inventory Existing FTP Services

Before making configuration changes, identify every system in the environment running an FTP service and determine whether anonymous access is enabled on each. FTP services frequently run as components of larger application stacks and may not be tracked in asset inventories. An Nmap scan across your internal network ranges targeting port 21 with the ftp-anon script is a fast way to establish scope.

Enable Logging Before Making Changes

Before modifying any FTP server configuration, ensure that access logging is enabled on the affected system. Most FTP server software logs connections and commands by default, but verify this is active and that logs are being retained. Review existing logs to understand what accounts or systems have been accessing the server, how frequently, and what files have been retrieved or uploaded. This context is essential before restricting access, as it identifies whether any legitimate processes depend on the current configuration.

Disable Anonymous Access

Once you have a clear picture of what is using the server, disable anonymous login directly in the FTP server configuration. The specific steps vary by software:

vsftpd (Linux): Set anonymous_enable=NO in /etc/vsftpd.conf and restart the service
ProFTPD: Set <Anonymous> block to disabled or remove it from the configuration entirely
IIS FTP (Windows): In IIS Manager, navigate to the FTP site, open FTP Authentication, and disable Anonymous Authentication
FileZilla Server: In the user manager, ensure no account is configured with the username anonymous and that anonymous access is not enabled in server settings

After making changes, validate by attempting an anonymous connection using the native FTP client or the Nmap script.

Replace FTP with Secure Alternatives

Where file transfer functionality is still required, FTP should be replaced with a protocol that supports encryption and modern authentication:

SFTP (SSH File Transfer Protocol): Encrypts both authentication and data in transit; widely supported across platforms
FTPS (FTP over TLS): Adds TLS encryption to the FTP protocol; appropriate where FTP-specific compatibility is required
HTTPS-based file transfer: Many organizations replace internal FTP with web-based transfer solutions that integrate with existing identity providers

Restrict Network Access

If FTP cannot be immediately decommissioned, restrict access to the service at the network level. Firewall rules should limit port 21 access to only the specific IP addresses or subnets that have a legitimate need. This reduces exposure without requiring immediate application changes and buys time for a proper migration.

Review Write Permissions

Regardless of whether anonymous access is disabled, audit the write permissions on any FTP server. Write access for anonymous or broadly scoped accounts should be treated as a critical finding, particularly on servers where the FTP root is shared with or accessible by a web server process.

Detection & Monitoring

Key Event to Monitor

The most direct signal for anonymous FTP access is a successful authentication event using the username anonymous or ftp in your FTP server logs. Most FTP server software records the username used for each connection by default.

Filter for:

Username: anonymous or ftp (both are commonly accepted by FTP servers with anonymous access enabled)
Result: Successful authentication (response code 230)

Any successful anonymous login to a server that should not permit it should be treated as a priority investigation.

FTP Server Log Patterns

Beyond successful logins, the following log patterns are worth monitoring:

STOR commands: Indicate a file upload. Anonymous write access is a high-severity finding and any upload activity warrants immediate review
RETR commands at scale: Bulk file retrieval in a short window may indicate an attacker collecting content using mget or a similar recursive download
Connections from unexpected sources: Anonymous FTP access from external IP addresses or from internal hosts that have no business reason to access the server

Windows Event Logs (IIS FTP)

For environments using IIS-hosted FTP, the following Windows Security event provides relevant context:

Event ID 4624: Successful logon with Logon Type 3 (Network) and an account name of ANONYMOUS LOGON or FTP

SIEM Integration

Forward FTP server logs to a SIEM or centralized logging platform. Create alerts for:

Any successful anonymous FTP authentication
STOR commands from anonymous sessions
High-volume RETR activity from a single source in a short time window

MITRE ATT&CK Mapping

Anonymous FTP access frequently spans multiple ATT&CK tactics, beginning with discovery and quickly progressing into credential access and data collection depending on what the server contains.

Tactic	Technique	ID	Description
Discovery	Network Service Discovery	T1046	Identifying FTP services exposed on target systems
Discovery	File and Directory Discovery	T1083	Browsing FTP server contents to identify files of interest
Credential Access	Unsecured Credentials	T1552	Retrieving credentials from scripts, configs, or archives found on the server
Credential Access	Credentials in Files	T1552.001	Accessing plaintext passwords stored in files on the FTP server
Collection	Data from Network Shared Drive	T1039	Collecting sensitive files from an accessible FTP server
Command and Control	Ingress Tool Transfer	T1105	Uploading tools or payloads to a writable FTP server

Why This Matters

Anonymous FTP is one of those findings that tends to generate mild concern on first read and significant concern on closer examination. The protocol is old, the misconfiguration is simple, and the contents of improperly secured servers are consistently more sensitive than anyone involved remembers putting there.

What elevates this beyond a routine hardening item is the combination of factors: a protocol with no native encryption, anonymous access that requires no credentials, and a server that has often been accumulating files for years without anyone auditing its contents. Any one of those conditions creates risk. Together, they create a clear and often underestimated path into an environment.

Disabling anonymous access and replacing FTP with a secure alternative where file transfer is still required are both well-understood and achievable steps. As with most findings in this series, the gap is rarely capability. It is awareness of what has been left running, and what it contains.