Sounds like another round of WordPress blog hackings are making the rounds. I had my two WordPress blogs hacked by script 4 or 5 years ago. Here are some things to think about and consider if you own and/or maintain a WordPress blog.

Security setup and maintenance is a many-layered process. Traditional approaches to securing any computer asset layer many factors into a hardened whole. Keep this in mind as you read on.

Assuming you’re hosting a WordPress blog, there are some assumptions and guidelines that can help frame your thinking and planning. Hosting a WordPress blog gives hackers a generally easy-to-hack site (there are lots of hacking scripts and packages out there for WordPress). Also, WordPress blogs can be high-value (blogs are valuable to unscrupulous Search Engine Optimization shills) targets for hackers.

Still, there are good reasons to run WordPress. It’s accessible, standard, and there are many good extensions and integrated products to it. If you set it up securely enough, you can survive getting hacked and you can fend off most casual hackers and get a lot out of it. Also, authors and editors generally don’t need to know how to code in PHP or to hand-markup content in HTML to get the job done, which makes it very valuable to people who are not, by nature and upbringing, geeks like me. I wouldn’t blame you if you decided to go with WordPress. Despite hacking risk it’s a good choice of framework for a lot of web sites. But keep these security assumptions in mind as you consider it:

1. Assume you do not have unlimited geek resources. Maybe you have good geek friends who give good advice but you’re on your own when it comes to actually installing and configuring the blog. Or maybe you have a good geek friend who’ll help set you up the first time but doesn’t stick around to teach you how to maintain the site in good health. Or maybe you have a hired or volunteer geek but again, they didn’t train you for the eventuality when they’re gone, and they’re gone. Lots of things can happen, which is why I recommend keeping your blog as simple as possible, and making sure at least one non-geek in your organization understands how to keep things updated, backed up, and relatively secure. While you’re at it, also try to learn the suggested process to recover from a hack and maybe get an emergency number if all else fails.
2. The hacker community shares. Every time a hacker finds a way into (in hacker parlance, an “exploit”) an application like WordPress or an extension written for WordPress, it eventually makes its way into automated scripts that anyone can download and run against any site. And these exploits take almost zero time to run. They’re almost like automated tests. Once they’re in an exploit kit, they’ll get tried over and over by each successive hacker. So it doesn’t matter how old an exploit is. It’ll just be checked over and over.
3. In contrast, security consultants and designers and volunteers write hardening instructions for sites and applications. For example things like the “Hardening WordPress” article on the WordPress Codex. Along with regular updates, these are meant to address the known exploits out in the market. This is why following these guides and applying updates is so vital to the security of your site.
4. Part of security risk management is reducing the “attack surface” so if you can, you make every low-hanging fruit, every easy target, less easy. If it’s less easy to find, or less easy to guess, or less easy to infer, it’s less easy to hack. A lot of die hard security folks will dismiss this as “security through obscurity” but in the security layering game, every layer that’s made harder is less risk for you.
5. Assume your site will eventually be hacked. Backups are a good way to mitigate this eventuality. If you can, you’ll want to identify how to tell a backup is “good” or not hacked, especially after you get hacked. But any backup is better than no backup. It’s even better if you can backup via an export or something that will filter out some of problematic aspects of the content that might get hacked or compromised.
6. For the risk that a standard platform like WordPress presents by being standard and being a popular hacking target, it’s not all bad. It’s easy to replace the standard platform in the case that it actually gets hacked. (Just stand up a new copy of WordPress and import a recent export. You may still need to scrub some unpleasantness out if your last export was after the hack.) If you have a simple, uncustomized WordPress then just install and a clean content backup, one solution to a hacking could be to wipe the site, reinstall WordPress and import that content from that recent export. All you really need to keep in mind is your overall configuration, what extensions you had installed and how they were configured, and the theme you picked out.
7. The more customized the site you have, the harder it is to implement the wipe/reinstall/import a backup/proceed method of recovery. More customized means the site and configuration are more fiddly and harder to recover or restore depending on available geek resources. Given this I recommend running a WordPress site with as few customizations and add-ons as you can get away with. The more your site does with the core functions of WordPress, the better.
8. If you can’t find what you’re looking for in standard functions of the standard WordPress install, and you plan to use extensions to close the gap, try to pick extensions that are popular, recently updated, and written and maintained by bigger, professional companies. If you go with a smaller, one-person-shop or pay someone to write custom extensions or to customize your site, you’re likely chained to that shop or person unless you can hire someone to maintain it after they’re gone. This can be, as you might imagine, an expensive and difficult process. So if you do go for customized, watch out for the stinger when/if your customer quits. The reason updates are important is that over time it’s more and more likely that older, unupdated applications and extensions will get hacked.
9. If your site does higher risk and more delicious activities from a hacking perspective, for example selling stuff and collecting payments, storing health information and other types of identifying information, outsource that function! Find a reputable vendor with a respected security infrastructure and integrate their service into your site, like Paypal or another large payment processor or similar services for other kinds of identifying information or comment systems, or whatever you need to add on.

So. Assume you got hacked. You should start with doing all you can to scrub the content free of whatever happened to it when the site was in the hacker’s hands. This may require you to shut down the blog, hide it behind a maintenance page, or lock down the logins. Whatever it takes to stabilize the site, the content, and give you enough time to carefully look over your site and find all the content you didn’t write, all the code you didn’t install, all the media you didn’t intend.

Next, you should figure out a way to install a known-clean version of WordPress that’s the same version your hacked version was and compare the install files between the site that got hacked and the new install. This helps find any hacker-inserted code in the application files themselves. You’ll want to be sure that your known-clean version is the same version number as the site you had that got hacked. There are utilities like WinMerge and DiffMerge that allow comparing whole directories and every file in there. You may want to do this step with a PHP-literate geek of some sort. All the code can make normal folks’ eyes cross. If you find significant differences between the clean install and your hacked install, you’ll know someone customized your site, but unless you’re sure you didn’t do it or some volunteer in your organization didn’t do it, you won’t know who to blame or credit. A PHP-literate geek may be able to help you figure out whether the differences are malicious or just changes you didn’t know about.

Assuming your WordPress Application files were hacked (above), you’ll next want to figure out whether you want to preserve any customizations and transfer to the new install or try to edit out the hacked bits of code instead. It’s your choice, but I’d recommend a PHP-literate geek do whatever it is. The work’s fiddly and it’s hard to troubleshoot if something gets missed or goes wrong.

The other part of the recovery is the data itself.

Some hackers get enough control of your site that they can change the content you created on your site, not just the WordPress application that grooms and presents that data according to whatever theme and extensions you’re using. Typically this data lives in a database that WordPress sets up when you install it. The database is protected with a username and password, but depending on how deep the hackers sink their claws into your application, it’s possible they could get in there too and change things.

Usually, at most, what you’ll see here is changes to media (pictures, video, audio), posts, and pages. Normally this wouldn’t be terrible, but it’s possible the hacker could insert malicious and invisible script in your content that will affect your users. It’s a good idea to have a look, if you can, at every post and page, just to be sure. Again, you may want to have a friendly geek help look. This geek should know HTML and various HTML scripting languages. You should also get this geek and your PHP literate geek to look at the theme you’re using and give it a once over for anything problematic there too.

After everything’s scrubbed clean, you’ll probably be okay, but do take the time to harden your WordPress, and do make sure you’ve got a good backup strategy, and do make sure to update it regularly. Finally, keep an eye out for anything suspicious. One of the challenges in dealing with hackings is that the hackers are always coming up with new things, so it’s not entirely predictable what they’ll do or how they’ll affect your site.

Do the best you can. You’ll get back on your feet.