Cleaning up after a WordPress hack

Photo by NeONBRAND on Unsplash

There’s no shame in being hacked. It can (and will) happen to almost everyone, from the smallest web operator to the largest federal government agency specifically devoted to cybersecurity. If the experts can’t keep hackers out, there’s no reason to feel bad if (when) they get to you as well. There’s a tendency among people to assume that their business/information is so small, “no one would bother to steal it.” This overlooks the almost unfathomable ease with which some hackers can break into improperly secured systems.

It’s not the case that your average hacker sits down in front of her laptop at a European cybercafe, cracks her fingers, sips her latte and starts entering passwords at random into your website until it breaks. More likely, it’s something like that hacker sends 10,000 emails claiming to be from WordPress, that a problem has been detected with your site and would you please sign in to correct it? Or they have their computer automatically hit every website it can find and scan it for vulnerabilities that haven’t been patched, or WordPress installs that haven’t been upgraded. By doing so, they can essentially break into your site without having to do anything manually. By virtue of being on the internet, your site is a target.

You can reduce your risk exposure by remaining vigilant, securing your site, and keeping an eye on things (automatically, with a service if you can afford it). This both reduces the chance that a hacker can get in, and is more likely to let you know if one does so that you can fix the problem before it gets too large.

Once you’re aware your site has been hacked, the most important thing to do is make sure that your site is secure going forward. It may seem like battening up the chicken coop after the fox already got in, but remember that you have more chickens (readers) and eggs (your content/sales) to come — just because those foxes got in before doesn’t mean you want to let them in again.

What happened: A client — we’re not going to mention names, because although there’s truly no shame in it, many people don’t subscribe to that notion (even despite the fact that, much like breaking your arm, a site properly hardened after a hack is usually MORE secure than the average non-hacked site) — asked us to look at their site after they noticed a number of broken links appearing in Google Webmaster Tools. Unfortunately, the broken links were for pages that didn’t (and shouldn’t) exist — pharmaceutical names, “available without prescription,” and the like. When we looked at the server, we noticed some telltale signs they’d been hacked — files that allowed remote users access to the server, webpages that were serving up nonsense content, and some other clues.

The easiest type of cleanup comes when you know exactly how the hacker got in. Unfortunately, hackers rarely leave useful notes detailing their every move. In general, we recommend starting anew after a hack, to try to break clean of all possible entry points. That doesn’t mean deleting your site content — it means opening a new hosting account (either at your current host or a different one), changing your database information, resetting all administrator user passwords, reinstalling the WordPress core files (the ones that just make WordPress “work”), taking a good look at your theme and plugins (to make sure they don’t have security concerns, removing those you don’t use and finding secure replacements for those you do as needed), and manually inspecting your content and uploads to remove anything nefarious.

Changing accounts/hosts, administrator login credentials, database information, etc., is all designed to eliminate possible means of entry for the hacker — even if they didn’t get in with knowledge of those things, it’s relatively easy to discover them once they’re already inside, and it allows them to continue to infiltrate your site without setting off suspicions.

Cleaning it up: In this case, the client was already looking to switch hosts, and this incident provided an easy impetus to move. We immediately loaded their information into a different database with new access information, combed through the folder structure to remove files that weren’t supposed to be there (including two or three that allowed full run of the server from anywhere on the web), disabled various remote entry points, and changed their login credentials. Once we got them secured, we then moved them to a new installation on a different host and worked with Google to get things reindexed correctly. They were able to get back to business quickly, and haven’t had to call us back about further hacking problems.