The Warning Signs
First, I started receiving messages from followers on Twitter about virus alerts on my
site. I try to personally respond to every message I receive, but at that time I had nearly
15,000 Twitter followers and was getting a ton of spam! Most of it is about some video
they found of me on Facebook or how someone is writing terrible things about me. (It
may have worked to trick me to click through if I didn’t have 20 different people all
sending me the exact word-for-word message.) After checking my site and not seeing
anything wrong or getting any virus alerts when I visited it, I assumed these were more
I have thousands of great followers, some of whom have alerted me when there were
problems with my site which I have taken very seriously, but I couldn't find anything
wrong this time.
Finally, someone sent me a screenshot of a warning message from Chrome. I checked
it once again, and bam! There it was in my face. Google had blacklisted me as a
potentially malicious website.
Flailing About Helplessly
Frantically, I searched the code on my site, but I couldn’t find anything wrong. Google
Webmaster Tools will even tell you exactly what code on your website is getting you
blacklisted, but I couldn’t find that code, even when doing a full search of my site.
I immediately changed all of my passwords including FTP, WordPress, and MySQL.
Pinpointing the Problem
After much cursing of Google for telling me what the code was but not where to find it, I
found how hackers often use base64 code to obfuscate what they are doing, and then I
shifted tactics. I had been searching the source code in the browser, falsely assuming
that if Google saw the code then I should be able to see it in the source code. I was
even using the Web Developer tool to view the generated source code, so that I would
Now I decided to search the source files on the server. This was going to be a pain
because I am using WordPress and that pulls in files from all over the place. Thank
God for Linux.
My First Clue
I used Putty to SSH into my server. If you don’t have SSH access to your site and you
are serious about web development, then you need a new web host. From the
command line I used the “grep” command, one of my all time favorite Linux tools, to
quickly and easily search every file in my site. I searched for the PHP command to eval
base64 code, and a lot of things came up that were just white noise that I had to sift
through, but eventually I found something very suspicious.
Inside my index.php file before the doctype was even declared, before the header is
called in, before anything else there was obfuscated code that I didn’t think should be
there. The first mistake I made was quickly deleting the code and saving the file. When
you have been searching all day, and you finally find the problem, your first instinct is to
remove it ASAP. But that code has a lot of information that could prove helpful in
finding anything else, because I guarantee that this is NOT the only thing they did.
Closing the Front Door
One of the first things I did when trying to figure this mess out was to shut off all of the
plugins in my WordPress site, knowing that they could have been how the hacking
occurred. I didn’t see any evidence of that, so I slowly re-activated some of the more
important plugins over the course of a few days.
One item I noted was that all of the unused themes that were installed had their
index.php file hacked. At this point I researched the vulnerability that unused themes
and plugins could cause, and it turned out that is a very real problem. I had several old
themes with old versions of Timthumb installed and these older versions of Timthumb
have a serious security hole in them.
So I deleted all of the themes from the server except the one I am using and I made
sure it was using the newest version of Timthumb. I also deleted any plugins I wasn’t
using and evaluated the security of each plugin by how recently it was updated and if it
is actively being maintained.
I also found several folders in my account that I had carelessly left with insecure
directory permissions which I promptly changed.
Closing the Back Door
Now I made another mistake. Having appeased the Google gods that my site was
clean, and having removed what I thought had given them access to my website in the
first place, I rested. Like most people I don’t have endless amounts of time to spend
hardening my website against hackers. I had already had one full day and several
partial days wasted, and I needed to get back to real work. Even though I knew I hadn’t
likely gotten it all.
Sure enough, within a week I was starting to get the same warnings again. This time I
knew where to look, found the code and removed it. Now I knew I had a deeper
problem, so I delved into error logs and searching for any files that had been changed in
the last few months.
Eventually I found two files buried in the WordPress directories of my site. One I
intended, and the other was the back door.
Since removing those files, my site has been clean now for almost a month (at the time
of this writing).
I hope that in sharing my story it will help others to secure their site or to clean it up in
the unfortunate case that it has been hacked. I also hope to spur some conversation,
because I am sure that there are better ways I could have gone about this. So I
welcome your comments and questions below.
In my next article I will go into the technical details of what I did to clean up my site and
make it more secure for the future.