Your Drupal Site has been Hacked….Now What?

It’s finally happened. Your Drupal site has been hacked. There’s a lot to do, but what it all boils down to is, you need to clean up your website and prevent further hacks.

But you’re not here for the short answer. You want to know how to clean up and prevent. Here’s how:

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

Top 3 things to document:

  • Current issues and any suspicious activity that you identify on your site
  • All steps that your strategyfor removing malware and restoring your site should include
  • Preventive security measuresyou will be taking to prevent this from happening in the future

Step 2: Make a Forensic Copy

Before you start investigating how your Drupal site has been hacked and way before you begin to rebuild anything, make a forensic copy of all your files, your database, and your operating system environment. Employ external storage for these copies and store them offsite.

As you’re scanning through your files, detecting viruses and malware and having them cleaned up, make new “working backups”. Store those in a different directory from your regular backup files. These backups will come into play when you try to fix the issues you detect. If for some reason, but instead you make them worse; then, you can easily roll back those changes.  They would also be useful, if you call upona third party to assist you with the troubleshooting process. The backup can provide a clear picture of the site before you started “malware detecting” on your own.

Step 3: Scan Your Servers and PC

Your next step is togive both your PC and your servers a deep scanfor malware, malicious code Injections, virusesbefore making any changes. For instance, don’t rush to change all the passwords on your site. What if the attack has been “programmed” so that the attacker is notified once you change your password(s), or what if your PC or one of your servers that’s infected? Storing a clean backup of your site there would only make it even more vulnerable.

Step 4: Detect & Remove the Backdoors

These could create easy-access for hackers even after you’ve removed malware and restored it to its healthy state. Here are a few key places on your site that you should look for these:

  • 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

Your decision to take your site offline depends greatly on the nature of your site. For instance, ifit’s an eCommerce Drupal site, then don’t wait! Take your site down (along with the internal network and servers) and install a placeholder! This will prevent malware from being further distributed and spam from being sent to your customers.

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.

Word of caution:don’t mistake “Drupal maintenance mode”for “offline Drupal”. They’re two 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

If your hosting provider wasn’t the one to notify you that your site has been hacked, then they should immediately be informed about the breach and about your site being taken offline (if that’s the case).

The sooner the better. This way they can start scanning their own systems for incursions and get ready to assist you with your site recovery and securing process.

Step 7: Handle Client Data with Extra Precaution

It goes without out saying that your client data is sensitive. Here are three scenarios where you’ll need to take extra precautions:

  1. Your 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 apply, then here some extra precautions you can take 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

Though you may be under pressure to get your site back online ASAP, remember you have a responsibility to do it right. You MUST expose the main source of contamination on your site;the key vulnerability that attackers exploited to hack in the first place.

That being said, make sure that you first audit, on a staging server, that “clean” backup of your sitethat you’re planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code. This is a tedious task; you compare pre-and post-hack files, looking for any suspicious changes.

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

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). You’ll also want to look for any sources of “Drupal site hacked redirect”; for links to external URLs.

Here are a few places to begin running your investigation:

  • .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

You’ve went through 8 steps of assessing damage detecting vulnerabilities and so much more. Now, all that’s left to do is repair your website, right?

Before you begin, let’s share another important tip: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 securityupdates.

In repairing your site, you have 2 options. You eitherrestore 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, oryou rebuild your Drupal site.

A rebuild is more cautious, but way more cumbersome. There are a few scenarios where it’s a no-brainer though:

  • You do not know the precise date and time when your site was 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
  • Close all the backdoors!

Dealing with a hacked Drupal site is a pretty long, complex and discouragingly tedious recovery process. It can be avoided with some simple precautions and regular backups. Contact Contegix to host your site on a safe, secure environment, and to learn more about our managed backups solution.