Win32/BruteForce.WP analysis by XyliBox

Malware analysis blog Xylibox often has interesting posts which are very relevant to our own work – many of their analyzed samples are exactly what we’re removing from clients’ sites.  We wanted to highlight a post from December in which they analyzed a piece of malware designed to guess the passwords of WordPress (and Joomla) sites: Win32/BruteForce.WP.

Important takeaways:

The hacker does not lack for targets – 36,000 domains with WP or Joomla.  With a large enough botnet he’ll be able to attack all of them.
From what appears to be a brief attack, a dozen compromised sites had very predictable passwords: admin, password, abcd1234, and asdfasdf.
There may be some built-in intelligence to guess passwords based on the name or content of targeted sites, so having a password based on the name of your organization is risky.
Once a site is compromised, the hacker can install backdoors via the plugin/component uploaders built in to WP and Joomla.  This is extremely common.

You can find more details at “Malware With Bruteforce Capabilities” by

The features of this malware emphasize how important it is to have strong passwords and non-standard usernames for site administrator accounts.

By |January 15th, 2014|Commentary|0 Comments

Joomla hack – str_ireplace on JResponse in index.php

This isn’t particularly new, but is still being injected into some compromised Joomla sites.  In the /index.php file and /administrator/index.php file, the last few lines of legitimate code look like this (at least in 1.5.x):

The hacked version changes it to this:

The code basically just alters the output to add spam into the body of the page.  The encoded part (which will vary between hacked versions as it contains a hard-coded URL that the hackers are changing), when decoded, looks like this (I’ve removed the original code comments which were garbled and added my own comments to explain things):

In a nutshell, the code downloads whatever is present at the hard-coded URL, and then inserts it right after the </head> tag in the page that Joomla is preparing to render.  It’s been used to display spam links.This code obviously targets Joomla and is inserted into specific files.  It’s not difficult to clean up, but the greater question is how the hackers inserted it… if you’ve found it in your files and are unsure how to continue, contact us for professional incident response!

By |January 3rd, 2014|Malware Analysis|0 Comments

WordPress OptimizePress hack (file upload vulnerability)

UPDATE: OptimizePress has a response and official fix here.

Thousands of WordPress sites are at risk of being hacked using a newly-discovered vulnerability in the popular OptimizePress theme.  We tried to find an official announcement of this vulnerability, but the search only turned up a PasteBin post from Nov. 23 that has since been removed.  However, the Google cache is still there as of now (included at the end of this post).  It shows the details of the vulnerability, which is very simple – you can exploit it with a browser.  The problem is in this file: wp-content/themes/OptimizePress/lib/admin/media-upload.php .  You can simply browse directly to that file, yielding a page like this:

The hacker simply has to choose a PHP file using the “Upload New Image” section and upload it.  The page then lists it, like this:

Now the PHP file is located at /wp-content/uploads/optpress/images_comingsoon/2013112722-02-57osirt.php .  What makes this even worse is that there’s no index file or .htaccess file at /wp-content/uploads/optpress/images_comingsoon/, so hackers can search for that as part of URLs to find already-exploited sites.  A fix by OptimizePress will have to include adding index files to directories not meant to be browsed.

This is a very simple exploit, and so far we have seen only defacements (commonly “Hacked By Iwan Kaito”) performed with it.  However, it’s likely already being integrated into the scanning tools used by the serious criminals to infect sites with malware and spam.

Here are the relevant log entries from one of the recent cases.  First, the hacker locates the vulnerable page using one of the specifically-crafted Google search terms for it: – – [27/Nov/2013:00:26:55 -0800] “GET /wp-content/uploads/optpress/images_comingsoon/ HTTP/1.1” 200 521 “[…]

Next, a request and a post to it: – – [27/Nov/2013:00:27:37 -0800] “GET /wp-content/themes/OptimizePress/lib/admin/media-upload.php […]

By |November 27th, 2013|Alerts|15 Comments

vBulletin “Hacked By Ne0-h4ck3r” (vBulletin 4.1.x / 5.x.x Upgrade 0day Exploit)

We’ve had a few clients with vBulletin sites suffer defacements during the last two weeks.  The hackers exploit the newly-discovered vulnerability in vBulletin 4.1.x/5.x.x installation files, creating administrator accounts for themselves and adding defacement code and backdoors to vBulletin forums.  A case study demonstrates how this happens.

First is the exploit, and then they’re permitted into the admin control panel: – – [02/Sep/2013:04:52:14 -0500] “GET /forum/install/upgrade.php HTTP/1.1” 200 3236 “-” “Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20100202 Firefox/3.5.8” – – [02/Sep/2013:04:52:15 -0500] “POST /forum/install/upgrade.php HTTP/1.1” 200 202 “-” “Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20100202 Firefox/3.5.8” – – [02/Sep/2013:04:53:45 -0500] “GET /forum/admincp/ HTTP/1.1” 200 544 “http://www.[REDACTED].com/forum/login.php?do=login” “Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0”

They create and edit a plugin: – – [02/Sep/2013:05:00:30 -0500] “GET /forum/admincp/plugin.php?do=edit&pluginid=415 HTTP/1.1” 200 11543 “http://www.[REDACTED].com/forum/admincp/plugin.php?do=modify&sort=hook” “Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0”

This plugin was hooked at global_setup_complete, and contained this PHP code:

A pretty simple backdoor.  Later they (or perhaps a different attacker) created two other backdoors, one involving a Perl shell and the other with this code:

This would cause requests to subscriptions.php to yield the C99 shell.

With backdoors in place, they set about defacing the site.  This was done by altering the FORUMHOME setting in the template, replacing it with the “Hacked By Ne0-h4ck3r” page.  In this case it was simple enough to restore the default template, although we had to disable the plugin system so we could log in and flush the cache to clear out the defacement entirely.

For vulnerable vBulletin sites, this exploit can be prevented by deleting the /install directory (something which is recommended anyway).  If you find yourself suffering from this or a similar hack, please feel free to request help.

By |September 11th, 2013|Malware Analysis|0 Comments

vBulletin infected with iframes from [malware analysis]

There’s a new hack in which users clicking on Google results for vBulletin forums are served iframes pointing to various infected domains.  The contents of the iframes come from the host  This behavior causes the vBulletin forum to be added to Google’s malware blacklist.  Here’s an example of one we worked on today.

We found the malicious code in a plugin named “Forum Runner: Check” with a hook location of “global_start.”  This was the code:

It’s pretty simple; it just fetches code from and adds it to the output buffer for the vBulletin pages.  The code in this case was a hidden iframe pointing to another site (interestingly, running on port 38 or 36).  Example:

<iframe src=”************” height=”0″ width=”0″>

We’re not sure yet if there’s a common attack vector used in this type of infection, but investigation is still ongoing.  If your vBulletin site has this problem, contact us for help solving it.

By |July 5th, 2013|Malware Analysis|0 Comments

Plesk Apache Zeroday Remote Exploit

Plesk users should be aware of a remote exploit for Plesk announced today on the Full Disclosure mailing list.  The exploit allows the attacker to execute PHP directly.  It will run as the “apache” user and execute whatever PHP code the attacker passes in the HTTP request.  Here are some potential effects at a glance:

Attackers can use PHP directly to leverage the power and bandwidth of the exploited server in attacks against other hosts or sending out spam.
Attackers can read site configuration files and harvest database info, then connect to the database and harvest or manipulate any data therein.
If the server isn’t kept up to date, attackers could perform a local privilege escalation exploit such as the recent perf_swevent_init exploit and gain root access.
On most servers, the site files are owned by the user account corresponding to each site, so they would be safe from modification/infection through this exploit.  But in many cases, new files could be created to maintain user-level access to each site even after the server is patched.

Plesk generally doesn’t take long to issue updates; I’m not sure if they’ve addressed this issue yet or not.  But this could be trouble for websites hosted on Plesk servers if the administrators aren’t quick with the patch.

By |June 5th, 2013|Alerts|0 Comments

Joomla defines.php infected with spam code [malware analysis]

We found some interesting Joomla malware this week, where Joomla’s /includes/defines.php file had this code appended to it:

The first line defines a variable “DZR” as “C:/inetpub/wwwroot/[REDACTED]/modules/mod_banners/tmpl/helper.php”.  This was on a Windows server running multiple Joomla sites, and DZR, pointed to a file helper.php within a different site.  Several other sites on the server also had their defines.php infected with code pointing to this same helper.php.

The rest of the code basically runs helper.php and looks for a variable call “RSLT” (result) to append just before the closing “</body>” tag of pages on the infected site.  So what does helper.php do?

We deobfuscated the code enough to find out.  It contains some basic backdoor code, but its main function is to check a bunch of variables and then display links obtained from one of the following Russian link-building networks:


It keeps track of what has been displayed via several log files, and it will contact external servers to obtain fresh links.  It assembles code around the links (sometimes hidden with Javascript setting the display property to “none”) and  returns it to Joomla via the RSLT variable.  It stores the log files in a temporary directory on the server, in this case “C:/tmp/tmp_server”.  The files would have these names:

sess_(l|s|t|x|p)(32 hex characters)


The links seem to be pretty standard spam – online pharmacies, online casinos, payday loans, etc.  Though the link networks are Russian, the spam can be in English or potentially any language.  The purpose of the links is to fraudulently build up their targets in search engine results by having a variety of sites link to them.

If you think your site is infected with this or any malicious code, you can always contact us and get help taking care of […]

By |May 21st, 2013|Malware Analysis|1 Comment

Media site mass hack [malware analysis]

Researchers at Zscaler published an article Monday with details of a widespread hack putting malicious code on several popular media websites.  We had the opportunity to work on a site affected by this hack, and it was an interesting one to track down and study.


By |May 9th, 2013|Malware Analysis|0 Comments

"Explo(it|r)ing the WordPress Extension Repos"

Ben at Spare Clock Cycles did a cool project in which he swept the WordPress plugin repositories for vulnerable code, finding dozens of exploitable plugins.  I can attest to this bit, specifically regarding vulnerable versions of the TimThumb script:
Finally, I searched for Uploadify usage and outdated timthumb.php libraries. This turned up another 24 vulnerable plugins […]
I’m pretty confident that he’s not the first one to do this, based on my experience with clients’ hacked WordPress sites.  The vulnerable script was present in all kinds of plugins and themes, some widely used and some hardly at all.

His conclusion is a harsh truth for website owners:
As for what site admins can do, it’s pretty clear: don’t install plugins or themes unless you *absolutely* need to or you are willing to and have the expertise to audit what you’re installing.
We can’t expect very many people to do that, but it’s advice worth taking for people who have a lot of money riding on WordPress-based sites.

By |September 18th, 2011|News|0 Comments

timthumb.php WordPress theme file critical vulnerability

Mark Maunder reports:
An image resizing utility called timthumb.php is widely used by many WordPress themes. Google shows over 39 million results for the script name. If your WordPress theme is bundled with an unmodified timthumb.php as many commercial and free themes are, then you should immediately either remove it or edit it and set the $allowedSites array to be empty. The utility only does a partial match on hostnames allowing hackers to upload and execute arbitrary PHP code in your timthumb cache directory.
Full story here.  If you run WordPress, take his advice and check for the file within your theme directories.  We’re adding it to the list of possible attack vectors we look for during our incident response.

UPDATE:  The file has been patched on its Google Code page.  Get the updated version for your site (or if your theme creator is on top of things, make sure you update your theme immediately).

By |August 1st, 2011|Alerts|0 Comments