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 clean their hacked Drupal site. This is not meant to be an all-encompassing guide, but it addresses the most common infections we see.
You can use tools that remotely scan Drupal for malware 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.
Free Drupal Scanners:
Drupal scanners and other resources:
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.
Drupal hacked scan results in SiteCheck.
A remote scanner will check the site externally using different user-agents, but some issues do not present themselves in a browser. Hidden infections (i.e., backdoors, phishing pages, and hidden scripts) can be found using a server-side scanner. Learn more about how remote scanners work.
New or recently modified files may be part of your Drupal site 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 site’s 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:
We highly recommend using FTPS/SFTP/SSH rather than unencrypted FTP.
You can also use the Hacked! module for Drupal to get a report of any integrity issues with your core files and modules, which could be an indicator of a hacked Drupal site.
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.
Caution
It is important that you compare the same version of your Drupal site’s 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:
Log into your server using an FTP client or SSH terminal.
If using SSH, you can list all files modified in the last 15 days using this command:$ find ./ -type f -mtime -15
$ 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.
Drupal 7: People Panel
Drupal 8: People Panel
If your Drupal site has been blocklisted by Google or other website security authorities, you can use their diagnostic tools to check the security status of your hacked Drupal website. It’s an effective way to verify if a Drupal site is hacked.
For more information about these security warnings, read our guide explaining the Google blocklist.
To check your Google Transparency Report:
Google Transparency Report
If you have added your Drupal 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:
Our Website Application Firewall (WAF) stops bad actors, speeds up load times, and increases your website availability.
Now that you have identified potentially compromised users and malware locations, you can remove malware from your hacked Drupal site and restore it 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 your Drupal website’s malware.
If any scans or diagnostic pages revealed malicious domains or payloads, you can start by looking for those files on your Drupal site’s 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 Drupal malware.
To manually remove Drupal malware:
If you can’t find the Drupal malware, 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.
Resources
Top Drupal directories where we find malware infections:
Other tools to scan your hacked Drupal site website:
Caution
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.
Never perform any actions without a backup. If you need help with this, review the official Drupal Backup Docs or look into free Drupal backup tools such as Backup and Migrate and a Node Squirrel.
To remove a Drupal malware infection from your database, you need to open a database admin panel, such as PHPMyAdmin. You can also use tools like Search-Replace-DB or Adminer.
Caution
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.
To manually remove a malware infection from hacked Drupal site’s 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.
Hacked Drupal Database Example
Top infected Drupal database tables we see:
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:
Caution
These functions can also be used legitimately by Drupal extensions, so be sure to test any changes because you could break your site by removing benign functions.
Always remember to compare files using the same Drupal version.
To remove Drupal backdoors by comparing files:
Example of Comparing Files to find Backdoors
The majority of Drupal malware 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. A web application firewall (WAF) may be the best strategy, as it blocks hackers before they can install backdoors.
If you were blocklisted 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 all Drupal malware is removed before requesting a review!
For more details on how to remove website security warnings, read our guide explaining how to remove the Google blocklist.
To remove malware warnings on your hacked Drupal site:
With the Sucuri Platform, we submit blocklist 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 your Drupal hack 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 Drupal getting hacked, 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.
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:
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.
We recommend using the Key module along with Lockr to ensure keys are managed offsite.
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 7: Updates
Drupal 8: Updates
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.
If you are manually updating core files, follow the official upgrade docs for Drupal 8 and Drupal 7.
To manually update Drupal core files:
Caution
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:
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 security 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.
To update Drupal software we recommend using Drush:
All accounts should use strong passwords – complex, long, and unique. We recommend using password manager and generators to simplify the process.
Drupal 7: Password Reset
Drupal 8: Reset
Backups function as a safety net. Now that your previously hacked 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 with Drupal site backups:To reset passwords for Drupal user accounts:
Have all Drupal users run a scan with a reputable antivirus program on their operating systems.
Drupal security can be compromised if a user with an infected computer has access to the dashboard. Some Drupal hacks 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 toolsx 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 plan includes protection, monitoring, and response.
Drupal protection resources:
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.
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.
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.
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.
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.
Say on top emerging website security threats with our helpful guides, email, courses, and blog content.