I am a part time moderator/web administrator on our unofficial college website. Last year our website had been hacked and some malicious script had been placed on it which was causing redirection of some Google referred traffic. It would not resend all Google referred traffic though, it even placed its own cookie in the malicious script to ensure that people are not sent to the offending site every time but only once every 86400 seconds.
For days I searched the internet desperately to find out if it was a known thing, most sites suggested it was a .htaccess attack, but I had already suspected that and our .htaccess file was squeaky clean. Just to be sure I also checked all the .htaccess files above and below out root level and they were clean. So I was sure it was a script. If your site is hacked via the .htaccess method, there would be entries like :
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://newaddress [R,L]
After the .htaccess files were found clean, I tried some workarounds to prevent the redirection, like setting server referrer variable to null and trying to make all URLs 301 redirects but that didn’t work since the script was still able to detect the referrer as Google and redirect the website to tinyurl4.info which probably paid them a lot to get this done. It would be sent to random addresses on the tinyurl4.info site. Since the site may be hosting malware, I would request you not to go there. So this method of cloaking the referrer at my side clearly wasn’t working.
Next I created a zip file from the offending folder of the site and downloaded the whole thing using my 3G connection photon+ connection (wanted to finish it off ASAP). Once the folder was downloaded, I ran a McAfee scan of the whole thing hoping that the anti virus would be able to detect the offending code as it would be obfuscated. But I was wrong McAfee was terribly incompetent. So it was plan B , I started searching for strings like .js and tinyurl4.info to try and find the redirecting code. Windows search wasn’t very helpful here and couldn’t even find base64 which was one of the strings I searched for and was a part of the offending code.
So now it was plan C , this one worked. I listed all files in the site which had been modified within the past one year. Here is where I was able to find the culprit. One PHP file global_lang.php had been edited in 2009 while all its peers were not listed. I grew suspicious and opened the file. To my shock, horror and relief I found the following piece of code :
which when translated turned out to be malicious code. I am not displaying the malicious code here should you get any ideas. What it was doing was checking if the person was referred by Google, Yahoo etc. and if that was true and there existed no cookie it would redirect that person after setting a cookie. The cookie ensured that once a person was redirected to the fake site, he wouldn’t be redirected for some time.
I have listed these steps here so that webmasters might be able to get a hint of how to recover from this particular type of injection on their sites. Ofcourse, always take backups, backups ensure you can just dump them on and the malicious code is removed.
Future Proofing
There is probably no way to protect yourself from the super hackers , however you can always take precautions. First and foremost, always take backups and multiple backups. you should ideally have 12 backups from the past 12 months.
Apart from backups, ensure that the permissions on your website are always set correctly. 777 is really the devil .Never grant write permissions to outside users. 755 for folders and 644 for .php files usually works. Incase you suspect hacking, contact your host at the earliest.
Also turn off all directory listing.
Hoping you found this article helpful 
.
