Website Malware Removal – Blackhole Exploit

Here is a quick little write up on how to to deal with one, of many variations, of the Blackhole Exploit.

The Infection


If you scan your site using Sucuri SiteCheck and find yourself with a result that looks like this:

Then you are dealing with an infection that is facilitated through the use of the Blackhole Exploit kit, the infection is classified as a Drive-by-Download type infection.

As the type implies, when someone visits a site with this payload, the infection will be initiated on visit and if the conditions are correct it will attempt to download something on your local environment. Hence the classification.

Another option you have, if you feel the site is functioning funny, is to leverage your terminal environment. On UNIX/LINUX based machines you have the option to use CURL as follows:

$ curl -D googlebot www.infectedsite.com

In this instance you’d see this:

Same infection as what was presented in the SiteCheck results.

The Removal Process


In this specific instance the infection was found across all the following files:

  • index.php

This includes the root, theme directory, plugins directory, admin and includes directories. Every one of those directories had an index file and each file was infected, I mention that to show the scope of the infection.

Hunt The Infection

If you have terminal access to the environment you can quickly identify every file infected by running the following:

$ grep -r ‘72.81.840.918.256’ .

If you’re in a rush and your site is very deep, you could also push the results of the grep to a log file versus waiting for it to display and check back later:

$ grep -r ‘72.81.840.918.256’ . > infectedsite-infection

This will create the infectedsite-infection file in the directory you are in. Once you have time you can come back and analyze the output:

$ cat infectedsite-infection

If you don’t have terminal, don’t sweat it, you can often download the entire install to your local environment and run it there too. When you’re satisfied you have found all the offending files simply push it back to your server.

Now Clean it Up

When you’re cleaning, you don’t have to be a coding rockstar, but you want to be aware of the little things. By little things I mean this:

  • If in a PHP file you’re going to need an opening tag, usually looks like this: ‹?php that will then be followed by a closing tag that looks like this ?›

In this instance, this was the most important to keep in mind.

As for the removal, when you look at the results in SiteCheck or your Curl results you see everything fits inside ‹script› and ‹/script›.

There are a few ways to automate the removal, but that won’t be covered here. The easiest way for you is to open the files from the steps above, find the infection, highlight, and delete.

Verify you don’t pick up any of the important characters I mentioned above.

Opening you have a few different options, you can use terminal editors or a local FTP editor (e.g., Codad, notepad, textpad, etc.. ). If you don’t want to mess with any of that, well then good news, simply sign up with us and we’ll take care of it for you.


Any questions or concerns with the post just let us know at info@sucuri.net.

6 comments
  1. There is a UNIX-based tool which does all of this automaticly for you, see: sourceforge.net/projects/smscanner/

  2. I’ve cleaned this off two websites this week, one a WordPress site and one a 7-year-old custom PHP site. In both cases the malware snippets were appended to numerous files within the site, including index.php files, as well as .htaccess and PHP/HTML/TPL files that contained the words “header” or “footer” in the filename. Very sneaky as clearly they want every pageload on the site to deliver their payload.

    Cleaning the infection is relatively simple, and Securi now proclaims my sites as safe. But what I’m having a harder time finding is information on how to *prevent* this sort of compromise in the first place. I’ve changed my FTP passwords, chmodded many of the affected files and folders to read only 444, and upgraded WP and all plugins to the newest versions. I’m on PHP 5 and don’t use any obvious idiocy like register_globals. But is that enough? I’m on shared hosting, is it possible the compromise is happening at the server level?

    How does one prevent this garbage from happening in the first place? Recommendations are always vague in this regard. I don’t want to spend the rest of my life cleaning Blackhole exploits from my websites.

  3. As the website administrator for several sites that have had the Blackhole Exploit Kit I have only been able to upload fresh code from a known good source to fix the problem. Most of the time I see that the files affected are the minified javascript files (respond.min.js and others) but not always. I have seen this as the result of using html5shiv.js and html5printshiv.js as well. My hosting provider does not seem to have any real answers (GoDaddy) here but points to using their date/time stamps on ftp uploads and noticing the IP addresses associated with them as a means of isolating where the exploits are coming from. What am I going to do with that information? Travel to that country and beat up the person who uploaded that code? How in the heck would anyone but me be able to upload any code via ftp to my hosting package anyway, unless they know the credentials. I recently changed all of the ftp account passwords on my business and personal ftp accounts and the infection STILL HAPPENS! The only other way I can imagine this happening is through some back door method other than ftp. I have perused the internet looking for discussions, instructions, etc. for WEB DEVELOPERS to use in fixing this permanently but have found none. This is where the real problem is, not the client. If anyone knows of a blog, user group or otherwise that speaks to this malicious problem and how to solve it, please let me know. I have clients that get hopping mad at me for this and I don’t seem to have any control over it.

Comments are closed.

You May Also Like