In This Guidex
Fix the hack and protect your Drupal website.
Sucuri is committed to helping server administrators check their website for hacks and remove malware infections. We created this guide so Drupal users can identify and fix a Drupal hack. This is not meant to be an all-encompassing guide, but it addresses the most common infections we see.
Common Indicators of a Hacked Drupal Site
You can use tools that scan your site remotely to find malicious payloads and malware locations. These instructions are for our free remote scanner, SiteCheck. Other online scanners and Drupal extensions can also help you look for indicators of compromise, malicious payloads, and other security issues. Tools for checking security misconfigurations in Drupal could help you identify possible attack vectors.
Click Scan Website.
If the site is infected, review the warning message.
Note any payloads, locations (if available), and blacklist warnings.
If you have multiple websites on the same server we recommend scanning them all. Cross-site contamination is one of the leading causes of reinfections. We encourage every website owner to isolate their hosting and web accounts. See the Drupal Multisite Docs for more info.
New or recently modified Drupal files may be part of a hack. Your core, contributed, and custom modules should also be checked against known good copies to identify malware injections.
The quickest way to confirm the integrity of your Drupal files is by using git status (or another version control system) to check for changes, commit any new branches, and then roll back to the last known good set of code.
To use git to check for changes:
You can also use the Hacked! module for Drupal to get a report of any integrity issues with your core files and modules.
Another option is to use the diff command in terminal to compare to the known good files. You can find all Drupal versions on GitHub. Using an SSH terminal, you can download Drupal locally. The following commands use version 8.3.5 as an example of the clean files and public_html as an example of where your Drupal installation is located. The final diff command will compare the clean Drupal files with your installation.
We highly recommend using FTPS/SFTP/SSH rather than unencrypted FTP.
It is important that you compare the same version of your Drupal core files and extensions. Core files on the 8.x branch are not the same as the 7.x branch and so on.
To check core file integrity with SSH commands:
$ mkdir drupal-8.3.5
$ cd drupal-8.3.5
$ wget https://github.com/drupal/core/archive/8.3.5.tar.gz
$ tar -zxvf core-8.3.5.tar.gz
$ diff -r core-8.3.5 ./public_html
To manually check recently modified files:
$ find ./ -type f -mtime -15
Unfamiliar modifications in the last 7-30 days may be suspicious and require further investigation.
Verify any unknown Drupal user accounts, especially administrators.
To check for malicious users in Drupal:
Wait to change user passwords until after you have completely cleared the site of malware. This ensures that hackers no longer have access to any user accounts. You can use a module like Mass Password Reset to force all users to reset their passwords.
If your Drupal site has been blacklisted by Google or other website security authorities, you can use their diagnostic tools to check the security status of your Drupal website.
For more information about these security warnings, read our guide explaining the Google blacklist.
To check your Google Transparency Report:
If you have added your site to any free webmaster tools, you can check their security ratings and reports for your website. If you do not already have accounts for these free monitoring tools, we highly recommend that you sign up:
Now that you have identified potentially compromised users and malware locations, you can remove malware from Drupal and restore your website to a clean state.
The best way to identify hacked files is by comparing the current state of the site with an old and clean backup. If a backup is available, you can use that to compare the two versions and identify what has been modified.
Some of these steps require web server and database access. If you are not familiar with manipulating database tables or editing PHP, please seek assistance from a professional Incident Response Team member who can completely remove Drupal malware.
If any scans or diagnostic pages revealed malicious domains or payloads, you can start by looking for those files on your Drupal web server. If you use a version control system like git, you can rollback to a known good copy, delete new suspicious files, and checkout to revert any maliciously modified files.
By comparing infected files with known good files (from official sources or reliably clean backups) you can identify and remove malicious changes.
To manually remove a malware infection from your Drupal files:
If you can’t find the malicious content, try searching the web for malicious content, payloads, and domain names that you found in the first step. Chances are that someone else has already figured out how those domain names are involved in the hack you are attempting to clean.
To remove a malware infection from your Drupal database, you need to open a database admin panel, such as PHPMyAdmin. You can also use tools like Search-Replace-DB or Adminer.
To manually remove a malware infection from Drupal database tables:
You can manually search your Drupal database for common malicious PHP functions, such as eval, base64_decode, gzinflate, preg_replace, str_replace, etc. Note that these functions are also used by Drupal extensions for legitimate reasons, so be sure you test changes or get help so you do not accidentally break your site.
Manually removing “malicious” code from your website files can be extremely hazardous to the health of your website. Never perform any actions without a backup. If you’re unsure, please seek assistance from a professional.
Hackers always leave a way to get back into your site. More often than not, we find multiple backdoors of various types in hacked Drupal sites.
Backdoors are usually embedded in files that are named just like legitimate files within the official Drupal framework but located in the wrong directories. Attackers can also inject backdoors into files like index.php and directories like /modules, /themes, /sites/all/modules, and /sites/all/themes.
Backdoors commonly include the following PHP functions:
To remove backdoors by comparing files:
The majority of malicious code we see uses some form of encoding to prevent detection. Aside from premium components that use encoding to protect their authentication mechanism, it’s very rare to see encoding in the official Drupal repository.
It is critical that all backdoors are closed in order to successfully clean a Drupal hack, otherwise your site will be reinfected quickly.
If you were blacklisted by Google, McAfee, Yandex (or any other web spam authorities), you can request a review after the hack has been fixed. Google is now limiting known repeat offenders to one review request every 30 days. Be sure your site is clean before requesting a review!
For more details on how to remove website security warnings, read our guide explaining how to remove the Google blacklist.
To remove malware warnings on your site:
With the Sucuri Platform, we submit blacklist review requests on your behalf. This helps ensure your site is absolutely ready for review. Some reviews, however, such as web spam hacks as a result of manual actions, can take up to two weeks.
In this final step, you will learn how to fix the issues that caused Drupal to be hacked in the first place. You will also perform essential steps to enhance the security of your Drupal site.
Outdated software is one of the leading causes of infection, and it is important to remove any known vulnerable extensions. Though Drupal uses a secure hashing algorithm to prevent passwords from being hacked, it’s always a good idea to reset passwords to ensure you are not reinfected if hackers gained access to your credentials.
Clear Active Sessions
If a user account has been compromised it’s important to log them out and force a password reset so they lose access to your site. The sessions table in your Drupal database keeps a record of every user login and you can remove them.
To clear active Drupal user sessions:
Reset API Keys
Your API keys in Drupal should be reset to ensure they have not been compromised by the attackers. Additionally, if your website connects to external services (such as marketing services, payment gateways, and shipping providers) it is a good idea to create new API keys created for those services.
Update Drupal Core and Extensions
Update all Drupal software including core files, themes, and modules.
To check and update Drupal extensions:
To update Drupal software we recommend using Drush:
Drupal 8.x is where all new developments in core are happening. Drupal 7.x continues to receive updates for known vulnerabilities. We recommend keeping an eye on the Drupal Security page for security alerts. Users on the 6.x branch or lower are no longer receiving security patches and strongly encouraged to upgrade to 8.x by following the Drupal Upgrade Docs.
If SiteCheck identified other outdated software on your server (i.e., Apache, cPanel, PHP) in the first step of this guide, you should update those to ensure you have any available security patches.
If you cannot patch, consider activating a website application firewall to virtually patch your site.
To manually update Drupal core files:
Be careful not to overwrite the settings.php file (in /sites/default) file as this will break your site!
Once you are sure everything has been cleaned and updated, as with any update to your site, you should clear the Drupal cache so the latest version of your site is visible to everyone. We recommend using Drush commands drush cache-rebuild (Drupal 8) or drush cache-clear all (Drupal 7).
To manually clear the Drupal cache:
Reset User Credentials
You should reset all user passwords with unique, strong passwords to avoid reinfection.
To reset passwords for Drupal user accounts:
You should reduce the number of administrator and super-administrator accounts for Drupal and all of your website systems. Practice the concept of least privileged. Only give people the access they require to do the job they need.
Keep in mind that the first user created by Drupal during installation (User 1) is the most powerful user in the system. It has permissions above even administrators. Because of this it should not be regularly used. Instead, every administrator should have their own unique account so you can limit admin permissions.
All accounts should use strong passwords – complex, long, and unique. We recommend using password manager and generators to simplify the process.
Backups function as a safety net. Now that your Drupal site is clean and you’ve taken some important post-hack steps, make a backup! Having a good backup strategy is at the core of a good security posture. For more information, review the Drupal Backup Docs. There are also some great free Drupal backup tools such as Node Squirrel.
Here are some tips to help you with website backups:
Store Drupal backups in an off-site location. Never store backups (or old versions) on your server; they can be hacked and used to compromise your real site.
Ideally, your backup solution should run automatically at a frequency that suits the needs of your website.
Store your backups in multiple locations (cloud storage, your computer, external hard drives).
Try the restore process to confirm your website functions correctly.
Some backup solutions exclude certain file types such as videos and archives.
If you are an existing customer, Sucuri offers an affordable system for secure website backups.
Have all Drupal users run a scan with a reputable antivirus program on their operating systems.
Drupal can be compromised if a user with an infected computer has access to the dashboard. Some infections are designed to jump from a computer into text editors or FTP clients.
Here are some antivirus programs we recommend:
You should have only one antivirus actively protecting your system to avoid conflicts. If your Drupal Dashboard user’s computers are not clean, your site can get reinfected easily.
You can harden your Drupal site by restricting file permissions and implementing custom .htaccess or nginx.conf rules. We recommend reviewing the Drupal Security Docs to learn how.
There are a number of modules and tools that can help you protect your Drupal site and prevent a future hack. Many are free and can make it easier to manage specific aspects of website security. A good website security planhttps://sucuri.net/website-security-platform/ includes protection, monitoring, and response.
Test your site against a checklist of common security issues.
Prevents PHP code execution in certain areas and prevents risky permissions being granted.
Define user password policies and strength requirements.
Adds another layer to password security using two-factor authentication options.
Protects your login and web forms from being submitted by malicious bots.
Automatically log users out after a period of inactivity.
Limit login attempts and whitelist access using allowed IP addresses.
Obfuscates email addresses to stop spammers from abusing them.
Enables encrypted communication allowing modules to keep data secured.
An authenticated encryption method plugin for the Encrypt module.
A module that allows other modules to encrypt, filter, and validate data.
Secure, offsite storage and management of API and encryption keys.
Detect common problems with Drupal including security issues.
Fine-tune user roles and ability to grant permissions.
Enforces permission management via code instead of UI.
Force password resets for users if they are lost or stolen.
Distribution modules and settings for enterprise security.
Drupal is a complex and highly extensible CMS, and software vulnerabilities are difficult to predict. Trying to keep up with security patches is challenging for administrators. Website application firewalls provide a perimeter defense system surrounding your website and blocking malicious requests. Trying to keep up is challenging for administrators.
Benefits of using a website firewall:
Prevent a Future Hack
By detecting and stopping known hacking methods and behaviors, a website firewall keeps your site protected against infection in the first place, including the OWASP Top 10 vulnerabilities.
Virtual Security Update
Known vulnerabilities are constantly being exploited, and new zero-day attacks are always emerging. A good website firewall will virtually patch and harden your holes in your website software even if you can’t apply security updates in time.
Block Brute Force Attack
A website firewall should stop anyone from accessing your Drupal admin interface if they aren’t supposed to be there, making sure they can’t use brute force automation to guess your user passwords.
Mitigate DDoS Attack
Distributed Denial of Service (DDoS) attacks attempt to overload your server or web application resources. By detecting and blocking all types of DDoS attacks, a website firewall ensures availability and uptime.
Most WAFs will offer a CDN caching for faster global page speed. This keeps your visitors happy and is proven to lower bounce rates while< improving website engagement, conversions, and search engine rankings.
If you would like help protecting your website, we are available to chat with you about the benefits of using a website application firewall.
After taking steps to secure your Drupal site against future hacks, be sure to keep a record along with your mitigation and identification steps.
Please share this guide if you found it useful and help promote website security education to other website owners. Let us know if you have suggestions to improve this guide in the future.