Several new plugins for Nessus were recently introduced which can detect FTP servers that are fake:
- Fake FTP server accepts a bad sequence of commands
- Fake SMTP/FTP server (backdoor)
- Fake FTP server does not accept any command
- Fake FTP server accepts any command
The basic concept is that a hacker, botnet, malware or virus needs to have some sort of method for communication, to receive commands, to transfer data or provide continued access so they use a backdoor. But rather than use some sort of custom or proprietary command and control, they use a service that looks like an FTP server.
By "looking" like an FTP server, connecting to the daemon port (usually TCP port 21, but could be any port really) results in an FTP banner. Some of the fake FTP daemons that have been encountered even implement some of the actual FTP protocol. However, most fake daemons don't support all of the FTP options and error codes which is what the above Nessus plugins try to ferret out.
Below are two screen shots of different real-world systems that had an FTP service discovered on a port other than 21. One even claims to be a Microsoft server.
These plugins are available in the FTP and Backdoors Nessus plugin families. If you are doing a complete audit of a system or network, including these checks is a good idea. If you would like to simply scan your network for these checks, the following Nessus policy file can be used to quickly run your scans with the Nessus Client.
It includes three polices that enable the four FTP checks and "Experimental" NASL plugins. One policy performs a full TCP port scan, the other a generic scan and the last one just looks at port 21. To use this policy, download this file to your system and open it up with the Nessus Client and then connect to your Nessus canner and add your target network ranges. If you have not performed a plugin update recently, or don't have automatic updates enabled, make sure you grab the latest plugins (which you should be doing anyway) before trying this policy.
These plugins were also built to minimize security warnings. For example, if a fake FTP server always logs you in this can end up mis-identifying it as a valid Anonymous FTP server.
The hunt to find these types of backdoors should throw into light how your organization can detect these types of changes:
- Do you have some sort of realtime network monitoring that can alert on new services? Products like the Passive Vulnerability Scanner sniff your traffic in real time and can send an alert when they find new hosts, services and vulnerabilities.
- Do you have some sort of way to compare ongoing active vulnerability scans with each other and identify what is new? Products like the Security Center and Nessus automatically produce reports about what is new for every scan and also keeps a historical history for each vulnerability for when it was first found and last seen.
- Do you have some sort of process to identify services that are unauthorized? Most Nessus users tend to think about finding vulnerabilities and mitigating the critical ones, but for compliance and consistency, many organizations simply want to know if a server or service is authorized or not and if it is being managed.
- And if you do find such a backdoor on your network, being able to turn to netflow, firewall logs, IDS logs or whatever you have generating logs is also important. Products like the Log Correlation Engine can show you potentially how this system was compromised and if any other local systems have been communicating with it.
These plugins were written by long time Nessus plugin contributer Michel Arboi. Michel has his own blog, which includes lots of very good Nessus information such as a recent post on how to configure Nikto within a Nessus scan.
We've blogged before about hunting backdoors and detecting compromised hosts with Nessus. If you are hunting for these types of issues, also keep in mind that any high-port FTP service should be suspected, as that is a very common backdoor file transfer technique. If this topic is of interest to the reader, the older blog postings are listed here:
- Detecting Compromised Windows Hosts
- Detecting "Off Port" Services
- Hunting Symantec Worms
- Using "New Port Browsing" Events to find Worm/Trojan/Rootkit Activity