A different angle of attack is to redirect only search engine crawlers to a different site. By doing this, they can make it look like the pages of a website moved to a new domain name. In general, when search engines find redirects like that, they will more or less pass the “value” that a page had on to the new URL — that generally also applies to PageRank. So in a sense, they are trying to steal the value that a webmaster has built up over time.

In this particular case, a “massive amount” of sites were hacked and likely redirected through suomi.co.in.

The webmaster generally doesn’t notice this kind of hack because there’s nothing that would alert him to a problem. Only search engine crawlers would get redirected, normal users (including the webmaster) would see the page normally.

The first symptom that you would see is hard to interpret: URLs from the website are just not indexed anymore. URLs not being indexed is something that could happen because of any number of reasons, so how do we find out more?

One of the first things I like to do in a case like this is to access the site with a search engine crawler’s user agent. This gives you a rough look at how the website reacts to a search engine crawler (although it’s not complete, it’s often pretty close). There are two relatively easy ways to do this:

1. Use an online tool such as Web-Sniffer. It’s pretty easy to use and is somewhat close to an actual crawler.
2. Use FireFox with the User Agent Switcher plugin. If you use this plugin, you’ll have to add the user agent yourself. I usually use the current Googlebot user agent string:
   

   Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

   Note: if you use Firefox for this, make sure that your Firefox installation is up to date and locked down properly in case you run into a site serving malware like this. Sometimes it even makes sense to use a virtual machine for this.

3. (I wish there were a half-”li” ) There’s also “wget”, which is easy for those of you who prefer use console tools. I usually use the above user agent string with wget.

If you access the site using one of these tools, you’ll often be able to spot these redirects (or other issues that a site might be having with regards to being accessed by search engine crawlers). It’s rare that someone uses cloaking by IP address for things like this. In a recent thread in the Webmaster Help forums, “webado” spotted the redirect using Web-Sniffer.

In this particular case, the URL was redirected to http://suomi.co.in/ , from where it was redirected to a page that they wanted to promote with the original site’s “value”. I’ve seen the same kind of redirect going through http://ahtung.co.in/.

The webmaster responded with a note from his hoster in the thread:

Note from my host server (support @ hostgator.com)
I have removed the file “.htaccess” from the directory /home/aceuropa which was causing the redirect. The logs show a massive amount of .htaccess files being edited over the last couple of days. I would highly suggest changing your password to something more secure. Please let us know if you have any further questions or concerns.

(It’s great to see a hoster act so quickly!)

There’s another way to spot this kind of hack with Google Webmaster Tools: When you submit a Sitemap file, Google will show warnings for URLs that redirect. By design, you should be listing the final URL in your Sitemap file, so if the URL is redirecting for our crawlers (as in this case), we’ll show a warning in your account.

It all started with a posting like this:

When I do a google search for [Jonathan Wentworth Associates] the first result is:

Jonathan Wentworth Associates, LTD
Welcome to Jonathan Wentworth Associates, a respected resource for world-class orchestral soloists,
conductors, opera, chamber music, chamber orchestras, ...
www.jwentworth.com/ - 19k - Cached - Similar pages - Note this

The: "Jonathan Wentworth Associates, LTD" is highlighted and is a link to the web site. If you place the mouse over the link, it shows http://www.jwentworth.com. However, if you click the link it immeately attempts to download the trojan. My McAfee immediatly blocked it.

Looking at the page in question, it doesn't appear to be hacked, it doesn't appear to have any kind of scripts injected, etc. However, using LiveHTTPHeaders with Firefox, while doing the same steps (search, click on the top result) you see the following:

GET / HTTP/1.1
Host: www.jwentworth.com
HTTP/1.x 302 Found
Location: http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80...

GET /ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2F HTTP/1.1
Host: 85.255.117.38
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates
HTTP/1.x 302 Found
Location: http://www.jwentworth.com/

Without going through Google, the page is returned right away, just like it should. Search engine crawlers also get it like that. After the step through Google however, the site does a 302 redirect to some IP-Address and then returns to the original site. The average browser won't see that, but if you're quick you might spot it in the status-bar. A search engine crawler or any user who knew the address would get there without a redirect and not notice a thing.

Strange.

That's something that deserves to be looked at more closely. What's on that server? How could I be able to see it?

I had seen something similar a few months back which redirected me to an affiliate site the first time I went to that site through a Google referrer (in my case, the gmail.google.com referrer was enough). It would only trigger once per IP-Address. This looks like a similar hack.

When I was able to download the files, I had a nice collection of:

• an encrypted javascript file that downloaded exploits based on browser and operating system
• an exploit from free-spy-cam.net
• an affiliate sales page for an antivirus software. Oh the irony. "We just infected you, buy our antivirus to get clean." That is, if that software isn't infected with something else.
• an affiliate signup link on that page

A search engine crawler will never see these things. A user, coming in from Google, will get redirected and if the IP address is not known, it will trigger a few exploits based on the system the user has and then display an affiliate ad page. The next time the user comes, the redirect will happen but the normal page will be shown.

Spotting the hack on your site

It would be good to know how you could spot a hack like this on your site. In general, you wouldn't be able to. You can check for this particular hack, but it might not trigger every time ... not to mention that there are likely way too many hacks that you would need to check for.

A simple way to check for it would be to use wget to access the page, and check for strange redirects, eg:

>wget --user-agent Firefox --save-headers --referer "http://www.google.com/search?q=duuude" "http://www.jwentworth.com/"

However, as mentioned, that might not work every time.

The technical details

(skip this part, if you are lost already )

The original spotting of the anomaly was using LiveHTTPHeaders with Firefox, while doing the steps: search, click on the top result. You see the following:

GET / HTTP/1.1
Host: www.jwentworth.com
(...)
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates

HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:04 GMT
Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/
1.2 mod_bwlimited/1.4 PHP/4.4.6 FrontPage/5.0.2.2635.SR1.2 mod_ssl/
2.8.28 OpenSSL/0.9.7a
Location: http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80...
(... added space to prevent linking ...)

GET /ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2F HTTP/1.1
Host: 85.255.117.38
(...)
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates
HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:05 GMT
(...)
Location: http://www.jwentworth.com/

A strange redirect like that is a really bad sign. How can we check the URL that is given to see what they are sending? Apparently it can only be triggered once per IP-address and I had already used that chance earlier. In order to view the initial page, I had to find an IP address that was not yet registered with the remote server (at least that's my explanation). I used a proxy server from one of the lists online. Using the proxy server and wget, I was able to access the page:

>set http_proxy=81.63.140.37:3128

>wget --user-agent "Firefox" --save-headers "http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2Findex%2Ehtml"

Connecting to 81.63.140.37:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
20:43:23 (79.20 KB/s) - `ind.htm@src=324&surl=www.jwentworth.com&sport=80&suri=%
2Findex.html.2' saved [414]

The page that was returned was a normal frameset:

The second frame was kind of funny, "about:blank"? The first one was a bit more interesting though: http://85.255.117.38/site.htm?lng=1&trg=cln&oip=0&trk=zszuyhbinthnpzt
Notice the "trk" parameter.

Accessing that page with Opera within a VMware virtual machine running Windows 2000 (heh, paranoid is good), I was able to access that page. I saved it for analysis (and had Ethereal running on the side just to be sure). I tried to refresh and it returned 404. You could only view the page once.

Looking at the files you see some interesting things:

- an encrypted javascript file
- an exploit from free-spy-cam.net
- an affiliate sales page for the antivirus software
- an affiliate signup link on that page

The ZIP-File contains a full copy of the files as downloaded by the Opera browser. Check the files at your own risk, they contain the full exploit.

The encrypted javascript file looks like this (pulled apart and reformatted; called "__cntr000.htm" in the ZIP file):

The contents of the file are encrypted with some variation of Base64 encoding. You can decode the javascript by replacing:
eval(dd1+"."+dd2)
with
document.write("<xmp>" + r + "</xmp>");

Doing that will display the full contents of the encrypted data (called "__cntr000-decoded.htm" in the ZIP file).

It is yet another javascript that triggers an exploit based on the operating system (it even test for XP service pack 2) and browser that the user is using. The exploit is also tagged with the "trk" parameter and couldn't be downloaded separately. You can bet that's it's not a picture of your favorite celebrity, however.

Next steps

You could follow these up with:

• Checking the whois of the payload-server and notifying the hoster (in this case probable fruitless)
• Checking the sales page, search for the affiliate ID and the setups running and complain to the affiliate networks about this webmaster
• Mirror a copy of the original server for analysis
• Obviously move to a different server, perhaps even a different hoster

Summary

The hacker had managed to patch the server side code (most likely the Apache server) so that
- search engines see the normal page
- new users from search engines are hacked with several exploits and shown an ad for anti-virus software

Spotting something like this on your own sites is close to impossible. The search engine crawlers would not notice anything.

Recognizing something like this algorithmically on Google's side would be possible with the Googlebar-data. Assuming all shown URLs are recorded, they could compare the URL clicked in the search results with the URL finally shown on the user's browser (within the frames). At the same time, the setup could be used to detect almost any kind of cloaking.

Scary stuff.