Understanding Google’s Blacklist – Cleaning Your Hacked Website and Removing From Blacklist

Today we found an interesting case where Google was blacklisting a client’s site but not sharing the reason why. The fact they were sharing very little info should not be new, but what we found as we dove a little deeper should be. The idea is to provide you webmasters with the required insight to understand what is going on, and how to troubleshoot things when your website is blacklisted.

Get Your Bearing

While investigating the website, we found that some Google shortened URLs were being loaded and redirecting to http://bls.pw/. Two of the goo.gl links were pointing to Wikipedia images, their icon to be specific, and one was redirecting to http://bls.pw/ shortener.

goo.gl/9yBTe - http://bits.wikimedia.org/favicon/wikipedia.ico
goo.gl/hNVXP - http://bits.wikimedia.org/favicon/wikipedia.ico?2x2
goo.gl/24vi1 - http://bls.pw/

A quick search for this last URL took us to /wp-content/themes/Site’sTheme/css/iefix.sct. As malware writers like to do, it was trying to trick us into believing it was good code. In this case, the Sizzle CSS Selector Engine code (Real code here) was the target:

As you can see, it is creating an iFrame with the malicious address, but, before we start to break the malware apart, lets clean it. Understanding the payload is one aspect of the game, but for most of you website administrators, identifying is a by-product of the process, what you really want is to get clean and get clean fast.

Clean The Infection

It’d be too easy if locating the iefix.sct was all that needed to happen. Let’s do a quick search for that filename, iefix.sct. Doing so, we found that it was being called in a cascading style sheet (CSS) – wp-content/themes/Site’sTheme/style.css. That should raise a few eyebrow’s for sure…

In this CSS file the following behavior was added:

How do you clean up though?

Easy, remove the behavior and delete the sct file and you’re off to the races. If you still can’t figure it out, no worries let us know and we’ll be happy to give you a hand.

Understand the Malware

Now, to the fun part!

Recall the bls.pw shortener? Well, it’s loading another iFrame with all the other Google images we saw, plus a new link.

Yes, now we are getting to the payload!

The page it loads is really fine, a nicely encoded JavaScript using hidden div’s to store its encoded strings:

It’s a huge code set, and it tests for the presence of Java plugins, and Adobe Reader, and tries to load some malicious Java code or PDF files, depending on what’s enabled in the victims browser.

Here is what you’d likely see if you don’t have either installed:

You gain a real appreciation for what it’s doing when you decode the JavaScript and you find this little gem:

Unfortunately that’s where the cookie trail stopped for us.. 🙁 The domain was taken offline during the investigation which halted any further forensics.

Remove the Google Blacklist

Finally, we get to the important stuff, removing your website off the blacklist.

This perhaps is the one step that is going to require the most patience. It’s not an instantaneous process. The site has to be submitted to Google to review, and you have to wait to see what the response is. This process normally takes 12 – 24 hours, and there is no speeding this process up.

Google has been kind enough to provide step-by-step instructions. We recommend taking the time to read through it, unless you would prefer us to handle it for you so that you do not have to. This submission process is included in our service offering. Simply see the information we provide for removal services.

When you log into your Google Webmaster account and verify you own the website, you’ll have the ability to click on the Security Issues, and from there you’ll be able to submit for a review:

Once submitted, you wait. You want to make sure you are protecting yourself to avoid reinfections, but other than that it’s a waiting game. Be sure to continue to check back with Google Webmaster Tools for updates, but as long as you can keep the attacker from reinfecting your website you should be good to go.

Evolving Trends

This is a good example of malware that’s not using the common infection vectors, like PHP or JS files, it’s injecting its malicious code inside CSS files and using different extension types to store the trigger. Most of the users look only for eval() or base64_decode() functions in their files, overlooking infections like this.