How it all started

These posts, from bottom to top, outline the events that lead to the creation of this plugin.

Now available in the WordPress Repository

Posted by on March 26, 2012 at 6:51 pm

I just released my new Anti-Malware plugin for WordPress. It is still in BETA but I think it will be very helpful in removing malicious scripts and patching security vulnerabilities.

Please feel free to leave feedback and donations are always appreciated.

A WordPress plugin is born

Posted by on February 16, 2012 at 6:34 pm

I made my PHP scripts into a WordPress plugin and installed it on a couple of different servers to test it. Over the next few weeks I will be testing, refining, and improving the plugin to get it ready for release to the WordPress community. Anyone interested in testing it on their WordPress site should contact me and I will set you up with a pre-release version.

Zero Day Vulnerability in timthumb.php is the main problem

Posted by on February 15, 2012 at 5:38 pm

 

I was able to find and trace one of the hacks back to thumb.php file. This turned out to be an old version (1.08, 1.14, etc.) of the popular TimThumb script. It turned out there were a lot of old TimThumb script on the server. Many were found in plugins and others were in themes.

I wrote a script to identify old TimThumb files and upgrade them automatically. Now it looks like we finally have a secure server again.

Automated backup recovery script added to the cron jobs

Posted by on February 13, 2012 at 3:20 pm

We figured out that the .htaccess files were getting hacked about every 71 minutes, with a few random exceptions. We could not keep running my automated script every hour so I made a bash script from the command line and set up a cron job to run the script once every minute. If it found any differences between the .htaccess file and the .htaccess.bak file then it would overwrite the changes immediately, and send us an email.

Discovered PHP files with some nasty “eval” code in them

Posted by on February 11, 2012 at 4:43 pm

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.

Found infected index.html files all over the place

Posted by on February 10, 2012 at 10:20 am

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.

.htaccess hacked again! It’s time for a counter attack.

Posted by on February 9, 2012 at 8:01 am

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.

 

We found hacked .htacces files in the root of every site on our shared host!

Posted by on February 8, 2012 at 10:20 pm

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.