In June and July I posted two diaries (http://isc.sans.edu/diary.html?storyid=9085 and http://isc.sans.edu/diary.html?storyid=9103) in which I analyzed one campaign used by the RogueAV guys and various scripts they utilize. Last week Dancho Danchev posted a blog about mass compromises of .NL and .CH sites that are utilized in yet another RogueAV campaign (http://ddanchev.blogspot.com/2010/08/dissecting-scareware-serving-black-hat.html).

This campaign is different from the one I described in two diaries above, judging by the code it is probably a totally different group, although some of the functionality is the same. In the previous campaign attackers infected all PHP files on compromised sites while here they only used one PHP script. So let’s dig into it and see what and how they do it.

The first step in this campaign was to compromised as many web sites as possible – in many cases we were looking at mass compromises where a server hosting hundreds of web sites was compromised. The attackers planted one file (usually called page.php or wp-page.php) on every web site – they didn’t change anything else.

The page.php script does the majority of work. Similarly to the one I described in June, this script actually just asks the main controller what to do when it receives a request. The request sent to the controlled is interesting – it downloads another PHP script from the controller and executes it via an eval() call. This allows the attackers to be able to constantly change how any script behaves.

This master script, in a nutshell, does this:

First it checks if the request to the page.php script contains the “r=” parameter. If it doesn’t (meaning, you accessed the script directly) it displays a 404 error. Clever, so they hide it if you try to access it directly.

Now, if the User Agent shows that the request is coming from a Google, Yahoo or Bing bot, special content is returned (more about this below). If you visit the script directly (no referrer) it again displays a 404 error. Finally, if the referrer is set to Google, Yahoo or Bing (meaning, the user clicked on a search result), the browser is redirected to a third site (and possible fourth) that displays the infamous RogueAV warnings.

Above is the standard modus operandi of the RogueAV guys – you can notice that this is almost exactly the same as the campaign I analyzed back in June, although the scripts are completely different.

The most interesting part happens when a Google, Yahoo or Bing bot visits the web page. Since this visit is actually the bot crawling the content, the script has to return the correct content to poison the search engine (otherwise it would not be related to the search terms the attackers use).

So, in order to return relevant content, the master script does the following:

First it queries Bing by using the same keyword that was used by the crawler. You can see that part of the script below:

You can see above how they nicely create the query and ask for 50 results. These results are parsed by the script and saved.

Now comes the interesting part: they get the main (index.html) page on the compromised web site with the following code line:
$index_html = file_get_contents("http://".GetHostId());

The retrieved index.html file will be used to serve back to the bot. First the attackers remove any JavaScript from the file. After this, they change the title of the web page:
$index_html = preg_replace("~<title[^>]*>(.*?)</title>~is", "<title>".htmlspecialchars(ucwords($keyword))." - $1</title>", $index_html);

This will “expand” the old title with the keywords that they used to poison the search engine. The following pictures show the original HTML document (the real index.html) and the modified one (blacked out the title to protect the compromised web page). Notice how they added the keywords at the beginning of the title tag (and one extra blank line):

Original index.html:

Modified index.html:

Now they retrieve 100 links to other compromised web sites from the controller and insert these links, as well as results retrieved from Bing into the final index.html page. This page is then returned to the bot.

Such content clearly works much better when poisoning search engines than the one I described back in June – yesterday I checked Google and I was able to find thousands of poisoned results pointing to such compromised web sites. While the search engine operators do a lot of work to prevent poisoning like this, it is clear that the bad guys are not resting either and that they are developing new poisoning techniques constantly.

--
Bojan
INFIGO IS