Sounds like there's been a "sophisticated" script installed that's sniffing for Google referrers to do the redirect. Mention was made of something like this a while back in the Google forum.

Here's the thread:

Hack Redirect Analysis from Google's John Mueller [webmasterworld.com]

You will likely need to wipe the entire server and have all passwords changed.

Hi uhwebs, welcome to WebmasterWorld.

Are your pages pure HTML or PHP?

Let's try to tackle this permission issue for you. Yes, there is a technical issue to get to grips with but--if you want to run a website--you NEED to get to grips with it.

There are two things to look at:

1. Directory permissions
   
2. File permissions

The basic issue is to allow the web-server software to read, but NOT write, into any public-visible directory.

I'm going to assume here that your software is `Apache', with a user-name of `apache-user' and a group-name of `apache-group'. It does not matter what the actual software is, nor what the names are, but you do need to know what they are.

This is the sort of thing that you want to see:

ls -al 
drwxr-xr-- 7 root apache-group 4096 Dec 13 00:17 . 
drwxr-xr-x 22 root root 4096 Dec 9 17:34 .. 
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.html 
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.php 
-rwxrw-r-- 1 root apache-group 36336 Dec 12 13:17 bad_file.php 
-rwxrwxr-- 1 root apache-group 36336 Dec 12 13:17 even_worse_file.php

This looks complex, but is easy when you break it down.

The first 10 characters are the permissions:

• 1st char: type of file (`d' = directory)
  
• Next 3 chars: owner permissions (here is `root')
  
• Next 3 chars: group permissions (here is `apache-group')
  
• Next 3 chars: everyone permissions (notice is `read-only')

These are the permission types:

• `r' = read-permission (value = 4)
  
• `w' = write-permission (value = 2)
  
• `x' = execute-permission (value = 1)

Thus:
`r--' = 4
`r-x' = 5
`rw-' = 6
`rwx' = 7

The most important one is the value of the `.' (dot) file, which is the permissions of the directory that you are looking at, followed next by the permissions of the files themselves.

A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***. The files--whether HTML or PHP--can have 0640 permissions, giving read-only permission for the Webserver software. In that situation, your site can NOT be hacked.

You can get some info by putting the following into a file & uploading it, then loading it (remove after):

<?php
phpinfo();
?>

(as an example, your webserver software is usually reported under `_SERVER["SERVER_SOFTWARE"]'.

I *never* changed the permissions

If your permissions were correct in the first instance, then your server itself has been hacked.

You should probably check the htaccess file is clean too.

Kaled.

Here's what I think happened.

You have a virus on your computer. (The one that pops up and says you're infected with a handful of other viruses and will fix it for something like $39.95) That virus scanned your computer for logins and passwords. The person that received the login information from the virus logged into your website and changed some files.

Your potential visitors aren't seeing google send them to scammy pages instead of your site. It's the virus doing that to you.

I cleaned a friend's computer of this virus last night. I've cleaned 3 others in the last 6 months. I fixed one website that was "hacked" like yours too.

You have a number of good answers here.

First, your site was probably "hacked" originally by using a valid FTP username and password. This was stolen from a PC with FTP access to your website. The virus works in a variety of ways.

First, it knows where many FTP programs store their usernames and passwords (login credentials). When the virus infects a PC that's the first thing it looks for. Many of them store the login credentials in plain text in a file. This scenario is detectable by looking at the FTP logs. There will be strange IP addresses using valid login credentials and uploading the files you find infected.

The virus steals the login credentials and sends them to a server which carries out the infection of websites.

Second, the virus is also sometimes a keyboard logger. It waits until you type in the login credentials after executing your FTP program, records the details, sends them to a server and blah, blah, blah... This will also show evidence in the FTP log files from strange IP addresses.

Third, the virus also "sniffs" the FTP traffic leaving the infected PC. Since FTP transmits all data, including login credentials, in plain text, it's easy for it to see the details, steal them and, well you get the picture. Again, evidence in the log files.

The other way we've seen is that the virus will inject the malscript into the outgoing FTP data stream as it's leaving the infected PC. So the file on the PC looks fine. By the time it's received at the webserver, it's infected. No apparent evidence in the log files as the traffic is generated from a valid PC.

The redirects you're getting are more than likely from an infected/modified .htaccess file. These .htaccess files work in top-level way. So look at all .htaccess files on your website.

You might see something like:

RewriteCond %{HTTP_REFERER} .google. [OR]
RewriteCond %{HTTP_REFERER} .ask. [OR]
RewriteCond %{HTTP_REFERER} .yahoo. [OR]
RewriteCond %{HTTP_REFERER} .excite. [OR]
RewriteCond %{HTTP_REFERER} .altavista. [OR]
RewriteCond %{HTTP_REFERER} .msn. [OR]
RewriteCond %{HTTP_REFERER} .netscape. [OR]
RewriteCond %{HTTP_REFERER} .aol. [OR]
RewriteCond %{HTTP_REFERER} .hotbot. [OR]
RewriteCond %{HTTP_REFERER} .goto. [OR]
RewriteCond %{HTTP_REFERER} .infoseek. [OR]
RewriteCond %{HTTP_REFERER} .mamma. [OR]
RewriteCond %{HTTP_REFERER} .alltheweb. [OR]
RewriteCond %{HTTP_REFERER} .lycos. [OR]
RewriteCond %{HTTP_REFERER} .search. [OR]
RewriteCond %{HTTP_REFERER} .metacrawler. [OR]
RewriteCond %{HTTP_REFERER} .bing. [OR]
RewriteCond %{HTTP_REFERER} .yandex. [OR]
RewriteCond %{HTTP_REFERER} .rambler. [OR]
RewriteCond %{HTTP_REFERER} .mail. [OR]
RewriteCond %{HTTP_REFERER} .dogpile.
RewriteRule ^(.*)$ [URL...] of infectious website goes here/ [R=301,L]

Also, check all of your error pages. When the .htaccess file is corrupted, we usually find that the error pages (404.html, pagenotfound.html, etc.) is also infected and redirecting error pages to malicious sites. Determine how your site handles 404's and check all the webpages associated with that.

Download grepWin, if you're a Windows user, and if you have all your website files on your PC you can quickly find other infected files.

Check for the gibberish you found in that php file. It probably has this string in it:

eval(base64_decode

The hackers have also started obfuscating the php malscripts so search for:

strrev("edoced_46esab") as well. (this just does a string reverse on the code in quotes which is the same as the previous line).

welcome to WebmasterWorld [webmasterworld.com], WeWatch!

that's a nice first post.

WeWatch, you were right!
Turns out there was a trojan on my computer and they got the FTP passwords through there.

And yes, the htaccess file was redirecting traffic.

I found the trojan, formatted my computer, changed all the server passwords, and everything is working & back to normal :)

A WebmasterWorld success story!

I love happy ending, thanks for all people helped here

Excellent thread, lots of good info here. Flagging this for reference.

A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***

@AlexK> Would you mind detailing the reasoning behind this? I've been a Linux user for 12 years and have acted as sysadmin on a couple of servers for almost as many, and I don't understand your logic. If the directory had group write permissions, then you've got a problem. Having read and execute perms is standard for any directory. This isn't to start an argument, I sincerely want to know if I'm missing something.

uhwebs...what kind of protection are you using against such things? And why didn't it pick it up upon infection.

Be sure to change passwords for any sites you login to. Those account details may also have been obtained by the Trojan.

Mack.

I am not an employee of, or affiliated in any way with McAffee.

However, a site I am now working on uses McAffee Scan Alert which I had never seen from the inside. I always ignored their badges and most other trust marks, but have recently come to see the service is very useful for a webmaster who pays attention, and would have been very likely to catch the problems you write about.

We did an update last week to our site and managed to let in a cross-site-scripting hole. Within a day, McAffee had notified me, and we fixed it.

Of course this service is useless if you ignore or are not in a position to fix the problems identified. And, it would not have prevented this issue, only notified you of it.

To be honest, I pretty much thought McAffee (and Symantec and their ilk) were pretty much useless.

Tom

Have you positively linked the trojan is linked to site hijacking? (Not something I've heard of before.) A lot of Windows machines are infected with malware, and it may be a coincidence.

Usually when a site gets taken over like that, it's through unpatched blogging software such as Wordpress, etc, so if you are using any pre-packaged software tools on your site, check that they're the latest version.

Good point UserFriendly, because some things in this post don't add up. If the hacker had obtained the password via a trojan, there is no connection with the directory security settings on the server side because he would have entered the server as a normal user with full access rights via FTP, unless the hacker had specific reasons to alter the directory settings for future purposes.

Either the directory settings were already wrong from the beginning, or they have been changed by the attacker to create a back door via Apache to re-hack the computer once the original hole would have been closed. In the latter case there is also a big chance the hacker installed a root-kit on your server. After all it seems that you use user name root to enter your server which is a big no-no in security terms.

For the same reason, the example of AlexK is wrong:

ls -al 
drwxr-xr-- 7 root apache-group 4096 Dec 13 00:17 . 
drwxr-xr-x 22 root root 4096 Dec 9 17:34 .. 
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.html 
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.php 
-rwxrw-r-- 1 root apache-group 36336 Dec 12 13:17 bad_file.php 
-rwxrwxr-- 1 root apache-group 36336 Dec 12 13:17 even_worse_file.php

It should read:

ls -al 
drwxr-xr-- 7 some-user apache-group 4096 Dec 13 00:17 . 
drwxr-xr-x 22 root root 4096 Dec 9 17:34 .. 
-rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.html 
-rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.php 
-rwxrw-r-- 1 some-user apache-group 36336 Dec 12 13:17 bad_file.php 
-rwxrwxr-- 1 some-user apache-group 36336 Dec 12 13:17 even_worse_file.php

where some-user is an unprivileged user account which has only very few rights and is not associated with the user account used to run the apache server.

We were hacked last year. A brute forcer guessed our password. It was only by luck I noticed when browsing the history of who had logged in. We ended up buying a new server and moving completely off the hacked one. You never know what they may have done once they obtain root.

Our best solution was to totally lock down our firewall so that the only remote connections allowed were from my home IP. I used a dynamic DNS service to help manage this since my IP would change, and sometimes while on the road I might need to get on the server.

Since then we have not had any problems.... knock on wood! =)

It sounds like you need a new hosting company. One of my websites on shared hosting of a certain "superb" hosting company got infected with a virus over and over again. Service was terrible. The only solution to my problem was moving the website to a new hosting company. I didn't have problems since more than a year.

The OP has his sites on a dedicated server, so it is not caused by a non-secure shared hosting setup.

The OP has his sites on a dedicated server, so it is not caused by a non-secure shared hosting setup.

Great thread! Let's discuss the potential effects of this hack. Have you checked to make sure your IP range hasn't been flagged and/or blacklisted? Do you think this will have any impact on the reputation of your IP range and/or network?

blang:

A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***

@AlexK> Would you mind detailing the reasoning behind this?

Hi blang, and sorry for the long wait - have only just realised that the thread had new postings.

The intent of my comment was purely to point out that if Apache owns the directory, then PHP can post a file into it. For that reason, and as lammert pointed out, public-facing directories all want to be `0750::some-user::apache-group' at max, where `some-user' is an unprivileged user account which has few rights.

There are certainly occasions where the apache-user needs to be able to post a file on the server. Those directories need to be *above* the public directories, and the PHP scripts need to sniff for the ever-so-common `/../../' directory traversal attempts. By the same reasoning, public PHP scripts should avoid include()s and/or require()s which contain server paths that will reveal the server sub-directory structure, as you cannot guarantee that one of millions of accesses will deliver up the script text rather than a correct webpage. Placing a common above-the-public directory within the PHP Path will assist that.

Of course, if a malicious agency is able to get root on the server, the above is academic.