This can happen to the best of us. Hacks suck. There is no formulaic response to them that is guaranteed to fix your site, but I’m going to outline a few steps that might get you back in the saddle and hopefully help you identify the extent of the damage. The most common type of hack I see is against sites running known systems (like WordPress) where the hacker modifies the index.php file and prints extra code into the pages. This causes visitors to inadvertently download malicious code and it causes Google to black-list your site. Did this happen to you? Keep reading…
1. Verify that no sensitive data was on the server. It’s a whole other ballgame if you were storing credit card or social security numbers. In a nutshell, never store sensitive data on your server! It’s too hot to handle! Let a professional store that stuff. If you did have sensitive data on your server, you can stop reading now, because you need to hire a professional security consultant (and possibly a lawyer) to help dig you out of this mess.
2. Take a snapshot of the crime-scene. Zip up a copy of all files on the site and copy of the database. You should also get copies of your system’s logs dating back to sometime before the hack occurred. You may not need to touch this stuff ever again, but there’s a possibility that later on, a security consultant may want to look at your “bag of evidence”.
3. Restore from backup. You did have backups right? Sometimes it is difficult to know which backup to use. Inspect the backups carefully: you want to find a clean copy. Your host should be able to help identify a time frame of when the site was compromised.
4. Determine your Exposure. If your site was running WordPress (or any CMS), then your database and your database login got exposed. This is simply because if the hacker was able to write to your index.php file, he was certainly able to read your CMS’s config file (e.g. wp-config.php), and thus able to read everything in the database. You have to assume that any passwords in that database are cracked. You can never use those passwords again.
Important question #1: did you use that same password on other sites (e.g. Gmail, Yahoo, Facebook, etc)? If the answer is yes, you need to change those passwords immediately. You’re in a race against time here: any hacker with an ounce of curiosity will try logging into other sites using the credentials he cracked from your database. This is why you should never reuse a password: if one site gets hacked, the dominos start falling. You can use 1password or a similar tool to help you manage your passwords.
Important question #2: does your database login have access to other databases? If the MySQL user you used had access to other databases, you have to assume that any data in those databases was also compromised (including passwords). So you may need to force a password update for those sites too. The lesson here: NEVER grant a MySQL user access to more databases than it absolutely needs.
Important question #3: did you use the same username/password for anything else on your server? Like your FTP login or your cPanel password. If you made that mistake, then you need to assume that the hacker compromised everything that he would have been able to see with that login. If this is your cPanel or WHM control panel, then it’s possible that ALL sites on that server or the server itself were compromised. At that point, you may need to restore your entire server or set up a new one entirely. Again, if you find yourself in this situation, consult with your hosting provider or find a qualified security professional.
5. Consult with your hosting provider or sysadmin. You need to figure out what files the hacker would have had access to. In a PHP site, that means that you would have to figure out what user and group PHP was running as. If you determine that the hacker was able to get root privileges, then you have to assume that any passwords on your server were harvested and cracked, and all sites and all data on the server were compromised. At that point, you need to restore your entire server. If you determine that only your home-directory was exposed, then you can continue patching things up. Make sure that no sensitive files were anywhere in that your user’s home dir. Some juicy targets for downloading might be any notes with logins or backup files that contained other configuration files.
It’s usually not 100% clear how exactly a hacker got in… an unpatched WordPress plugin might not be as bad as an unpatched version of OpenSSH. Your sysadmin might be able to help determine the attack vector. If you want to sniff around, google names and versions of WordPress and/or plugins on www.exploit-db.com — it’s a one-stop shop for hackers, so if you see something on there that matches what you were running, it’s probably a good indicator that that’s how they got in. Hopefully your hosting provider will shoot you straight about what versions of software they were running — most hosts worth their salt will keep their servers patched, and most often, it’s the users who forgot to update something on their site. If you are reasonably certain that the hacker did not gain root privileges, then you can keep going…
6. Change ALL passwords on the server. The database login credentials were exposed via the config file, so you’ll have to change your database login at a minimum, but it’s a good idea to swap out other credentials at this time too — it’s possible that there were keyloggers or other payloads that harvested those other logins, so you’ll want to update them. REMEMBER: you need to do this even if you were able to restore from backup.
7. Update all your files. Update your server (if possible), your version of your CMS, any plugins, any themes, etc. Basically, if you can re-install something on your site, do it. You don’t know for sure if the backup had the same vulnerability, and it’s possible you may just be repeating this exercise in a few weeks if the same vulnerability is exploited again. Really the only stuff you want to keep is stuff that you (or other users) generated, i.e. content. Everything else should be re-installed from a trusted source. Inspect your content carefully for any strange code or payloads… it’s possible that the backup you restored from may not have been clean.
8. Notify Google. Presumably, this whole affair got your site black-listed from Google, so once you’ve cleaned up the damage, you need to fill out a form with Google and request that they re-scan your site. Often you have to specify what steps you took to clean things up. You should expect your site to black-listed for 48 hours. Sometimes you’ll be back online faster than that, but the time frame is not predictable.
Hope this helps those people who have found themselves in this unenviable situation. If you need more of a post-mortem than this, or if you need more protection moving forward, you can look into monitoring services or having a penetration test done. Security is one of those areas where it can be hard to know when to stop — it is a journey more than a destination, and at some point you have to strike a balance to get a setup that has acceptable risk.
-- Everett Griffiths