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:

Sucuri  Sizzle CSS Selector Engine Modified III

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:

Sucuri iefix-sct Behavior II

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.

Sucuri iFrame Loader Malware II

Yes, now we are getting to the payload!

Sucuri Google Shortner Link w Malware II

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

Sucuri Redirect Payload II

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:

Sucuri Malware looking for Java Plugin

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

Sucuri Java Plugin Redirect Code II

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.

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:

Sucuri Google Blacklist Reqeust 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.

Scan your website for free:
About Fioravante Souza

Loves long walks on the beach, while listening to his country music collection on his portable 8trac, and dreaming about the next evolution of web-based malware. He also enjoys a family of 5 girls, rides his motorcyle backwards, and plays cricket.

  • Zack

    Nice Analysis… Can I ask how the malware was injected? Was there an exploit in the site why those behavior parameters where then inserted? The reason im asking is that, potentially we remove the behavior and file, but if there’s an exploit, it will just come back and Google will say you are still blacklisted. Appreciate some further comments.. CHeers

  • http://www.gahe.co/ Gahe

    Maybe those relating to blacklist simple and we can see that everything is under control.

  • jeffatrackaid

    In terms of evolving threats, we have seen an increase in drive-by FTP attacks. The attackers use a compromised FTP account to deliver the payload. The scripts may only be on the server for a short period of time but should Googlebot hit the server during this period, you get blacklisted. We’ve had a couple of cases like this — in most cases the scripts were only on the server for about an hour before they removed. In other cases, they were removed immediately after execution.

  • LUNA

    LA INFORMACION AQUI ENCONTRADA ME SIRVIO MUCHO GRACIAS