Web server botnets and hosting farms as attack platforms


Gadi Evron

Beyond Security, Israel

Kfir Damari

Beyond Security, Israel

Noam Rathaus

Beyond Security, Israel
Editor: Helen Martin


Web server malware may be used to establish a foothold for the general exploitation of the infected server, or to compromise the server for specific purposes ranging from DDoS to spamming. Some more advanced uses include the construction of botnet armies from these web servers. Gadi Evron and his colleagues describe the problem.


Malicious programs, including bots, often incorporate a spreading mechanism that may be based either on software vulnerabilities exploiting the operating system, the applications running on it or on social engineering tricks, which exploit the gullibility of the user. However, the malware itself is, in most cases, operating system specific.

However, where web server malware is concerned, the application is attacked first and only later is the operating system examined to determine how further exploitation can be achieved. Another difference with web server malware concerns the type of exploits used for propagation and infection.

In terms of technology, web server malware utilizes known methods, from using search engines such as Google to propagate, to infection utilizing file inclusion vulnerabilities, also known as Remote File Inclusion (RFI). What is new is the sheer scale of the problem, which has not been thoroughly documented until now. Currently, anti-virus software detects only a small percentage of web server-infecting malware, and literature on the subject of file inclusion and PHP shells is readily available.

Over the past two years, several web server malware attacks have been noted. A good example is the Santy worm, which spread through the use of Google. However, Santy is long behind us and today there are hundreds of samples of web server malware being spread on the Internet. A recent example is SpamThru, in which a well-known web shell was used for spamming (see http://www.secureworks.com/analysis/spamthru/).

Web server malware is not platform-dependent but relies on scripting languages such as PHP, ASP and Perl that are interpreted by the web daemon. This enables the malware to execute on any environment that supports scripting languages – meaning Apache, IIS and other web daemons on Windows, Linux or any other operating system.

Web server malware, typically in the form of PHP shells, may be used to establish a foothold for the general exploitation of the server in question, or to compromise the server for specific purposes ranging from DDoS to spamming. Some more advanced uses include the construction of botnet armies from these web servers (which represents a major difference from the botnets we have seen in the past, which were made up mainly of home-user broadband computers). More disturbing is the fact that these botnets are now also constructed as ‘Linux botnets’ or ‘IIS botnets’, with entire armies of high-bandwidth business customers or production servers ready to wage war or deal in online criminal activity.


Web server-based malware is as arbitrary in propagation as any other, with one significant difference: the victim pool is pre-selected ahead of time. Searching for strings such as ‘Powered by phpBB’ in Google search quickly identifies servers running web applications such as the phpBB forum system.

PHP malware that searches for vulnerable websites via Google and MSN.

Figure 1. PHP malware that searches for vulnerable websites via Google and MSN.

For the most part, these searches target PHP applications. One reason for this is that PHP applications tend to have security vulnerabilities in far higher numbers than applications built in other languages. More importantly, the large number of open source PHP web applications available for download on the Internet makes these applications very accessible.

Each of the web servers found to be running or suspected of running the searched-for web applications will be attacked and, if vulnerable, malware will be injected into them. In some cases, web servers will be arbitrary choices and attacked regardless of the search engine results. Attempts to reach the web application’s vulnerable code will be made blindly, sending an HTTP request to the web server in the hope that phpBB (for example) is installed, is vulnerable and that the default directory path was used.

The injection

In most cases, malicious code is injected into a web server system via a file inclusion attack.

File inclusions are vulnerabilities in web applications that allow an attacker to execute a script by including it in an existing script. For example, the include() function in PHP can be used, providing a URL into an unchecked variable called arbitrarily in an include statement, followed by the execution of the included script.

The following PHP code allows the server to act like a client and request a file specified by the user:

<?php include ($_GET[page]); ?>

The following HTTP request shows how an attack could take place against that PHP code:


Other types of vulnerability in web applications are also used, including URL parsing code execution vulnerabilities, POST vulnerabilities and arbitrary file upload vulnerabilities.

In essence, a script that is downloaded (or uploaded, depending on the vulnerability) can be used to do anything it is programmed to do, with the privileges of the web daemon.

In the past few months alone dozens of file inclusion attacks have been disclosed publicly. Effectively, a web application’s vulnerability serves as a remote exploit for attacking the web server. In one recent case, a group kept a list of hundreds of compromised web servers with their exploit command in a list of URLs, and referred to them as ‘shells’:

                OwneD By [GaspeR]‘-
                Group ShellBR

Server: irc.undernet.org

Canal: #ShellBR

Aconcelho a Quem For Testar As Shell‘s Que mude As Cmd‘s !






The compromise

Once compromised, a system will often be injected with further malware, such as scripting tools or binaries.

On a Linux system, ELF malware based on the likes of Kaiten can be uploaded, and on a Windows system, PE malware such as Agobot or Rbot may be uploaded. In most cases an assortment of malware is dropped rather than individual samples.

For example, in one case RST-b was uploaded to a Linux-based server disguised as the legitimate application sshd (or sshd was merely infected with it) while the legitimate IRC bot EnergyMech was also uploaded and connected to the command and control server of the botnet in question. This is similar to how some botnet controllers from the Windows realm work: a legitimate IRC client, such as mIRC, is uploaded along with malicious scripts. This used to be very commonplace in the Windows botnet scene. In the very early days of botnets regular IRC bots such as EnergyMech or Eggdrop became malicious when loaded with harmful scripts.

One function of the dropped PHP shells is database dumping, which is one of the primary goals of some of these groups. Since PHP is often the primary choice of web database interfaces, this type of attack goes hand-in-hand with web server malware. In the case of SpamThru, the spammer was using R57shell to steal databases in order to obtain targeted email addresses (hacking into investment news sites). However, some of the databases they obtained actually contained stored credit card numbers from a payment system. Some interesting statistics can be found at http://www.secureworks.com/analysis/spamthru-stats/.

Types of web server malware

There are several main groups of script ‘tools’ which are typically uploaded using these attacks:

  • Tester (echo tool): these tools are often very small, simplistic and built as web pages which can be accessed from the Internet. By accessing these scripts one can easily determine whether a server is vulnerable to a particular attack. On occasion, more functionality may be added to them. An example is shown below:

  • Beachhead: this tool establishes a beach head on the system by uploading a script which allows the remote attacker to take further control of the system. These include remote shells and connect-back shells.

    Remote shell

    Instead of opening a port and binding a shell to it, these tools construct GUI web applications that allow the remote attacker to launch commands and upload other tools.

    Connect-back shell

    Much like a remote shell, except it connects to the remote attacker.

  • Downloader: a small, limited scripting tool that often has the sole purpose of downloading additional malware.

  • Compromise tool: a full attack tool built with the purpose of compromising the attacked system by exploiting privilege escalation vulnerabilities with local kernel exploits (Linux) or adding a new administrator account (Windows).

  • Defacement tool: a compromise tool built with the sole purpose of defacing a website.

  • Backdoor tool: a general backdoor tool designed to allow anything from file uploads to port scanning.

  • Anonymous mailer: designed to allow anonymous mailing.

  • Spam tool: these anonymous mailers send spam in bulk.

  • DDoS tool: used to launch DDoS attacks against remote systems.

  • Bot: much like any other backdoor tool, only it connects to a centralized command and control (C&C) server, often on IRC, to receive commands.

  • Worm: a self-propagating script of any of the above-mentioned types.

In our research, we looked into over 250 unique scripting malware sample variants. Of these, we found 34 main source families. The most common of these families were:

  • Echo Executer (tester): echoes a message if the inclusion is successful.

  • VulnScan (backdoor, shell): VulnScan is one of the most elaborate tools available today. With various versions – mostly versions 2–8 – it provides almost any conceivable option for the bad guy to use. It is based on an earlier script version which is still in the wild.

  • Morgan/Alex (backdoor, shell): one of the most heavily circulated tools in the wild, on a par with the VulnScan tools. While the VulnScan tools are mostly dropped on the web server after an initial infection, the Morgan malware stands on its own. Some of what Morgan allows includes: upload, create new directory, create new file, delete, chmod, rename, copy, execute command, edit files, run shell and so forth.

  • Shellbot (bot, worm, DDoS): a basic bot with many variants. Some include DDoS abilities as well as a spreading mechanism.

  • Phpwriter (backdoor, defacer): general usage tool, also the most common automatic defacement tool in the wild.

  • R57shell (backdoor, shell): a very elaborate dropped tool.

  • C99shell (backdoor, shell): another one of the most elaborate dropped tools in the wild.


We examined C99shell in a little more detail and found that it was created by ‘tristram [CCTeaM - Captain Crunch Security Team]’. It is a remote hacking console and has a number of features, which include the ability to list host information, provide a directory listing and execute the following shell commands:

  • Find all suid files: “find / -type f -perm -04000 -ls”

  • Find suid files in current dir: “find . -type f -perm -04000 -ls”

  • Find all sgid files: “find / -type f -perm -02000 -ls”

  • Find sgid files in current dir: “find . -type f -perm -02000 -ls”

  • Find config.inc.php files: “find / -type f -name config.inc.php"

  • Find config* files: “find / -type f -name \”config*\””

  • Find config* files in current dir: “find . -type f -name \”config*\””

  • Find all writable folders and files: “find / -perm -2 -ls”

  • Find all writable folders and files in current dir: “find . -perm -2 -ls”

  • Find all service.pwd files: “find / -type f -name service.pwd”

  • Find service.pwd files in current dir: “find . -type f -name service.pwd”

  • Find all .htpasswd files: “find / -type f -name .htpasswd”

  • Find .htpasswd files in current dir: “find . -type f -name .htpasswd”

  • Find all .bash_history files: “find / -type f -name .bash_history”

  • Find .bash_history files in current dir: “find . -type f -name .bash_history”

  • Find all .fetchmailrc files: “find / -type f -name .fetchmailrc”

  • Find .fetchmailrc files in current dir: “find . -type f -name .fetchmailrc”

  • List file attributes on a Linux second extended file system: “lsattr -va”

  • List open ports: “netstat -an | grep -i listen”

  • Custom command

C99shell can also perform the following operations: search file (using regexp), upload file, create directory, download/open a file and create a text file.

Surrounding issues

As millions of web servers running web applications are at risk, and thousands are being defaced every month, this is a serious threat.

Most at risk are ISPs with hosting farms and colocation facilities. Their services are built to be cheap and provide low-cost, hassle-free hosting services. When even one website out of 3,000 on a shared hosting server is compromised because of a web application any user may have installed, the entire server can be compromised and all websites hosted on that server can be defaced.

Controlling what applications users install is not feasible, and monitoring these and patching them for the latest security vulnerability is virtually impossible, even if patches are available. The low cost of these services also means that ISPs cannot afford to intervene in security and enforcement issues. Dealing with anything other than routine maintenance may mean operating at a monetary loss for several billing cycles.

Some solutions that have been suggested include vulnerability assessment scanning of the servers. Indeed, vulnerability scanning solutions can detect and alert when some web applications are vulnerable. This alone cannot prevent these attacks, but will help minimize the risk and allow resources to be concentrated on those hosts that are known to be vulnerable. Other possible solutions include running the services within virtual or chrooted environments, which offers a limited, more costly, solution.

The authors of this article have heard of some cases in which ISPs quietly patched some of the more notorious web applications without their clients ever finding out.

None of these solutions is the silver bullet.

Another important issue is the treatment by some of web vulnerabilities as ‘less critical’ or ‘kiddie vulnerabilities’. File inclusion attacks, for instance, are equivalent in effect to code execution and should not be underplayed or ignored.

Honeynets and mitigation

Some non-application-specific solutions include a combination of research and operational mitigation. As an example, research into web honeypots for file inclusion attacks can pinpoint attacks and offer a variety of options, for example:

  • Anti-virus scanning tools for detecting malicious files.

  • Blacklisting and filtering attacking IP addresses.

  • Blacklisting and filtering the URLs from which tools are downloaded.

  • Taking down malicious websites hosting these tools through abuse reports.

An on-access anti-virus scanner would significantly slow down a production web server, making it impractical to run, even if it runs on a platform on which the anti-virus can operate locally or remotely. An on-demand scanner, however, would be able to pinpoint potentially compromised accounts.

At the time of publication of this article, The Web Honeynet Task Force (not to be confused with The Honeynet Project) is set to begin operation (see http://www.webhoneynet.com/).

The Web Honeynet Task Force reports hundreds of file inclusion attempts detected every day with dozens of new malicious URLs hosting the malware. The task force, which has been established by Gadi Evron and is run by the ISOTF and SecuriTeam, offers free samples to any trusted member of the ISOTF communities through the MWP (malicious websites and phishing) group. The task force also shares openly with any trusted new member of the honeynet which submits honeypot information.

Currently, the task force reports that most attempts originate from the same IP addresses (when looking at aggregated data over time). This world of web server attacks currently stands relatively unopposed on the Internet. It is time now to start escalating the detection and mitigation of this threat – clearly, tools and response mechanisms need to be put in place to combat the bad guys on this front.

General security best practices are also of importance and should not be ignored. For example, a secure web server should not allow web surfing and outgoing connections to HTTP or FTP servers. This way, it may still be vulnerable but, when attacked it will not be able to download the malicious code. Another best practice that should be followed is the hardening of your web server software and related software. For example, PHP has an option to disallow treating URLs as files. This should be set to off if it does not disturb your application. As these types of attacks are web server specific, it is also wise to avoid storing sensitive information where a web server can access such as a database, whether local or remote. Although these solutions are far from perfect, and the bad guys can adapt their methods to work around them, different layered approaches can help mitigate the threat.

For more details on the Web Honeynet Task Force readers should visit http://www.webhoneynet.com/ or http://isotf.org/.



Latest articles:

VB2017 paper: Walking in your enemy’s shadow: when fourth‑party collection becomes attribution hell

Attribution is complicated under the best of circumstances. Sparse attributory indicators and the possibility of overt manipulation have proven enough for many researchers to shy away from the attribution space. And yet, we haven’t even discussed the…

Throwback Thursday: CARO: a personal view

As a founding member of CARO (Computer Antivirus Research Organization), Fridrik Skulason was well placed, in August 1994, to shed some light on what might have seemed something of an elitist organisation, and to explain CARO's activities and…

VB2016 paper: Uncovering the secrets of malvertising

Malicious advertising, a.k.a. malvertising, has evolved tremendously over the past few years to take a central place in some of today’s largest web-based attacks. It is by far the tool of choice for attackers to reach the masses but also to target…

VB2016 paper: Building a local passive DNS capability for malware incident response

Many security operations teams struggle with obtaining useful passive DNS data post security breach, and existing well-known external passive DNS collections lack complete visibility to aid analysts in conducting incident response and malware…

Throwback Thursday: Tools of the DDoS Trade

In September 2000, Aleksander Czarnowski took a look at the DDoS tools of the day.

Bulletin Archive