Vbulletin Infections Fighting for Dominance

Labs Note

A very common pattern in compromised websites is the presence of backdoors and other malicious codes. Attackers use different techniques and malware to abuse of server resources, distribute spam and at the same time, maintain access to the site for as long as they can.

One of the most used backdoors for that purpose is the C99 web shell. For those of you who are not familiar with it, C99 is a variation of the WSO shell with additional functionalities. It pretty much allows the attacker to manage your website remotely, including executing arbitrary remote commands directly into your system, navigate through a file manager interface, read arbitrary file and much more.

This kind of shell is most typically found on files but recently we found it on a database within a vBulletin site. vBulletin is a prime candidate for database based backdoors due to the ability that the CMS grants to running PHP directly from the database without any kind of control.

One of the most used table to store malicious content is the vBulletin ‘datastore’ table, more specifically the ‘pluginlist’ record, through this table they can easily add any kind of PHP code and that code will become part of any plugin that is installed on the website.

Sometimes the attackers also add the malicious code as an entire plugin by adding it on the ‘plugin’ table. In this case, we have a plain regular shell appearing when we access /forum.php/subscriptions.php

The path where it is accessible may look strange but on vBulletin the requests are handled by forum.php instead of the common index.php.

Upon tracing it we found the culprit in the database within the ‘plugin’ table:

From the image above, we see 2 records posing as init_startup plugins. This is a highly unusual scenario as it’s not valid for more than 1 plugin to have the same name within vBulletin.

We identified the plugins responsible for displaying the shell, however those still need to have an occurrence within the ‘pluginlist’ row inside the ‘datastore’ table for it to be actually enabled and act on the site.

By taking a quick look at those records, we found various pieces of malicious code

s:12:"init_startup";s:63824:"if (strpos($_SERVER['PHP_SELF'],'subscriptions.php')) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}
if (strpos($_SERVER['PHP_SELF'],"subscriptions.php")) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}";

When checking the database entry, we see 2 sets of codes that have the same purpose which may indicate that different attackers exploited the same vulnerability through an automated system and added the same malware.The funny thing is that after the first “exit” instruction, the second set of code becomes non-functional as it will no longer be read by the server and executed.

In other words, the first attacker compromised the site and then the second one attempted the exact same thing but since the “init_startup” already existed, their system simply infected the already existing plugin. Since the first infection was the regular shell and not the c99, this means that the c99 did not work.

There was also another small but powerful malware added into the database


Through this code the entire forum is a backdoor regardless of the area you are in, all that is required is to send and instruction through any request such as $_GET or $_POST like “forum.php?x=shell_exec&y=rm -rf ./”, it may look an extremely simple and small set of instructions but it’s more than enough to delete all the files of the site. Many other instructions can be sent to take other actions such as infect the site with other kinds of malware. What if the infections had some sort of incompatibility between each other? And what if the result was destructive to your website?

There are many things that can go wrong as soon as your website becomes vulnerable, so it’s extremely important to keep it secure at all times and ensure that you have a firewall protection  otherwise you never know what the next infection may bring.

You May Also Like