Repairing a HACKED WordPress site

Did your site get hacked?

• Are you crying? Did you lose money?
• Are things broken or spam and junk links placed all over your site?
• Are you stressed as hell and want to pull out your hair?
• Do you not know where to begin?

Don’t worry, I’ll show you how to carefully put everything back together (hopefully) without losing any data AND to secure your site so it doesn’t happen again.

NOTES:

• Some steps can only be done if you have access to the server.
• If you don’t have access to the server, then you have to ask your webhost to do it or you skip the step.
• If all fails…please oh please just hire a developer that knows what they’re doing.
• A typical repair job can be $200, or free if you have a hack-guarantee with your webhost or security service/plugin.

STEP #1 – take down the site

You can just flat out take down the site. Rename the website directory. Or put a maintenance message. All up to you. If your site’s been botting others, your host might have already taken down your site.

It’s much more professional this way so your brand doesn’t look bad. Some of you might argue that you’re “losing sales”…but I’ll tell ya, if clients see your site is hacked they are not gonna trust giving you their money & credit-card info (even after you repair it).

STEP #2 – check critical website files

Usually for a developer, this part is obvious as hell. You look into your website directory and already know which files shouldn’t be there. (Because you know which files belong and which ones don’t.)

But for everyone else…follow these steps:

• check .htaccess
• check wp-config.php
• check index.php

Delete any weird crap (hack code) you see in there.

The easiest hack code to see are right at the top and bottom of the code. The hardest ones are sometimes in the middle of the file. (Yes, it’s a total PITA when you have hack code buried deep inside a long file.)

• Sometimes looks like a request to a domain you never seen before.
• Sometimes encrypted/obfuscated and looks like /r0X/b4a/1xz9/ (but like 800 times longer).
• Other examples of bad code – Wordfence

And if you don’t know what should be there or not, just compare it to your backups. (And if you don’t have a backup, you should just look at yourself in the mirror and shake a finger. *BAD DEV! BAD!*)

You should also take note of calls to non-WordPress files.

These are hard to spot if you’re not a dev. For example…let’s look into the index.php:

• Here we typically see something like require DIR . '/wp-blog-header.php';
• But if you also beneath it require DIR . '/wp-blogheader.php'; – then you know you should go check that file and see what other crap it leads to. (And then delete all of them.) Yes…it’s like sniffing out a f**king rat nest of hacked files.

STEP #3 – check theme files

The next obvious place to look for hacks are in your theme. Go to your theme directory and check the usual places:

• index.php
• functions.php
• header.php (or whatever the header template part files are called)
• page template files (pages, posts, CPT, etc)

If you see weird things in weird places, get rid of them. Don’t know what’s weird? Compare with your backup!

STEP #4 – check site address in database

Reset your site url (if it’s been changed).

• If your site’s been redirecting users elsewhere, go to database (using phpMyAdmin) and look into the wp_options table (the “wp” might be another prefix).
• Then look for the siteurl and home rows and change it back to your domain if they were changed to something else.
• You may also want to check wp-config to see if there was a hard-coded site url call in there.

STEP #5 – remove unauthorized users

By now, you should have repaired enough that you can log back into your site again. Time to delete any accounts the hacker might have made.

• Go to your webhosting and delete any email. or FTP accounts you don’t recognize.
• Check for new “admin” users in WordPress and delete the ones that shouldn’t be there.
• Another common tactic hackers use is to promote a regular user/customer account to “admin” and maybe even change their email/password.

If your own admin account password was changed (and you can’t get in), you can get WordPress admin access through database.

STEP #6 – scanning for bad files

Let’s run a malware scanner to save time and also catch things you may have missed.

• Log in and install Wordfence (free option is fine) and then run the malware scanner.
• It’ll find all the bad and potentially bad files for you.
• Some recommendations are easy to fix. Others require you to manually scan and decide whether they are hacks or not.

What are “bad files”?

• Outbound redirects to other sites (usually commercial, porn, gambling links).
• Outbound DDOS on other sites/servers (can be an IP).
• Backdoors (code that lets hackers back into your server, upload files).
• Database-access scripts (Adminer.php) – that lets them change or steal your database info. Adminer script works just like phpMyAdmin but you can call it from your domain….e.g. yourdomain.com/adminer.php.

Again…if you don’t know what belongs or not, just compare with your backup!

STEP #7 – find the vulnerability

Hahaha…you thought you were done, huh?! (Admit it!) You were just about ready to go out and play. No buddy. This is where you have to do the pro’s work…

…time to figure out how the hack/hacker got in.

And if you don’t do this part, they’ll probably get in again and you’ll have to spend all that time repairing all over again. Maybe even more since this time they’ll work harder to hide their hacks better (and create even more backdoors to let themselves in again).

How PROS know how the hacker got in…

Just intuition. Lol, I know this doesn’t help but it’s true. I can look at a site and guess right away how the hacker got in. I wish I had something more scientific to say. Of the 101 places you can look, pros know instinctively where to look first and they find the opening (vulnerability) sooner. This is the value of hiring a pro.

What if you’re not a pro?

Here are the possible hack points:

• WordPress core – especially if it’s not updated regularly
• Theme – especially if it’s crap-coded theme, not updated/maintained, or has special functions.
• Plugin – anything not coded well or not updated. Most common are plugins that save frontend input to your database…basically anything with a form or allows user-entry. Also anything that makes or accepts external connections (like plugins connecting to home server or does API stuff).
• Bad webhosting configurations – weakness in htaccess or web-server configuration. Outdated PHP, MySQL.

One really good place to check is your website error.log in your website directory. Usually hacked themes or plugins will spit error messages since their code is altered. And if you see many error messages from a specific plugin, then you know it’s likely to be the one that’s hacked.

Scan for modified files

From your server CLI (if you have access), you can run some linux commands:

• find /home/user -type f -ctime -7 – searches all files within /home/user directory changed within 7 days or less. (Change to + sign if you want to search for changes older…usually uncommon.)
• Change that -7 to however long ago you were hacked. Ideally, you noticed it within 24 hours or less. If the hack occurred like 30 days ago…well…God help you (try and you’ll see what I mean).

You should also use grep -r "string" /home/user – searches /home/user directory for all files named “something”…but instead of “something”, replace it with the following base64 code below.

• base64_decode
• gzinflate(base64_decode
• eval(gzinflate(base64_decode
• eval(base64_decode
• I like this command too: grep -E '[A-Za-z0-9+/]{4}*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)'

The toughest part about closing vulnerabilities…

Is that you have to close the original one (the one the hacker got in through)…as well the new ones the hacker made (to keep letting themselves back in after you close the original). Maybe they got in through one plugin but now they put backdoors in all directories (WordPress core, theme, other plugins, uploads) and it feels like you’re exposed everywhere.

Quite often, it’s a cat & mouse game between admin and hacker. One closes and the other one opens. Sometimes you think you got them all, the coast is clear for 3 weeks…and then *BOOM*, your site is hacked all over again (because the bastard waited until you weren’t looking).

• How many pros figure out how the hacker keeps getting in, is by scanning the access logs and seeing what files they’re accessing. The problem with this is that access logs are usually rotated (deleted) very quickly and if you don’t check them in time, you lose the valuable info that shows how they got in.
• You can also monitor your server process list as well but this only shows processes right as they’re being run. If the hacker is doing them off-hours or when you’re not looking…you won’t be able to see it. Monitoring the process list only works for on-going brute-force attacks, not for finding the points of intrusion.

Closing the vulnerability

Once you find the vulnerability, the easiest way is usually to just get rid of the theme or plugin that was causing it. Don’t even try to fix the code. GET RID OF IT!

STEP #8 – change all your passwords

By now… the hacks have been cleaned, vulnerabilities closed, new admin accounts deleted. Only thing left is to change all your passwords. (And I’m so sorry…but even non-WordPress ones too!)

• WordPress admin users – all of them!
• Email accounts – any that you think were compromised or using any of the site admin passwords.
• Database user
• Webhosting login
• FTP accounts – all of them
• Personal email/social/PayPal accounts – any accounts like Gmail, Facebook, PayPal that use the same email referenced in your admin user account and/or shared the same password.
• Server root login and VPS login – as well if they use the same email/password.

This isn’t related to passwords but you should also check areas of your site that specify which PayPal email address to pay to. Very often, hackers point it to their own PayPal email account and you’ll have to point it back.

STEP #9 – harden your WordPress site

Securing WordPress applications

• XML-RPC protocol – if you’re not using it. Block it.
• wp-login.php – you should protect this against brute force attacks.
• Update regularly – keep your WordPress core, themes, and plugins updated. Update everything you have installed, not only the ones you use!
• Audit your themes/plugins – don’t install anything that was coded like crap, or hacked/nulled plugins that you got from some “cheap plugin site”. Don’t use anything coded by low-level programmers.
• Install security plugins – security plugins aren’t necessary if your server is secured well but they can help with specific functions and alert you if there’s a potential issue. I like Wordfence for occasional malware scanning and login notifications, but you can use something else if you like.
• Be cautious of any forms you have on your site. Any place that information can be inputted into your site can leave you vulnerable to an injection attack.
• Prevent PHP execution in your uploads directory.
• You might even want to leave a security plugin running, like Wordfence or Sucuri, and have it notify you anytime an admin-level user logs in and/or makes site changes. You can leave it on for 2 months and disable if all is clear. (Or leave it on forever if you like.)

You can Google up guides on how to do these application-level hardening tips.

STEP #10 – what did we learn?

Because if you don’t learn, you’ll suffer again.

• Keep everything updated – WordPress core, theme, plugins…and server OS, software, modules.
• Use strong passwords – do I have to explain this?
• Don’t use same password for everything – don’t use same password for database, WordPress admin, server root, email, Facebook, bank account, PayPal. Or else if they get one, they will get into all the others!
• Remove unused plugins – remove anything you don’t use. It’s less chance of vulnerability and fewer places for hacks to hide in.
• Have backups – it’s often easier to restore a site than clean up a hack. Even if you do want to clean up, having a backup makes it easier to find irregularities.
• Have a developer and sys-admin available – security really isn’t the place to DIY. You should experts available to audit your setup before issues happen, and then also to clean up if you do get hacked.
• Security plugins aren’t foolproof – I’m sure many of you were shocked to get hacked even with a security plugin enabled. Hahaha!

Hack repair is a painful and time-consuming task to do correctly. As I’m sure you see by now, there are many corners that can be cut. And the only way to do this right is by doing it yourself or hiring someone who is skilled and truly cares about your site.