Wednesday, August 31, 2011

Fake stores on other search engines

A few weeks ago, I showed that even search engines focused on eliminating spam from their search results fail to remove spam pages leading to fake online stores. I was curious to get a broader pictures of how different search engines deal with this issue. Since the fake stores exist in several languages (English, French, German, etc.), this issue affects web users in many countries.

I decided to check how spam pages for "Buy Windows 7 key" (or its translation) are displayed in the first two pages (20 results) for various search engines. For reference, the numbers for the 3 main search engines in the US are:

Russia
Yandex contains a lot of blackhat spam in general, much more than Google and not just for fake stores. While Google has cleaned up search results for popular queries, especially spam leading to fake AV pages, I have seen no progress on Yandex.

Yandex shows only spam pages leading to fake stores in the first 2 pages

China
A lot of the spam pages are hosted on Chinese websites (for example):
  • hxxp://nimende.com/notcjjff83/2011/08/29/ubuntu-10-04-lts-debut/
  • hxxp://bbs.52pk.com/thread-4913231-1-1.html
  • etc.

Spam pages and fake stores on Baidu

Germany
Yahoo.de and Bing.de show very similar search results. The first result page shows mostly spam pages hosted on German sites, while the second pages contain spam in German languages on US .edu sites.


Yahoo.de gives worse results than the US site
Italy

Italian spam pages on Google.it

France
Voila.fr and Google.fr give priority to web sites located in France. Most of the hijacked sites hosting spam are US University sites, hence they get a lower ranking.

DuckDuckGo

DuckDuckGo is a a one-man search engine that is gaining a lot of attention in the start up community. All results appear on the same page. Out of the first 20 results, 12 are spam pages.

The first 3 results on DuckDuckGo, all spam

As can be seen from the results, blackhat SEO spam is a global problem, not just one affecting the popular US based search engines. In fact, overall, the US seems to be in slightly better shape than some countries
such as Russia, China and Germany that may not yet have suffered the same battle scars in this fight.

-- Julien

Friday, August 26, 2011

Blackhat spam SEO trends in 2011

My last post on Blackhat SEO spam trends was posted in December 2010. Things have changed quite a bit in 2011.

Cleaner results in popular searches

The main target of search engine poisoning used to be popular searches found in the Google Hot Trends list. In several instances, popular searches contained up to 90% malicious links in the first ten pages. Currently, the number is between only one and three total malicious results in the first ten pages.

Still, in July 2011, we identified 60 popular searches which contained at least one malicious spam link. They led to 35 different fake AV domains and three other domains serving different types of malware.

Better protection

One of the big changes in 2011 is that various players appear to be taking action much more quickly in stoping hijacked sites from infecting users. Google has cleaner results and hosting companies are in general, much faster at taking down malicious domains. Antivirus vendors also seem to have better protection for fake AV pages (the fact that these pages are changing very slowly must help).

Webmasters seem to clean up their sites much faster as well. I believe that this is at least in part driven by better education as the threat of hijacked sites is now better known. Google has also helped to make webmasters aware of issues in their websites with warnings in Google Webmaster Tools, new warnings to users in search results and even direct e-mails to the owners of hijacked sites.

As a result, the number of spam pages redirecting to a malicious sites that are either down or have been cleaned up has increased significantly.

New targets

While the most popular searches are cleaner, a broader range of Google searches are now being poisoned. We recently demonstrated how Google News was redirecting users to malicious Java applets and Google Image search was poisoned for 6 months as well.

Searches for buying software online remains 90% malicious, redirecting users to fake stores. There has been no significant improvement on that front, with 60 different fake store domains observed in July 2011. This is a problem that pretty much all search engines are facing.

In total, I've found over 1,000 spam search results leading to 150 different domains, most of them were malicious. This is a conservative number as I did not include malicious sites that were down (but were likely infecting users in the past) and malicious domains which prevented me from accessing their content.

Distribution of malicious domains per category


Fake AV is still there

As you can see in the chart above, Fake AV sites are still present. They continue to look similar, both visually and in their source code. I've spotted 35 different Fake AV domains in July 2011. The usual suspects were there: 10 co.cc sites (xyfybir.co.cc, wydrjim.co.cc, ttvzxiw.co.cc, etc.), 6 co.be (vrtwyqz.co.be, urtty.co.be, etc.), etc.

Fake AV page seen on 08/22/2011

Google has definitely made progress cleaning their search results and hosting companies have been doing their part as well. It has been some time since I have seen a mass Google Web search poisoning like the millions of  "Hot Video" pages that we observed last year. The only exception would be for searches related to malicious online software stores.

I hope Google and other search engines vendors will continue to combat this threat.

-- Julien

Tuesday, August 23, 2011

DNS changes lead to W32/Rorpian

Update:
Upon receiving additional file-system information from an infected host, the malware that resulted in being dropped was a TDSS variant, which corresponds to the earlier statement about Rorpian being used as a loader for TDSS. This was pulled from the MBR of the infected:

Executables:
MD5: 57eaccabfa387d51a29b12fb9f2451f1
V/T Report (29/44)

MD5: 73cfb1489b7949cfb9c76fc9c727fb58
V/T Report (26/44)

DLL:
MD5: 4f6ebfe892b1be6c40ea0895c5c51d21
V/T Report (9/44)
Note: the binary has debugging info enable, including reference to its PDB file:
H:\atrohnwA\gqybua\ybgh\qdyy.pdb
(possible phonetic strings - there are other such strings in the binary as well)

The original infection on this host occurred from exploitation of the LNK vulnerability, in order to execute a Rorpian payload:

MD5: 4e69a47a418b7af08f53effd0e8c61b7
V/T Report (28/44)


Original Post:
We've had reports that some systems have had their DNS resolution settings modified to resolve domains from:

188.229.89.121

The IP belongs to a known "bad" /24 netblock in Romania, part of AS43134 (COMPLIFE-AS CompLife Ltd) ... a netblock that we had perviously noted within Scrapbook.

Which in effect, redirects all web browsing attempts to:

hxxp://188.229.89.121

Which presents a screen showing that you need to "Update your browser":


The image file and malware download viewable from my system linked to a placeholder "update.browser.com":

At least the attacker has a sense of humor :) the meta tag shows "(C) Bank of Nkolai. Look I have a pen !" -- this is in reference to this very funny awareness ad on cyber crime, see YouTube video.

The actual malware is live and downloadable from:

hxxp://188.229.89.121/X

A malware report related to this is viewable here:

MD5: 2dff3265278fb6a894829a75f6275c8a
V/T report: 28/44

The malware variant goes by many names: Rorpian, Buterat, Kolab, and SillyFDC. For ease, we'll just call it Rorpian -- which numerous sources describe it as a worm that spreads through network shares, exploits the .LNK vulnerability (MS10-046), and exploits a vulnerability (MS07-029) in DNS Server service (MS Encyclopedia entry). This worm can act as a loader for the TDSS rootkit (reference).

Further check-ins from the infected are made to the 188.229.89.121 c2 with the format:
/slog
&log=startum
&id=[ID number]
&os=[OS version]
&version=1d
&data=

Note: the User-Agent string used in the check-ins was:
Microsoft-WebDAV-MiniRedir/5.1.2600

There have been Internet reports of Mac and Ubuntu systems having this DNS change occurring within their /etc/resolv.conf ... however, this appears to just be a result of infected Windows systems that are setting DNS setting through DHCP for all devices on the network versus this malware infecting Mac/Ubuntu.

Monday, August 22, 2011

Be aware of Gmail phishing pages

Phishing is certainly not a new attack vector but attackers are constantly using it to fool victims into entering sensitive information like authentication credentials. As I mentioned in a blog post a couple of years back, such attacks will never go away as phishing is a trivially easy attack vector that can be used to steal sensitive personal information. There are number of popular websites being targeted in phishing campaigns to steal sensitive information. Recently, we came across one website claiming to be a Gmail login page. Here is the screenshot of the website:

The above page is largely identical to a legitimate Gmail login page but there are a couple of important differences to be noted. The address of the website is not “www.gmail.com” but rather points to “hxxp://kphb2040.110mb.com/Photosnewmine.htm”. Additionally, the copyright notice is out of date.

If you enter your username and password, the entered data will be sent to a malicious server and you will then be redirected to the legitimate Gmail website. The attacker has done this intentionally so that a victim will assume that the initial login wasn’t successful and they must then re-enter their login credentials.

Even if you enter fake information, you will be redirected to legitimate Gmail site. For testing purposes, we have entered fake account information. The following packet capture illustrates the POST request:

The victim’s email address and password has been sent to “input.php” and they are then redirected to the real “mail.gogle.com” website. There are plenty of such websites are present on the Internet and users should be cautious any time they are entering login credentials. Always check URL address before entering any sensitive information on a webpage. Instead of clicking on links, when possible manually enter the website address in the address bar.

Careful…

Umesh

Bitcoin Mining Malware

For those unfamiliar, Bitcoin is a digital P2P currency (here's a more detailed video explanation if interested) - people interact with it using locally or hosted "wallet" software. It should not come as much of a surprise that malware has been designed to target abuse of this digital currency the same as any other (e.g., WoW Gold). Abuse can come in terms of theft and/or unauthorized Bitcoin mining - that is, solving computationally complex, "proof-of-work" problems ("solving blocks") to obtain a payout (based on an inflation algorithm).
A Bitcoin account can be compromised if a computer with a wallet file can be remotely accessed by hackers or becomes infected by a virus or trojan. The first malware specifically targeting Bitcoin wallets was discovered June 16, 2011. Current Bitcoin clients lack functionality for encrypting the wallet, however, the current development tree contains this feature and it will be available in the next release.[1]
Recently, Symantec released a report on "Trojan.Badminer" - discovered 11 days ago, affecting most Windows systems that has the ability of running one of two Bitcoin mining programs depending on the infected host's configuration: Phoenix Miner (uses the system's GPU on graphics card) or RPC Miner -- the mined Bitcoins are then sent back to a location for the attacker to retrieve the generated currency. When you think about it, this type of revenue generation is perfect for a botnet.

It took me virtually no time at all to find a quick case study of such a malicious Bitcoin miner in our logs from yesterday. Here is a live sample of one that we blocked:

hxxp://img901.fileave.com/x8gp-on-59as.exe
MD5: 8941ECF2586690701F0E748CCC954BB7

Fortunately, it is detected by most A/V programs:
Virustotal Report (26/44)

The corresponding ThreatExpert report shows the malware connecting to 78.47.124.250 (belongs to Hetzner netblock) on port 8332 -- HTTP listener, assuming Botcoin dropzone. Note: I doubt the ThreatExpert sandbox is able to process any of the code that would be designed to mine Bitcoins on the GPU.

Further analysis of this particular sample shows that it makes its calls out to the domain: x.miners.in which does correspond to the previously mentioned IP in the ThreatExpert report. A round-robin has been setup as follows to handle receipt of the Bitcoins:

All of the IPs in the round-robin are to the Hetzner netblock - a great inexpensive hosting provider in Germany (sidenote: I recently tried to setup an account with them, and they required that I fax over a copy of my passport or drivers license for authenticity as part of their policy to prevent abuse - I did not want to share this and thus cancelled my account setup).

Attempts to HTTP GET access the Bitcoin drop site show authentication required (likely for an admin console):
Whereas, infected hosts do HTTP POST requests with the UserAgent strings like:

Ufasoft bitcoin-miner/0.20 (Windows NT XP 5.1.2600 Service Pack 3)
Ufasoft bitcoin-miner/0.20 (Windows NT 7 6.1.7600)

The Ufasoft Bitcoin Miner (site) shows that it supports AMD/ATI, CUDA GPU (graphics card processor utilization)

Obvious fake domain registration information provided to Name.com for registration of the miners.in domain:
(microshits.us is a domain registered and hosted through gandi.net in France, registered to "Dennis Timony" in the US with billing to "Gemblous Kim" in Germany)

Under the same fileave.com profile there are two PE executables with jpeg file extensions, possibly used in the same malware campaign:

yavncc.jpeg
MD5: 291bfc99016ed4647862aeb896f741d1
IRC Malware / injector (VT: 37/43)
C2: 92.243.19.35 port: 1337

yap.jpeg
MD5: a9c88a209db76deb4fe9f1a9f8f47971
Palevo (VT: 27/43)

While IRC-based malware and Palevo are older malware families, it looks as though the attacker is padding their portfolio of malware to include this newer, Bitcoin miner, form of revenue generation from their victims.

Do a Google Search for Bitcoin miner in VirusTotal (Google dork) and you will see an influx of these varieties in late July through present. If VirusTotal is any indicator, this certainly appears to be a growing trend (and convenient revenue stream for botherders).

Wednesday, August 17, 2011

The pastebin trend (cont.)

In June during some of the LulzSec pastes, I published a brief blog post on our sister blog (Scrapbook). In that post, I discussed a spike in Pastebin web transactions due to the LulzSec information drops and other controversial news within the information security community. To get a more precise view of when the spikes occurred, why and the general increase in Pastebin transactions, I wrote a script to automate the process of collecting daily statistics from our web transaction logs to Pastebin. Below are the results.

For Q2 2011 (April 1 - June 30), the a graph of the daily Pastebin usage looks like:

You can see from the trend-line that transactions to Pastebin increase about 200% throughout Q2. This increase has been due in part to some of the recent stories dealing with information being leaked out onto the Internet through Pastebin from LulzSec. However, surprisingly that was not the reason for the largest spike seen thus far - the reason for the significant spike on May 12 occurred due to privacy concerns surrounding Google's social networking site (see below for the link to the Pastebin paste). You can also see the cyclic-nature of the work week, since this traffic is from corporate, enterprise clients (i.e., the 2-day lulls are the weekends). The notable stories corresponding with the spikes seen in the above chart are as follows:
Following Q2, some of the LulzSec activity has settled down, so with the exception of two spikes in July, a slight overall decrease has been seen in recent Pastebin transactions versus Q2. This is what the July 1 to present chart looks like:

There are two prominent spikes during this timeframe:
  • July 1st: Anonymous / Lulz attacks against Arizona law enforcement (link1, link2)
  • July 21st: Anonymous / Lulz statement to FBI and law enforcement (link)
A interesting side note - Pastebin changed it's IP from 173.236.52.197 to 184.154.125.14 on July 2nd - both are SingleHop netblocks (the DNS PTR record for the first IP is to m1221.sgded.com and the second is to s1.jeroenvader.com). The reason for doing this is unclear, perhaps it was an server upgrade.

There were many other Anonymous / Lulz Patebin pastes that occurred in the timeframe of this analysis -- I only listed pastes that were the cause for spikes seen within our customer traffic.

There is no question that the Anonymous / Lulz pastes to Pastebin increase the visits and traffic volume to the site ... driving factors for online revenue. One website revenue analysis site estimates that Pastebin receives about 7.3 million page views a day and has an estimated worth of almost $3 million USD based on this traffic volume. It is certainly interesting to witness this conflict of interest: Pastebin (and yes other web services like Twitter) are being used as popular soap boxes for illegally communicating sensitive / stolen information while at the same time collecting revenue from its related traffic. If Pastebin were to crack down hard on removing this content they would effectively be loosing their biggest cash cow. The Anonymous / Lulz pastes remain live on the Pastebin site -- if interested, here is Pastebin's acceptable use policy. One could argue that with the open avenue of communication that is the web, groups like Anonymous / Lulz would just use a different service or start their own so why bother cracking down, just collect the traffic (revenue) and be happy. Others would argue to do what is "ethically right."

Amusing Craigslist phishing

The best way to double check that the page you are visiting is a legitimate page and not a phishing site, is to verify the domain name in the address bar (obviously, this does not work in case of DNS hijacking). Phishers have used a variety of techniques to make the URL look legitimate, like using http://login:password@url.com with a login name that looks like a legitimate domain.

I was amused when I saw a Craigslist phishing campaign last Friday. The phishing page ironically warns users about fake Craigslist pages. It tells people to always double check the URL before entering their credentials.

Craigslist phishing page claims to educate users on ... phishing sites!

If you didn't notice on the screenshot (click on the image to see it in its original size), the phishing page tells users to check the domain name at the end of the URL instead of the beginning.

Indeed, the phishing page that I spotted used a URL ending with what looks like a legitimate domain name: hxxp://69.175.106.6/~feacosa1/nozit/accounts.craigslist.org/.

The phisher is hiding the phishing page behind two other domains: URL shortener(s) redirect to different pages on free hosting sites which then redirect to the phishing page. It is a "smart" redirection in the sense that real users are redirected to the phishing page whereas URL shorteners are served with a regular page that looks legitimate. Even if the URL shorteners use a blacklist to prevent abuse, they cannot apply it on the real final destination.


Spam page to hide the phishing page from security tools
Here are some of the domains used for the redirection:
  • npzut81.125mb.com
  • fdabbe61.batcave.net
  • pziut318.batcave.net
  • nipxuto11.125mb.com
  • hpasut81.tekcities.com

This brought to my attention the fact that in addition to telling my friends to always check the URL and the domain name, I should also remind them where the domain actually is!

-- Julien

Thursday, August 11, 2011

The Web has still not switched to SSL-only

In November 2010, the release of Firesheep highlighted the dangerous consequences of not using secure HTTPS transactions. Following this, I provided some of the reasons why the web has not switched to SSL-only yet. There have been some improvements since, notably Google+, which works only over HTTPS, and from Twitter.

But those are very small steps. A lot more needs to be done.

SSL by default

One trend involves offering HTTPS as a new option. Facebook and Twitter took this path. Unfortunately, the option is usually disabled by default. Half of the users do not understand what this option does and the other half is not aware of the new feature well hidden in their profile!

HTTPS option under Security settings in Facebook

HTTPS should be enabled by default, perhaps with the option of disabling it for the very few users having problems with it.

Facebook

While Facebook has fixed the 2 bugs I mentioned in the earlier post - SSL: the sites which don't want to protect their users, it is practically impossible to use HTTPS on Facebook. The problem arises from the fact that the use of SSL breaks most of the applications I've tried on the platform. I used to get error messages, now users are warned that they need to switch to HTTP. They have to logout, and login again, to get HTTPS back.

Most Facebook Apps cannot be used with HTTPS
HTTPS cannot be used for popular applications like CityVille from Zynga. I doubt many users will take the hassle to logout/login constantly to switch back to SSL.


Insecure cookies

I've seen HTTPS implemented incorrectly on many sites, including Facebook. The main purpose of HTTPS is to hide the user cookies, so that tools like Firesheep cannot be used to hijack a user session. That means the HTTPS cookie should never be sent over HTTP. There are two ways to achieve this:
  1. Use the secure keyword when sending a cookie with Set-Cookie. This mean the cookie can be sent by the client only over HTTPS
  2. Use a different sub-domain that support HTTPS only (like encrypted.google.com) and restrict the cookie to this sub-domain
Otherwise, when the user connects to the website over HTTP the user session is vulnerable. Unfortunately, Facebook uses the exact same cookie over HTTP and HTTPS, without securing it. If you type "facebook.com" in your address bar, you will send your cookie in clear text, even if you are then redirected to https://www.facebook.com/ and simply visiting a site that uses a Facebook widget, a Like button for example, leaks your user session in plain-text, even if you check the "Secure (HTTPS)" option in your profile. Nowadays, it is a challenge to not visit a website that does not contain any element from Facebook...

My Facebook cookie leaked on a random web site (Like widget)

In the end, it does not really matter whether you use HTTPS or not for Facebook. Your Facebook cookie will be leaked when visiting other websites anyway.

Google

Google did the right thing with Google+. The website works with HTTPS only and there is no way to use HTTP. User cookies cannot be sent in clear text.

You can also use their search engine over HTTPS, unlike Bing, which does not offer a secure alternative.

But Google still has some work to do on the rest of their current web applications. For example, the Google Personal Home Page cannot be accessed over HTTPS (users get redirected to HTTP) and Adsense, the major adverting network, does not support HTTPS, which leads to a Mixed HTTP/HTTPS warning for sites would would like to use SSL.

Mobile

The situation is even worse in the mobile space. Most of the applications used on smartphones and tablets need to contact a web server to function: to retrieve advertising (Admob/Adsense Mobile), to get data from a web service, etc. But there is no way for the user to know whether sensitive information is sent over HTTP or HTTPS. There is no UI element equivalent to the lock shown in browsers and no visibility into the URLs. Researchers have illustrated that mobile developers cannot be trusted to secure communications, as all too often, they send user credentials in plain text.

While some websites have taken a few steps to protect the users, there is still a great deal to do. HTTPS should be enabled by default on all new web sites requiring user authentication. HTTPS should not just be required for login, it should also be required for all requests sent with a cookie.

-- Julien

Saturday, August 6, 2011

Blackhole exploit kit continues it’s dominance

Today, I was investigating a block that had been triggered on a webpage due to detection of the Blackhole exploit kit. We previously posted a blog about the rise in Blackhole exploit kit detections back in February, 2011. That blog post continues to receive comments from readers who have identified similar attacks and I regularly receive email from readers requesting analysis on Blackhole exploit kit samples. The Blackhole exploit kit is often behind the injection of malicious Iframes in legitimate websites.

Interestingly, attackers are not only using heavy obfuscation but they also hide the obfuscated Iframes inside HTML body tags. Here is the source of the infected website page which I analyzed this morning:

The heavily obfuscated code has been injected in the HTML body tag. You need to format the code and do some manual analysis to find the malicious URL. In order to do so, you can follow the trick mentioned in my earlier blog for de-obfuscating the malicious content. The formatted code looks like:

Basically, the above malicious code creates two Iframes pointing to two different malicious websites serving Blackhole exploit kit code. To decode, insert an “alert()” function as described in an earlier blog where it concatenates the various strings. You can then see the malicious URL’s, such as:

The URL syntax “/index.php?tp=” suggests that the links are related to Blackhole exploit kit. Once visited, the malicious websites return heavily obfuscated exploit code which exploits different vulnerabilities and downloads malicious binaries. Here is what the exploit code looks like:

The above code exploits various older vulnerabilities. Due to the obfuscation used in both the Iframe and exploit, overall AV detection remains very poor. Here is the VirusTotal result for the exploit code. This example shows that the Blackhole exploit kit continues to evolve with different tricks and obfuscation techniques.

Definitely Badhole!!!

Umesh

Wednesday, August 3, 2011

Malicious URL’s using DWORD formatted IP addresses

IP stands for Internet Protocol. An IP address is numerical label assigned to each device on the network and every website has a unique IP addresses to identify the site on the Internet. As an IP address is difficult to remember host/domain names are used and translated to an IP address via DNS. What some people don’t realize is that an IP address can be presented in many formats such as host/domain name, dotted decimal IP address or DWORD format. Most of the browsers are accepting only hostnames and decimal dotted IP addresses and rest of them are ignored nowadays.

In our research, we have identified that attackers have started using malicious domains in DWORD format to fool or confuse victims. Here is the example of such malicious URL:

hxxp://1539393606/GoogleSearch.class

If you look at the above URL, you will see an atypical number instead of a domain name or IP address. But careful, it is actually an IP address which has been converted by the attacker into DWORD format. If you visit above URL, your browser will automatically convert this to a plain IP address. Lately, we have been seeing many malicious URL’s using the DWORD format to hide their actual IP address. The number “1539393606” is actually an IP address which points to “91.193.72.70”. If you visit above URL using browser like Firefox, it will display the URL as “http://91.193.72.70/GoogleSearch.class”.

IP to DWORD format

To convert an IP address to DWORD, open your calculator in scientific mode. Let’s take the above IP address, which is “91.193.72.70”. Split the IP address into four octets - 91, 193, 72 and 70.

1) Select decimal mode and type 91 in your calculator.
2) Then click on HEX mode. It will give you hex value 5B for first octet. Write that down and do the same for the other three octets.
3) You will ultimately get “5BC14846” for all 4 octets.
4) The string above is in hex format. Select HEX mode in the calculator and copy paste the hex string.
5) Select decimal mode and you will then get “1539393606” which is the DWORD form of the IP address.
6) Type this DWORD in your browser and you will be taken to address “91.193.72.70”.

Here are some other malicious URL’s we have seen in the wild in DWORD format:

hxxp://1496251283/dhj8v.class

hxxp://3560666344/options.class

Further research shows that these URL’s are exploiting Java vulnerability (CVE-2010-4452) to download malware onto the victim machine.

What’s your DWORD form?

Umesh

Tuesday, August 2, 2011

Blekko illustrates the difficulty in fighting SEO spam

Blekko is the new search engine in the block. It launched in November 2010, raised about $24 million and received a fair bit of press in start-up and tech blogs.

Blekko's promise is to provide high quality search results. They work on a smaller index of around 3 billion pages (~46 billions for Google). Blekko emphasizes the fact that they eliminate spam, malware and content farms from their results. This statement is displayed prominently on their  home page.


Blekko's home page


I've blogged a great deal about how spam SEO infects the most popular searches. This is a real problem on Google. So I was very curious to know how a search engine focused on the quality of its search results and committed to remove spam, would do.

Buying software online, currently account for the majority of SEO spam. Google search results are mostly (up to 90% or more on the first 10 results pages) a list of hijacked sites, usually university websites, redirecting to fake stores. The spam pages shown to the search engine indexer look the same and the fake stores themselves are very similar as well.

After investigating, I'm afraid that our results show Blekko doing no better than Google when it comes to filtering out spam. For example, a search for "Buy Windows 7 key" returns mostly spam:
  • first page:; 7 out of the 10 links are spam redirecting to another domain, including 4 .edu hijacked sites
Spam results on the first page


Still under the radar

Luckily for Blekko users, spammers are not (yet?) interested in them. The spam pages look at the Referer header, among other things, to differentiate between real users and bots (security tools, search engine indexers, etc.). Most of the spam pages redirect users to the malicious sites only if they come from a Google, Bing or Yahoo! search. Users coming from Blekko see the spam page only.


Spam page on Universitiy website

All the search engines are having trouble eliminating spam. Blekko appears to be focused on identifying content farms, which usually contain harmless spam, rather than hijacked sites that lead to malicious domains (fake store, fake Antivirus, etc.)


You can protect yourself against malicious spam SEO with the Zscaler Safe Shopping and Search Engine Security plugins.

-- Julien