It was about the end of the year 2008 when one of my clients reported the dreaded message “This site may be hacked” in the search snippets for one of her sites. A quick visit to Google Search Console confirmed that this wasn’t done in error. The client had verified everything (to the extent she could verify things) and had submitted a reconsideration request to Google. It was declined.
She had been talking to the hosting support. An agent attended to the chat in 25 minutes and escalated the issue to the security team. The security team mailed her asking for more information and put the ticket into pending.
It had been hours and she wanted professional intervention. I took over, chatted with the support, they did a malware scan, found nothing and closed the ticket as resolved.
This wasn’t just some “yet another cheap hosting company”. They are in the list of the most respectable and trusted hosting providers.
Well if that’s all that the hosting support can do, then matters need to be taken into your own hands. Let’s begin:
1. Get a virtual machine
Having a virtual machine is a security safe-guard that limits the security issue to the virtual-machine and keeps your actual system safe. A virtual machine is the difference between some blogger preaching on how to recover your hacked website versus a professional trying to recover another hacked website on one fine day. Don’t be another victim to your own hacked website. You have to remedy it. You don’t necessarily need VMware or Hyper-V etc. VirtualBox has the name and backing of Oracle, is free and is cross-platform. Install a VM guest OS that you feel right at home with and get ready. Follow these steps inside the virtual machine.
2. Disable your website and block it all
The first step in troubleshooting a hacked website is to disable your website. Disable could mean many things. A good web host by default would block the website. This has a two fold purpose:
- Stop the infected website from being publicly viewable. An infected website may be defaced and could infect the computer system of visitors.
- Stop the hacker from doing anything further. Once the website is offline, the hacker wouldn’t / shouldn’t have access to it, thus limiting the extent of damage already done.
What exactly does blocking mean and how to block your website
- Take a pen and paper. Trust me, you are going to do quite a lot and you want to note everything down. You can use your computer system to take notes and screenshots but there’s quite nothing like pen and paper if your battery goes down or the kids spill a glass of water just when the world is about to go down. Not unless you’ve got a goat indoors that would eat your paper. Pointwise note down everything you are doing. I’ll expand on this later.
- The first thing that you should do is to put your website into maintenance mode. You can use the excellent WP Maintenance Mode plugin by Designmodo. This disables public access to your website. But you are not done yet. You’ve barely gotten started.
- Your hosting provider would have given you some sort of access to a control panel. It could be VirtualAdmin, Webmin, cPanel, WHM, etc. You now need to limit the backend access to your site.
- Update your password to the control panel. Note it down on paper for now. We’ll change it again later. Think of something at least 8 characters and easy to remember. Something like this but not the same:
the cat underscore is not dead.
- Identify who has access to the hosting. Often you may have multiple users who have access to the hosting account. You will need to revoke their access at least temporarily.
- Change the password for mysql / mariadb, phpmyadmin, ftp, ssh and WordPress admin backend. I can’t cover the exact steps as this would vary depending on your hosting provider. Note down each new password and where it belongs.
3. Backup as a precaution
It’s obvious that now is not a good time to backup. But you still need a backup. This is for several reasons:
- This is the latest backup of your site with the most recent posts, pages and other data.
- This backup also has the proof and evidence of the security issue at hand, which you can use to study things later and do a root-cause-analysis.
- This also is the latest backup in case things go south and we need to recover stuff.
Don’t keep this backup on the server. Download it to your virtual machine.
4. Identify the issue
So what exactly is the issue? This is the most challenging part and much depends on your technical aptitude as well as understanding of the issue and approach. There are several ways you could identify the problem.
- The source of the webpage: If that’s how Google detected it, then the evidence will be here. Check the html source of the webpage. It’s quite possible that only a few web pages are affected and it’s totally possible that the entire website is affected. So pick a url where the issue is reported. It may not be evident and obvious so look carefully. Scan each line and look for issues (yes it’s vague but that’s how a professional will try to smell things).
- What all is loading: Sometimes the issue may not be obvious from the source-code of the webpage. The browser’s built-in developer tools come in pretty handy. Open up the browser tools panel and go to the Network tab. Load the website and look for what all is getting loaded. We are looking for anything loading from external domains in particular, but keep an eye out for anything that looks suspicious on the local domain too.
- Looking for more similar infected files: If you have shell access to your hosting (in depends on the kind of hosting are you running) then it should be a simple matter of running a grep command to scan all files for that particular string.
- Inline scripts and content: Regardless of whether or not you found a rogue script, you will need to scan the website and see if there’s something in the database too. You can use phpmyadmin or the mysql command-line to search for strings like
display(which you’ll find many and most would be legitimate).
5. Identify the scope of affect
Hopefully by now you have identified the issue. Correction, hopefully you’ve identified something by now. But it is only a symptom. You need to correlate your findings and identify if the breach was limited to a single site, a single hosting account or at the operating-system level. Only then you’d know what all to fix and how to fix it.
6. Fixing the issues
7. Root-Cause-Analysis & Finding Security Loopholes
While a complete list of security loopholes is impractical to cover since everyday new loopholes are discovered and it’s basically a catch-up game before the bad guys innovate something new and then the good guys plug-in the hole; a root-cause-analysis will:
- Help you identify the attack vector (how it happened) and fix the root-cause of the problem so that it doesn’t happen via the same loophole again.
- Give you valuable insights on the system and security internals.
I’m however listing some of the most common attack vectors:
- Allowing (unauthenticated) user-upload of files.
- Allowing user-upload of unsanitized / unescaped data.
- Some rogue script that your web-developer left over when migrating your WordPress website.
- Some clipboard content that automatically got pasted when copying text over from some other webpage and included inline script(s).
- Too many users, accounts with access to your hosting / WordPress / FTP / SSH.
- Easy to crack passwords.
- Mis-configured server that misbehaves or leaks confidential information contained in PHP files.
- Rogue WordPress Theme or Plugin.
8. Finally What Did It Look Like
I can’t even begin to list what all ugly hacks exist there. But for this specific case, it was a base64 encoded piece of script. The catch was that it was encoded 10 times. So every time I decoded it, I didn’t see anything which I could make sense of… not until I decoded it 10 times. And even after that, the hacker was smart enough to use a piece of packed code that looked just cryptic and rubbish.
Let’s see if we can make sense out of it:
Fourth line from the top:
iframe with the characters reversed.
5000px, so on and so forth.
After some clean up and fixing, while going through the URLs I came across a URL which had a form for attachments. I’ll not go into the specific details and teach you how to duplicate this and hack someone’s website though.
9. Verifying That The Site is Clean and Accepted
- Once you have made sure that there are no security loopholes open and that your server is configured right, website is clean and ready to go live, you can make it live and submit a reconsideration request. Do not add any new users or allow anyone other than yourself to have privileged access. Give yourself 48-72 hrs. and watch out for any troubles.
- Later when all seems to be going well and there are no more issues reported with the website, it’s time to take a backup.
- Now finally you can change the passwords once more to something strong, that’s not written on a piece of paper and you can add other users who need access to the website, hosting etc.
10. Preventing Attacks in the Future
While it sounds contrary to the popular word out there, as an IT person I personally do not recommend any third-party plugins or scanning services — they charge monthly, send cryptic notices about security issues and don’t fix things for you unless you give them a ransom. Installing plugins that list the security gaps is good. However you’ll need help of a professional who can make sense of the security messages and help you rectify them. Hardening WordPress installs is something that you should entrust to a professional (and not a self-proclaimed one). With a well-maintained security infrastructure, you wouldn’t need to worry about much.
- Keep your accounts secure. Passwords can be stolen from emails, stolen phones and what not.
- Keep your hosting server properly configured with a well-secured firewall and other security infrastructure.
- Don’t leave rogue data, files, forms on the server. They can be used for various types of attacks.
- Keep your WordPress installation, themes and plugins updated. This has the additional challenge of keeping the environment stable and compatible.
Sites get hacked all the time. It’s important to know what do to and how to do things because security issues like this are a time-sensitive matter. Too late and loss increases exponentially. You can’t afford to “try” things and “see if it works out”. So here’s my advise:
- Maintain regular backups of all the website files including databse.
- Harden your WordPress install.
- Don’t neglect the Google search console.
- It’s not a matter of “if” but rather when you’ll be affected.
- Keep your calm, get professional assistance and don’t try things unless you want to mess up with the database and Linux utilities.
- Keep a close watch after things are back in place.
Hope this post helped shed some light on what it is to recover from a hacked WordPress website. If you need help, I’m only an email away.