![How To Clean Up A Hacked Drupal Site [GUIDE]](https://i0.wp.com/secure.wphackedhelp.com/blog/wp-content/uploads/2020/10/fix-hacked-drupal-site-cleanup-guide.png?resize=392%2C300&ssl=1)
Fix Hacked Drupal Site
Table of Contents [TOC]
So Your Drupal site got hacked and is infected with a malware. Now what? What to do when your Drupal website has been hacked? In this post, you will learn more about how to fix a hacked drupal site in and remove Drupal hacked redirect malware infection from the database.
With a dedicated security team, Drupal is considered one of the most secure CMS in the open-source world. The attacks, each more innovative than the other, make security a major issue for the community. However, there is no such thing as zero risks.
You have already faced attacks, crashes, performance issues… but what to do when your Drupal site is hacked? In this post, we summarize some best practices to maintain the security of your site. Since drupal is also iused for ecommerce sites. Check out our guide on ecommerce security threats & best practices.
Looking for a Drupal malware scanner? – we have got a list of website malware scanner tools here.
Drupal Hacked: Possible Hack Results
- Several malicious advertisements and pop-ups appear on the site.
- Users refrain from visiting the site due to lack of trust.
- This site may be hacked message in google.
- New unauthorized administrators appear in the connection database.
- Customers complain about malicious redirects.
- Sensitive information like login, bank details, etc. for sale on the darknet.
- Weird content is showing up on the site due to Japanese keyword hack or pharmaceutical hack etc.
- Phishing pages designed to steal sensitive information appear on the website.
- The message “Your account has been suspended!” Appears during connection.
- The site is blacklisted by google search engine.
- The website is getting very slow and showing error messages.
How do Check if my Drupal site is hacked?
Usually, when a site has been hacked, elements of the interface or the back end have been modified, files are deleted, features are altered or unavailable. Suspicious content or links are now posted on the site.
At the slightest suspicion, it is preferable to analyze the site and the server for traces of hacking. The list of ways to check if a site has been hacked is not exhaustive, but here is a good start to start your investigation:
Analyze server logs – Abnormal error messages can indicate a malicious attack on the site. There are tools like Scalp that allow you to analyze logs. You can also run manual commands to retrieve the contents of the logs directory. For example, in Linux, the Last command displays the list of the last connected users as well as their respective IP addresses.
Identify unusual IP addresses that may be an intrusion on your site.
Scan Modified Files – There are several ways to check if certain files have been modified. For example with Linux, it is possible to use the command # ls -al –time-style=+%D | grep ‘date +%D’ | more to analyze the last modified files (the last 24 hours).
Analyze messages on search engines – in Google search results, Google may display below your site result “This site may damage your computer”. It is also possible to use an antivirus that can detect if the site is corrupted. These messages are indicators that your site appears to have been the victim of an attack.
Signs of a Drupal Malware Redirect:
- Abnormally high website traffic
- Unknown files added to your Drupal site
- New users with Admin rights created
- Clicking links on your website homepage redirect to spam also called hacked site redirect
- Malicious ads or porn pop up on your website
Effective way to check if a Drupal site is hacked.
If your Drupal site has been blacklisted by Google you can use their diagnostic tools to check the security status of your hacked Drupal website. An effective way to check if a Drupal site is hacked.
Worried about Drupal hacked site? Drop us a message on the chat widget and we’d be happy to help you fix it. Secure my Drupal website now.We can thoroughly scan your hacked Drupal site & cleanup any malicious code. CONTACT US HERE
For more information about these security warnings, read our guide explaining the Google blacklisting.
Drupal vulnerability (Drupalgeddon2)
On March 22, the authors of CMS announced the release of a new version of Drupal 7 and 8 to address a critical vulnerability. The update was released on March 28, to correct (among others) the flaw referenced CVE-2018-7600 for the announced vulnerability. Nicknamed “Drupalgeddon 2”, this allows a remote attacker to execute an arbitrary code on the system (RCE) in order to gain control.
What is drupal vulnerability and its impacts?
The DrupalGeddon2 vulnerability, referenced CVE-2018-7600 comes from a failure to process parameters submitted by the user through the account creation and password reset forms, accessible via the “ / user / register” URLs and ” / user / password “.
This lack of processing more specifically impacts the “call_user_func_array” and “call_user_func” functions defined in the “/core/lib/Drupal/Core/Render/Renderer.php” file in charge of generating HTML pages.
By sending a specially crafted HTTP request, an unauthenticated remote user is able to force the remote server to execute arbitrary system commands. Thus an attacker can take control of the underlying system.
Such an attack can be carried out in order to impact the image of a company (disfigurement ), or to compromise the server .
It was found that this vulnerability could be exploited in at least 2 different ways:
- Via the account creation form (“/ user / register “)
- Via the password recovery form (“/ user / password”).
An attacker can inject PHP commands which will be interpreted by the “rendering” engine introduced in Drupal 7.
https://www.drupal.org/docs/7/api/render-arrays/render-arrays-overview
To inject the malicious code, the attacker uses the following native rendering functions:
- post_render
- pre_render
- access_callback
- lazy_builder
For example, to inject code within the account creation page, the attacker uses the “rendering” function named lazy_builder through the timezone parameter. Two arguments are passed to this function:
” [#Lazy_builder] [] = ” allows injecting a PHP function of our choice, such as ” exec “, which allows executing system commands.
” [#Lazy_builder] [] [] = ” contains the possible parameter of the function injected previously.
Thus, sending the previous request to a vulnerable server will allow an attacker to force the server to execute the following command: exec (“echo PWNED> /Applications/MAMP/htdocs/drupal/index.html”);
This execution results in the creation of the page “index.html” containing simply the term “PWNED”.
Rather than creating an HTML page, it is quite possible to upload a web shell, open a backdoor on the server, etc.
A filtering feature has been created to correct the vulnerability. In the CMS source code, this takes the form of a class called ” RequestSanitizer” . The methods of this filtering class are used upstream of the vulnerable code, so their use mitigates the exploitability of the various attack vectors detailed above.
The purpose of the “stripDangerousValues” method is to filter out all parameters prefixed with ‘#’, such as ” # lazy_builder ” and ” # post_render ” used in this attack. This allows preventing an attacker from injecting
“rendering” functions.
This filtering thus makes it possible to avoid the injection of PHP code within these parameters.
OTHER VULNERABILITIES IN DRUPAL
Multiple vulnerabilities have been discovered in Drupal, a free content management system. A remote attacker can execute arbitrary queries on a user, as well as execute arbitrary PHP code.
CVE-2020-13663 [CVSS v3 score: being calculated]: A CSRF type vulnerability has been discovered in Drupal. A remote attacker exploiting this vulnerability can cause the browser of a user visiting the vulnerable page to execute arbitrary requests, by sending specially crafted form entries.
CVE-2020-13664 [CVSS v3 score: being calculated]: An arbitrary code execution vulnerability has been discovered in Drupal. A remote attacker exploiting this vulnerability can execute arbitrary PHP code.
The attack requires that a user visit a site controlled by the attacker, with a specially crafted name in the tree structure of the vulnerable website.
Drupal hacked – Possible Causes
Let’s take a closer look at some of the most common causes of a compromised Drupal website due to the vulnerabilities exposed.
Drupal Access Bypass
A Drupal Access Bypass can lead users to access resources that are not intended for them. The last such vulnerability was dubbed SA-CONTRIB-2018-081. The cause is a Drupal module named JSON: API 8.x-1.x module for Drupal 8.x. It is mainly used for:
- Access Drupal content and configuration entities.
- Management of Drupal content and configuration entities.
In this case, it does not carefully check permissions while responding to some requests. This can allow malicious actors with insufficient authorization to obtain sensitive information. Therefore, only GET requests can be used for this type of attack.
Drupal SQL injection
Drupal SQLi vulnerabilities are often found in poorly coded modules. However, an SQLi in the kernel is quite rare and dangerous. One such dangerous flaw was “Drupalgeddon”, although Drupal used PDO (PHP Data Object) to separate a static SQL query and dynamic values.
$ query = $ db-> prepare ("SELECT * FROM users WHERE user =: user AND password =: password");
$ account = $ query-> execute (array (': user' => $ _POST ['user'], ': password' => $ _POST ['password']));
Everything looks fine because the entry is properly cleaned up before it reaches the database. The bone of contention, however, was in Drupal’s placeholder tables. They were aimed at giving flexibility to module developers, as they allowed dynamically changing the structure of database queries.
db_query ("SELECT * FROM {node} WHERE nid IN (: nids)", array (': nids' => array (13, 42, 144)));
Thereafter, the placeholder: nests would correspond to the number of arguments provided. Like that:
SELECT * FROM {node} WHERE nid IN (: nids_0 ,: nids_1 ,: nids_2)
This functionality combined with PHP indexed arrays could be used to pass parameters such as (GET, POST and cookies). Drupal placeholder arrays would by default assume that the $ _POST [‘user’] parameter is an array. Subsequently, it would use the raw array string indexes to generate the new placeholder names. As a result, the attacker can provide malicious values such as Parameter: user [0 #], Value: foo. The resulting query would be:
SELECT * FROM {users} WHERE user =: user_0 #
Thus, the attacker successfully bypasses the login authentication. Moreover, the attacker can even create new users by editing the parameter as user [0; INSERT IN THE user VALUES “MalUser”, “Passw0rd!”, “Administrators”; #]. This was a very critical flaw as it affected the core of Drupal. What is more alarming is that a Metasploit module has also been released to exploit it!
Also Read – SQL injection – How to Fix & Prevent SQLi Hack
Drupal remote code execution
Drupal security has been haunted by a series of Drupalgeddon bugs. Drupalgeddon 3 is the last one found this year. This allows unauthenticated users to run code on Drupal sites. Although Drupalgeddon 2 also allows RCE. However, to exploit this, the attacker needed the ability to drop a node. The full URL looked like this:
PUBLISH /? Q = node / 99 / delete & destination = node? Q [% 2523] [] = passthru% 26q [% 2523type] = markup% 26q [% 2523markup] = whoami HTTP / 1.1 [...] form_id = node_delete_confirm & _triggering_element_name = form_id & form_token = [CSRF-TOKEN]
Here, under the pretext of deleting a node, the attacker injected the whoami command. The second line of code is to verify the CSRF token. Essentially, a CSRF token checks if the request was generated on the same server. Subsequently, the attacker gets the form_build_id of the response as shown in the code below:
POST / drupal /? Q = file / ajax / actions / cancel /% 23options / path / [FORM_BUILD_ID] HTTP / 1.1 [...] form_build_id = [FORM_BUILD_ID]
This finally triggers the exploit and the output of the Whoami command is displayed. Therefore, the attacker can execute all kinds of commands to manipulate the server. What makes this RCE bug more serious is that the exploit has already been released!
Also Read – Remote & Local File Inclusion Vulnerability
Drupal Cross-Site Scripting
Vulnerabilities such as XSS and SQLi are quite common in Drupal modules. The last in this series is SA-CONTRIB-2018-080.
The E-Sign module has been found to be vulnerable to XSS. The E-Sign module essentially allows you to integrate Signature Pad into Drupal. As of this writing, approximately 875 sites are using this add-on.
The vulnerability is caused by the failure to clean up entries when a signature is displayed. Thus, the attacker can test XSS using the code <script> alert (‘XSS Found!’) </script>.
The vulnerable signature field would then spit out the message “XSS Found!”. This vulnerability can then be used by the attacker to:
- Redirect users also called Drupal site redirect hack
- Steal user cookies.
- Download malware onto the end user’s device while visiting the Drupal site.
Before we move onto fixing a hacked drupal site, you must have these tools in your toolbox.
Also Read – XSS Cros site scripting Attack – Exploit & Protection
Tools & Resources To Fix Hacked Drupal
Other tools to scan your hacked Drupal site website:
Drupal Backup Docs or look into free Drupal backup tools such as Backup and Migrate and a Node Squirrel.
Download the same version of known good core files from the version official Drupal repository.
manually updating core files, follow the official upgrade docs for Drupal 8 and Drupal 7.
We recommend reviewing the Drupal Security Docs to learn how.
Drupal protection resources:
- Security Review: Test your site against a checklist of common security issues.
- Paranoia: Prevents PHP code execution in certain areas and prevents risky permissions being granted.
- Password Policy: Define user password policies and strength requirements.
- TFA: Adds another layer to password security using two-factor authentication options.
- HoneyPot: Protects your login and web forms from being submitted by malicious bots.
- Automated Logout: Test your site against a checklist of common security issues.
- Login Security: Limit login attempts and whitelist access using allowed IP addresses.
- Spam Span: Obfuscates email addresses to stop spammers from abusing them.
- Encrypt: Enables encrypted communication allowing modules to keep data secured.
- Real AES: An authenticated encryption method plugin for the Encrypt module.
- Key: A module that allows other modules to encrypt, filter, and validate data.
- Lockr: Secure, offsite storage and management of API and encryption keys.
- Site Audit: Enables encrypted communication allowing modules to keep data secured.
- Site Audit: Detect common problems with Drupal including security issues.
- Permissions Lock: Fine-tune user roles and ability to grant permissions.
- Secure Permissions: Enforces permission management via code instead of UI.
- Mass Password Reset: Force password resets for users if they are lost or stolen.
- Guardr: Distribution modules and settings for enterprise security.
How to clean a hacked Drupal site?
Your site has been hacked, you are now sure! What to do?
- You choose to restore your site to a previous state and in good working order (thanks to the backup ). And this is possible only if you have a clean and recent backup.
- You just fix the site by analyzing the security breach. How and where did the hackers manage to infiltrate the site? You then proceed to correct the flaw.
- you go through all the possibilities that hackers could use to compromise your site and you try to maximize the security of the latter.
- You plan to redesign your site (which does not prevent you from having to recover your files and your data).
- One thing is certain: we must act quickly. Here are some best practices to save your Drupal site from getting hacked.
Quick Steps To fix Drupal redirect hack
- Look out for malware code in these drupal directories
- ./sites/all/modules/panels/help/
- ./sites/all/themes/
- ./profilesc
- Create a back-up for all the files supporting your web application.
- Delete core: all the files other than /sites folder
- Re-upload Drupal’s core code
- Delete and re-upload themes, plugins, modules supporting the application 5.Upload your database back-up (pre-hack)
- Run update.php
The main goal is to clean up your site and prevent further hacks. For this, several methodologies are possible to manage this crisis, but you can start on the basis of this one:
Restore hacked site – Analyze & plan
This phase should allow all actions to be put in place so that none of them are forgotten. It is about documenting:
- All problems encountered and abnormal activity on your site.
- The procedure involving all the steps to remove malware and restore the site. Note that it is better to plan a standard methodology before a hacking situation arises in order to be prepared and save time.
- The preventive security measures to be put in place and executed to prevent such a scenario from happening again. To be effective, this initiative must also be thought out upstream to prevent piracy. However, if the hack has already occurred, this phase remains essential to provide preventive security precautions in order to minimize the risks of a renewal of any attack.
Make a full copy of your Drupal site
Before starting an analysis of how your site was hacked, it is imperative to make a copy of all files, the database and the system environment. You can use external storage media for these copies and store them offsite.
As you browse the files, be sure to check for viruses and malware that need to be cleaned. Feel free to create new backups and store them in a different directory. These backups will make it possible to have versions of the site before your cleaning intervention.
So, if you made something worse or broken by wanting to debug, you can go back and undo the changes.
Notify your host that the Drupal site has been hacked
The best is to notify your host as soon as possible. This will allow them to start scanning their own systems and help you in the process of recovering and securing the site.
Scan the servers and the PC to detect contaminated files
Before changing the password of your site, it is necessary to ascertain the origin of the hack. Did this infect the servers or the computer, or both? Several anti-malware and anti-virus tools exist to detect this, like AVG, BitDefender, Malwarebytes, etc.
Consider taking your site offline while the flaw is corrected.
It all depends on the type of site and the number of visitors to it. If it is an e-commerce site, it is imperative to take the site offline to prevent malware and spam from spreading & to safeguard sensitive user data ( payment methods, etc.) Be careful Drupal “Maintenance mode” is not the same as “Offline mode”, as long as your site is online, malware continues to spread.
Close all possible access for hackers
Just cleaning up programs, code, and malware isn’t enough. It is imperative to close all possible access doors to avoid new hacks. Where to look? Here are some elements that must be monitored to optimize security:
- Access logs: this involves checking the PHP scripts and POST requests added to the directory.
- it is advisable to check all the payment methods, the delivery addresses, the linked accounts as well as the suspicious data recently added.
Passwords: it is imperative to verify/modify FTP passwords, administrator passwords, etc.
- E-mail rules and filters: it is recommended to check whether the e-mail has been secured, in particular with complex answers to security questions. An email compliance scan is also useful to check if an unwanted email address is present in the mailbox.
Investigate the attack and identify the source
Now you need to audit your site. You can perform the inspection directly on the infected site version if you do not have a recent backup. Otherwise, it is possible to do a comparative analysis with a test or pre-production environment.
That version is recent enough to compare the code with the version of the online site. In this way, you will be able to track down infected files, malware present on the site, and unauthorized settings. Where to look? Several places need to be carefully inspected:
- .Php files and .html files;
- The session tables;
- Newly created or modified files;
- New or recently updated user accounts;
- The directories;
- The database.
Check Modifed Files
Often, the backdoors infecting your Drupal site may modify the Drupal core files. File modification of Drupal site can be checked by the following steps:
Connect to your Drupal site via SSH.
Create a new directory using this command:
mkdir drupal-y.x.
Replace ‘y’ with your Drupal series i.e. 7,8,9. and replace ‘x’ with your Drupal release i.e. 4.7.1, 2.1.3, etc.
Navigate to that directory using the command:
- cd drupal-y.x
- Download a fresh copy of your Drupal version by the command:
- wget https://github.com/drupal/core/archive/y.x.tar.gz
Now, extract the tar.gz file using the command:
- tar -zxvf core-y.x.tar.gz
- Finally compare the difference between core files by the command:
- diff -r core-y.x ./public_html
- Alternatively, this can also be done by logging into the site via SSH and running the following command:
- find ./ -type f -mtime -20
This command will list all the files modified in the last 20 days. Check the modified dates of the files and if there is anything suspicious, scan that file for malware.
Remove Hidden Backdoors
You will find multiple backdoors of various types in hacked Drupal sites. Backdoors are injected into files like index.php and directories like /modules, /themes, /sites/all/modules, and /sites/all/themes.
Backdoors commonly include the following PHP functions:
- Log into your database admin panel.
- base64
- str_rot13
- gzuncompress
- gzinflate
- eval base64
- exec
- create_function
- location.href
- curl_exec
- stream
Restore the Drupal site
Once you have detected and cleaned up all the malicious code, it is time to restore your Drupal site by repairing all the damage done! Three main options are possible:
- If you have a clean and recent backup: this is ideal! You can restore your site. It is imperative to be sure of the date and time of the hack to restore an earlier version. However, it will be essential to put in place a regular preventive maintenance action.
- You don’t have a recent version, you don’t know the date and time of the hack, then you have to consider the option of redesigning the Drupal site.
Check User Logs
User logs can help you identify any suspicious logging into your site by the hackers. To do so:
- Login to the Administrative page of your Drupal site.
- From the Menu, Click on the option ‘People’
- Review the users present in this list and also see the ‘Last Access Time’ of every user. If you find any suspicious logins, proceed to find the vulnerability in your site.
Disable Drupal Backdoors
Drupal backdoors can be found hidden in folders like: /modules, /themes, /sites/all/modules, and /sites/all/themes. Detecting them is not easy as often the code may be obfuscated. To find such code, follow the steps mentioned above in “Clean Infected Files and Remove Obfuscated Code”. Also, these backdoors use certain PHP functions.
- To disable those functions, follow these steps:
- Log in to your site and open the file manager.
- Browse and open the php.ini file.
- Add the following code to that file:
- disable_functions = “show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen, eval”
- Clean Drupal Database
The Drupal database is often targeted by malware. To clean the database of your infected Drupal site, follow these steps:
- Log into your Drupal site via the Administrator panel.
- Navigate to Data Access>Drupal Database
- Here, in the search bar, search for the suspicious links or content visible during malware scans.
- Open the table that contains those spammy contents and links. Thereafter, manually remove the content.
- When done, verify if the site is still working and remove any other database management tools.
- Here, in the search bar, search for the suspicious links or content visible during malware scans.
- Open the table that contains those spammy contents and links. Thereafter, manually remove the content.
- When done, verify if the site is still working and remove any other database management tools.
Take extra precautions on user data management
It is about putting in place preventive security measures to minimize the risks of a new hack. Several means are possible:
- Set up an SSL certificate to secure data exchange;
- Regularly carry out preventive maintenance operations (upgraded version of Core and contributed modules);
- Perform regular site backups;
- Check log files again to see if user data has been copied, modified or downloaded;
- Encrypt connections to services used for sending confidential user data.
One last check before uploading
Your site is now cleaned and restored, but a final audit is recommended before putting it online to be sure that no malicious code persists . Make sure that preventive security measures have been applied to avoid a new episode!
- Install security patches that will mend several Drupal weaknesses
- Root out and delete all vulnerable scripts in your Administrative area.
- Boost security to ensure your hosting/ftp/admin passwords are secure
- Install our Custom Site Lock Script –
Conclusion
The process of recovering your site can be long and tedious. To avoid getting your drupal website hacked with malware in 2020-2021, one of the only ways is to take the security of your Drupal site seriously by providing preventive security measures.
You must Perform Drupal security updates, plan regular backups of your site, stay on top of alerts sent by the Drupal community, have a maintenance service center or get in touch with web security experts like WP Hacked Help, We take web security seriously. Apart from cleaning up hacked drupal site we fix hacked wordpress sites, hacked prestashop sites, hacked shopify sites & woocommerce hacked. Get in touch with us today. prevention is better than cure!