Every once in a while, someone comes to me with a hacked website needing someone to fix it. A former client of mine for whom we’d built a WordPress site a few years ago was having problems. We hadn’t supported their site in three or four years (they wanted to do it themselves) and we didn’t host their site.

If you looked in Google, you could see that Google had flagged the site as having malware. Not cool:

Google this site may harm your computer

Google’s warning!

If I tried to go to the site, you got this awful red screen warning you away. Their clients were seeing the same screen, and it wasn’t too good for their reputation.

This site contains malware

(click for a larger version)

“Sure no problem, we can take a look.” I quoted them 5-10 hours of work, because you never know what you’re going to find when you get in there.

Why WordPress Is Easy To Hack (Usually)

WordPress is a favorite of hackers because:

  1. It’s so easy to set up with the default settings that aren’t necessarily very secure.
  2. So many websites have the default user id: “admin”. (ALWAYS change this id or delete it!)
  3. The site is often set up and managed by volunteers or company employees who don’t know anything about web security.
  4. There are a ton of targets – I read somewhere that a whopping 57% of all websites in the world are built on WordPress. If one’s too hard to get into, there are plenty others to go after.

The easy setup part means that typically there are some holes left that can be exploited. Older versions of WordPress have vulnerabilities that have been patched in later versions, and if sites haven’t been upgraded, then hackers know how to exploit those problems.

If you have a WordPress site, you can easily tell the version by going to www.yourwebaddress.com/readme.html. Now I know your version, and (if I were a hacker) instantly know what to do to break down the door.

Another problem is insecure passwords. To further compound this, using an admin-level user id to post blog posts means that a hacker now knows your admin account, and just has to guess or brute force your password. Look at your blog posts, and you’ll probably see an author link at the top or bottom. Click it, and now you know the user id under which it was published.

I tell my clients to NEVER use an admin-level user id to post blog posts. Use an editor- or author-level account, and only use an admin-level for admin stuff.

Determining What Got Hacked

So getting back to the hacked site, I did not want to log into the site from the front end, because clearly it had a payload that could install on my computer. It might redirect me to someplace nasty, try to install a virus on my computer, or install malware that captures passwords. So I definitely don’t want to go in the front door, because who knows what kinds of booby traps were set?

I connected to the server with FTP and looked around. I was specifically looking for folders in the /wp-content directory that looked suspicious or weren’t the “regular” stuff like photos, and PDF files. Things like EXE files, ZIP files, or other things that might have a payload. Didn’t find anything there, so that’s good.

So I pulled the entire site down to my computer. If there was anything infected, my Norton would have flagged it and prevented it, but I wanted to be careful.

Next I pulled up phpMyAdmin and logged into the database. I wanted to see if there were any unusual user ids or other entries that didn’t look right. If someone’s user id had been compromised, it’s possible that a hacker could have set up additional user ids. Didn’t see anything out of the ordinary there either, so that was good.

I exported the full database and downloaded the SQL file to my computer.

Finally, I started looking at the individual files, especially the core PHP files. Aha! I found three files that had been changed on the same date and time, that should have had dates matching the rest of the site. In looking at the PHP files, there was code that had been injected which definitely was hacker code. It’s pretty easy to spot when you see it. Fortunately, of the three files, two were core WordPress files, and only one was from the site theme.

Repairing A Hacked Website

So I decided to set up a brand new, fresh install of WordPress, and only move the content over – after removing the hacker code from the one theme file of course. All plug-ins would get a fresh install too just to be sure (because the the database has all the configuration information, that would carry over without a problem).

I started with a blank slate, installed a fresh copy of WordPress, using the latest code (version 4.2.4) and copied just the wp-content/uploads and the one theme folder over (no plug-ins!). I used phpMyAdmin to import the database file, and changed the wp-config.php file to point to the new database. After I installed all the old plug-ins (fresh from wordpress.org), I fired up the website.

Everything seemed to be working.

Next, I installed and configured the iThemes Security Pro plug-in, which is my go-to for WordPress security.

The last step was to go to Google Search Console (formerly Webmaster Tools), and request that they review the website. Check the checkbox at the bottom, and you have to explain what you did to fix it. I doubt anyone physically reads it, but it’s good to document it.

request website review after malware

(click for a larger version)

Within a few hours, they had declared the website free of malware, and by the next day, the red warning screen was gone. Yay.

Putting “Hacker Insurance” in Place

I’m a big believer or prevention is a better policy than after-the fact repair, which can get very expensive very quickly. These are my suggestions to prevent or at least minimize your vulnerabilities:

Use a high quality hosting company – don’t go cheap. You get what you pay for, and cheap isn’t always a good investment. I’m a huge fan of WPEngine, and am actively moving all my WordPress clients over to them. They manage brute force attacks directly, and even disallow unsafe plug-ins. If you move a site over with a disallowed plug-in, they warn you, and within 7 days will remove it if you don’t first. Their tech support is top-notch, and I can’t say enough good about them.

Install anti-hacker software and configure it properly (see my previous article: How to Hacker-Proof a WordPress Website).

Keep a nightly backup of both the database and the WordPress files. WPEngine does this automatically without any additional plug-in. If you need to do an upgrade or install plug-ins, do an ad hoc “Backup Point”, and you can instantly roll anything back that pukes. If someone gets in and does bad things to your website, you can push it back with a click of the mouse. If you don’t use WPEngine, Backup Buddy (also from iThemes) is a good plug-in to use too, and allows you to restore your website pretty easily.

I don’t think you can ever be 100% sure of being hack-proof, but you can certainly make yourself much less of a target. If it’s too hard to get in, they’ll just go somewhere else and beat on someone else’s door. Good luck! It’s a jungle out there.