My Drupal Site Has Been Hacked: What Do I Do? How Do I Restore It? 10 Steps to Clean It Up

Oops! The worst has happened: your Drupal site has been hacked! Maybe it was precisely one of those critical vulnerabilities, that the Drupal security team has been drawing attention to these last months, that the attacker(s) exploited? 

Now what? What to do?

Should you be:
 

1. rushing to restore your website to a healthy, good-working state (that, of course, if you do have a clean and recent backup available)?
2. starting to rebuild it?
3. investigating how your Drupal site got contaminated in the first place: where's the “open door” that the attackers used to get in?
4. focusing on closing any backdoors that could make new attacks possible?
    

Now “tormenting” yourself with too many questions simultaneously will only distract you from what should be your main objective: cleaning up your website (and preventing further hacks I should add).

So, let's go about it methodically, step by step:
 

Step 1: Write Down Issues, Steps to Take, Preventive Measures to Apply

Keep your cool and go for a methodical approach to crisis management:

Just open up a document and start... documenting:
 

• the issues and any suspicious activity that you identify on your site
• all the steps that your strategy for removing malware and restoring your site should include
• the preventive security measures you commit to taking for preventing such a scenario from happening again the future
   

Step 2: Make a Forensic Copy of Your Drupal Site 

Before you start running your “investigations” on the attack, on how your Drupal site has been hacked, and way before you get to rebuild anything:

Make a forensic copy of all your files, you database and your operating system environment!

Note: go with an external storage medium for these copies and store them offsite.

As you're scanning through your files, detecting viruses and malware and having them cleaned up, feel free to make new and new “working backups”. And to store them in a different directory (from your regular backup files, I mean).

“But why bother? When will these backups turn out particularly useful?”
 

1. when you call out to a third party to assist you with the troubleshooting process; these “working” backups will then provide a clear picture of the site before you started “malware detecting” on your own
2. when you try to fix the issues you detect, but instead you make them worse; then, you can easily roll back those changes 
    

Step 3: Scan Your Servers and PC for Malware, Malicious Code Injections, Viruses

Before you rush to change all the passwords on your site, pause for a moment to think through your next “move”:

What if the attack has been “programmed” so that the attacker should get notified once you change your password(s)? And what if it's precisely your PC or one of your servers that's got infected? Then storing a clean backup of your site precisely there would only make it even more vulnerable.

So, how do you prevent that? You give both your PC and your servers a deep scan before making any change.

And, thank God, you sure aren't nickel and dimed in anti-malware tools and anti-virus software: AVG, BitDefender, Malwarebytes, ESET, AV-Comparatives etc.
 

Step 4: Detect & Remove the Backdoors

One of the crucial steps to take, once you realize that your Drupal site has been hacked, is to “close” all the backdoors.

These could easily turn into hackers' access ticket into your site even after you've removed malware and restored it to its healthy state. But, for closing them you first need to... find them right?

So, where to look?

Here are a few key places on your site that you should focus your “searches” on:
 

• access logs: while scanning them, be vigilant and look for PHP scrips and POST requests added to directories that have writable access
   
• eCommerce set up: check all the payment methods, shipping addresses, credit card addresses, linked accounts, looking for any suspicious, newly added data
   
• passwords: FTP passwords, admin passwords, control panel passwords
   
• email rules and filters: check that the answers to the security questions are “legitimate”, that messages are being forwarded to correct email addresses etc.
   

Step 5: Consider Taking Your Site Offline

And your decision depends greatly on the nature of your site:

If it's a hacked eCommerce Drupal site that we're talking about here, then don't wait even one more minute: take your site down (along with the internal network and servers) and install a placeholder!

This way, you'll prevent:
 

• malware from being further distributed
• spam from being sent to your online store's customers
   

Note: do keep in mind that taking your site offline will instantly let the attackers know that you've detected the malware that they've “infiltrated” and that you are about to “take action”.

If you decide not to take your Drupal site offline at the web server level, ensure that you've got your clean forensic copy at hand before deleting all the sessions.

Note: have you detected suspicious changes of the passwords? If so, use this query here for updating them (Drupal 7):
 

update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))))

As for the users, they can easily use the reset password tool for updating their passwords.

Word of caution: mind you don't take "Drupal on maintenance mode” for “offline Drupal". They're 2 completely different things! Once your Drupal site has been hacked, the malware could be of such nature that it allows the attacker to infiltrate as long as the site's online.
 

Step 6: Notify Your Hosting Provider That Your Drupal Site Has Been Hacked 

They should be informed about the breach and about your site being taken offline (if it's the case) immediately.

The sooner the better, this way they can:
 

• start scanning their own systems for incursions
• get ready to assist you with your site recovery and securing process
   

Step 7: Handle Client Data with Extra Precaution 

And these are the specific scenarios where you'll need to take extra precautions when handling client information:
 

1. your Drupal site stores client information on the web host
2. … it leverages the data POST method for sending form data via e-mail
3. … it doesn't integrate with a 3rd party payment gateway, but manages the payment processes itself
    

If one of these 3 scenarios suits your case, then here are some of these extra precautions that you need to make to ensure the private user data doesn't get exposed:
 

• update your SSL certificate
• re-check all logfiles (have any of the hosted client information been copied, updated or downloaded?)
• implement AVS (address verification system) 
• add CVV (card verification value)
• encrypt connections to back-end services used for sending confidential user data 
   

Step 8: Investigate the Attack: Identify the Source(s) of Infection

No matter how much pressure you might find yourself under to get your site back online ASAP, don't let take control over your site's restoring process!

Not until you've detected the main source of contamination on your site. The key vulnerability that attackers exploited, the key reason why your Drupal site has been hacked in the first place.

That being said, make sure that:
 

1. you first audit, on a staging server, that “clean” backup of your site that you're planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code 
2. you compare pre- and post-hack files, looking for any suspicious changes
    

Now if you have a clean (and recent) backup at hand for running this comparison, the problem's almost solved. Just use the right tools to compare your files and track down discrepancies.

But if you don't have a backup at hand, then there's no other way but to:

Manually inspect your files and databases to identify any suspicious changes that have been made.

• look for any suspicious iframe or JavaScript at the end of the files (if detected, save the code in an external file)
• look for any sources of “Drupal site hacked redirect”; for links to external URLs
   

Now, as for the places that you should be running your investigations on, let me give you just a few clues:
 

• .php files, .html files 
• sessions table 
• newly modified/created files
• new/updated user accounts 
• in writable directories and database 
   

Step 9: Do a Full Restore of Your Site 

So, you've noticed that your Drupal site has been hacked, you've assessed all the damage caused, removed malware and even detected the vulnerability that hackers exploited to get in, not it's only but logical to:

Try to repair your website, right?

Word of caution: never ever run your changes on your production site; instead, fix all detected issues on a staging site. Also, once you've cleaned it all up, remember to run the latest Drupal security updates, as well!

Now, getting back to repairing your site, you have 2 options at hand:
 

1. you either restore a clean backup, if you know the date and time that your Drupal site has been hacked and you're also 100% sure that none of the system components, other than Drupal, got contaminated
2. or you rebuild your Drupal site 
    

The latter method is, undoubtedly more cumbersome, yet a lot more cautious. Go for it if:
 

• you do not know the precise date and time when your site's got contaminated
• you do not have a clean (and recent) backup available to restore
• you've evaluated the damages as being already too widespread  
   

Step 10: Give Your Restored Site a Full Check Before Going Live 

Do remember to give your newly recovered site a final audit before getting it back up:
 

• remove all malicious code detected
• suspicious files
• unauthorized settings
   

And, most of all:

Close all the backdoors!
 

Final Word 

A pretty long, complex and discouragingly tedious recovery process, don't you think? 

So, why wouldn't you avoid all these steps that you need to go through once your Drupal site has been hacked?

Why not avoid the risk of finding yourself forced to take your website offsite for... God knows how long, risking to impact your site's reputation and to drive away users/online customers?

Don't you find it wiser to:
 

• be prepared instead?
• opt for ongoing Drupal maintenance and support services?
• make a habit of regularly backing up your website?
• keep your system and software up to date (and to install all the recommended patches)?
• stop underrating the security advisories that the Drupal team makes?