Everyone who has had their site hacked wants to know how it happened. Unfortunately there are a lot of way to get hacked and no single method for stopping it. I created this plugin because of a vulnerability in timthumb.php that got widely exploited about a year ago. This very useful timthumb script had a weakness in the way it was written that allowed hackers to place any script on your site thereby enabling them to gain access to your files and spread their infection. A newer and stronger timthumb.php was release to stop this abuse and it is fairly simple to update this file to keep your site from being exploited in this way. One of the things my plugin will do is to find old timthumbs and update them.
But, of course, there are other ways for your server to get infected. Many people don't realise that having their site on a hosting account with other site means sharing the vulnerabilities of all the other sites. Having your site on an isolated account, all by itself, can be a great improvement to your security. You will also need to make sure that your site up-to-date and has no vulnerabilities of it's own. Make sure the plugins and themes you have installed are secure and well trusted.
A lot of people think that they need to change there FTP passwords. This is not a bad idea but it's extremely unlikely that the a hacker is using your FTP account. Once a hacker has exploited a security hole in you website, hosting account, or server they will plant a script on your site to gain full access to your files. Then they don't even need your FTP to inject more malicious code and spread their infection further.
Unfortunately it may be very time consuming and costly to figure out exactly how you got hacked, but stay vigilant and take any security measures you can to avoid being an easy target. With every step you take to secure your site you become harder to hack and less of a target.
Aloha,We found some rotten PHP code in some random file throughout the server. Some were new files but some were there before and just had this line added to them. This code uses the eval PHP function to execute the given code. To make it harder to identify what the code does it has be encoded and the additional PHP function base64_decode is needed to decode the gibberish. I didn't even bother to decode this and find out what it does. It was so obvious to my that it was malicious that I added this pattern to my one-click removal script and repaired all the corrupted files at once.
After discovering a lot of index.html files on sites that are all PHP I analyzed the files and found some JavaScript that created an IFRAME to another hacked site. So I adapted my one-click removal script to repair files with this pattern in them.
Well, the hack was back. All our hard work for nothing. I knew we needed an automated repair to clean the infected .htaccess files with one click. So I wrote this quick little PHP script to clean all the infections out for us (see picture above). It was a good start but we obviously still had a vulnerability on our server and needed to figure out where it was.
Some of our domains started coming up as Infected in Google's search results. So we started looking on the server and found that most of the domains on our BlueHost account had a new .htaccess file. Even domains that had not had one at all before had a new one.
Upon inspection we discovered that each of these new .htaccess files had new rules that invoked a 301 redirect to another infected server when a user came to our sites from a search engine, or if there was an error on the page (404, 500, etc.) the user would also be redirected.
One of the tell-tail signs that these line in the .htaccess files were malicious was that they were heavily indented, You might not even see anything when you open the file unless you have line-wrap on or have it open on a high resolution screen in a wide window. You can see in the screenshot above how the code starts far to the right of the screen and wraps many time.
We manually removed th infected lines of code and replaced missing lines in each of these files. Believing that we had fixed it we decided to take a closer look later to figure out how the hack was planted.