In April/May about five of my Drupal websites were hacked, and I thought I would write a short guide based on what I did to clean and restore the sites.
The Drupal security team released two security advisories in March and April for two highly critical exploits (Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-004 and Drupal core - Moderately critical - Cross Site Scripting - SA-CORE-2018-003) which required Drupal to be updated to the latest version as soon as possible. I have many Drupal sites that I look after and was a little bit complacent in taking my time to update all of them to the latest Drupal version. I had had some sites hacked before, but usually they were WordPress sites, and I didn't realise how critical the vulnerabilities were. The result was that I had about five sites that were hacked before I had had a chance to look at them.
One of the sites was then blacklisted by Google, but for the other four it was difficult to tell from just looking at them that they had actually been hacked, you could only tell from scanning the files and seeing that various malicious files had been uploaded. For two of the sites, the hosting provider suspended them until they had been cleaned as they ran daily scans for suspicious files.
How can I tell if my site has been hacked?
It may be that, if you have a decent host, they will be scanning your website on a daily basis for suspicious files. If they find any they will either immediately alert you, or if they think they are sufficiently dangerous may suspend your site, which is really the best thing to do to prevent any further hacking and to prevent harmful content being downloaded onto unsuspecting users' computers.
It can be that from looking at the site you would not know that it had been hacked, as it will appear to function completely normally. The best way to tell if it has been hacked is to see if there are any files in the web folders which should not be there. These will frequently be "php" files but may also include files ending ".ico" or ".listing". For my sites that had been hacked, they included all of these files, "php", "ico" and ".listing" files. I also had many index.php files in multiple directories, when in fact in Drupal there should only be one index.php file in the root directory. You can also tell by editing any of these suspicious files because normally the code will not be plain code but use sequences of letters and numbers that do not appear to make any sense.
Quick Tips:
Use git to create a repository of your site, that way once you have cleaned it you can always restore that version just like a backup using the commands:
$ git clean -f //removes unindexed files
$ git checkout . //Overwrites all your files with the saved version from the repository
You can also use git status to quickly and easily check if any unauthorised files have been uploaded or any existing files have been modified
If your site gets hacked after being cleaned, you may be able to find the route the hackers took to get back in again by running the bash command $ stat <filename> on one of the files that were modified or uploaded. This tells you exactly when they uploaded the file, and you can then check the website access logs to see what files were accessed just previous to that point, which will probably be the files the hackers used to get back in again. You can then remove those files.
How can I clean or restore my site if it has been hacked?
The safest and best way to make sure your site is clean once it has been hacked, is by restoring all the files of the website from a backup that existed before the hack took place, as well as restoring the database from a backup that was created before the hack took place. Once all the files and the database have been restored, then you need to immediately update the files and database to the latest Drupal release. I was able to do this for two of my sites, but unfortunately for the other three I either had no database backup or no file backup or neither! This was rather careless of me and I have since put in daily backup procedures for all my Drupal sites.
Many Drupal developers say that if you are unable to restore a clean backup then you need to scrap the whole site and start all over again. However for many sites, this is simply not possible because of budget constraints. And as a site developer working for many small to medium sized organisations, I feel a responsibility to restore their site without having to scrap them and start again. In my experience, many times when a site has been hacked, it is not the end of the world and the site is recoverable if you are careful and methodical in cleaning the site. this also very much depends on the depth of the hack. For many hacks it may be that they are not that extensive and so as long as they are cleaned fairly quickly it is possible to repair the damage and prevent further hacking.
What are the steps I need to take to clean my site?
The steps I am outlining are based on a Drupal 7 site though the principles can be applied to Drupal 8 or even WordPress.
Before beginning any cleaning, it is important to back up the whole site and the database which you can restore in case anything goes wrong.
Tip: you can use git to create a repository of your site. This will mean it will be easy, as you make any modifications to the site to simply log those changes in the repository (.git). using git also has a great advantage in that once you have cleaned your site it will be very straightforward to see if the hackers have uploaded any more files by simply running "git status", as this will list any newly uploaded or modified files.
It is also much easier if you have SSH access to the site and phpmyadmin access to the database.
Check the list of users and block any that you do not recognise, particularly if they have admin or other high role access- Check if any new roles have been created and delete them if they have
- As a precaution, you should change the database password, as well as the passwords for any Drupal users with high-level access. Also check that none of the email addresses for the high-level Drupal users have been changed.
- Upgrade Drupal to the latest version. Do this by deleting the following folders in the web root: includes, misc, modules, profiles, scripts and themes (see the diagram opposite).
- Delete all the individual files in the root folder unless they are custom files for your site.
- Upload all the folders you have just deleted and the root individual files from a clean download from Drupal for the latest release
- Update the database by running update.php from the web root (you need to login to your site and then go to www.mysite.com/update.php, and follow the instructions)
Now you know that all those folders are clean and you can focus on the sites folder which is going to be different for each site and cannot be simply overwritten, otherwise you will lose any custom themes or authentic uploaded files as well as any custom modules that have been installed.
The sites folder contains any files that have been uploaded to the site, particularly images or documents as well as holding the custom themes, modules and libraries.
- For the custom modules and libraries it is best to download fresh copies of all of them after deleting your existing ones.
Downloading fresh copies of modules may be problematic if you have a lot of them and your modules were not up to date so it would mean either updating your modules to the latest version or downloading the versions that match the ones that you have. Sometimes updating your modules is probably a good idea anyway. Alternatively, you can install the Hacked! module which scans all your custom modules to see if there are any unauthorised files all codes changes which do not match the official module release.
Once you have cleaned your modules and libraries folders you now only have your themes folders and default files folders to clean.
- Update the database again by running update.php if you updated any of the custom modules with newer versions
- If you are using a sub theme, download any fresh copies of base themes you have to replace existing base themes. For instance, if you are using the bootstrap sub theme, you can delete the base theme and download it again.
- Now you will need to scan the remaining folders (which will be the default folder and the custom theme folder if you have one) that have not been replaced looking for unauthorised ".php", "*.ico" or ".listing" files and remove them. This can be done if you have logged in via SSH, by going to the folder or subfolders you want to search and simply typing in
'find -name "*.php"'. It is straightforward to check for PHP files in the files folder (sites/default/files), as there shouldn't be any at all, so you can remove any that you find. It should also be straightforward to check for PHP files in your sub theme, as the only PHP files there should be the template.php, theme-settings.php and any other overriding template files that will include end .tpl.php. - Following these steps should have removed all the hackers files from the website. However, it is possible they may also have inserted some code into the database. This happened on one of my sites where a script was inserted at the bottom of every piece of content. the easiest way to search for malicious code in the database is by doing a database export. the way I usually do this is by using phpmyadmin by following these steps:
- There should be a link to phpmyadmin from your hosting control panel.
- In phpmyadmin, select the database for the website, and then click on the export tab and export all the tables using the default option (into sql).
- This will then download the SQL file onto your computer which you can open in a text editor.
- Once you have opened it in the text editor you can then do a search for both "<script>" and "<?php".
- In some cases there may be valid occurrences of both of these strings, but you should be able to tell which ones are valid and which ones are not.
- If you find any suspicious occurrences, you should be able to tell whether they are in a block or a piece of content, and then you can login to the website and either delete the block where it is or remove those sections from the content where you have found it.
- Lastly, do a fresh backup of your site, so you have a clean copy, or if you have set up a git repository for it, update the repository. You also need to do a fresh backup of the database.
- For the next few days check to see if any more unauthorised files are uploaded - use "git status", if you are using get to track your website files.
What to do if the site gets hacked again soon after you have cleaned it?
This basically means there is still some code that the hackers are using to get back into the website which you did not find the first time. There is a way though, that you can identify what method the hackers used to gain entry into your site again. To do this, do not remove any of the files that have been uploaded; login to the hosting using SSH, navigate to the folder where one of their uploaded files are, and then you can run the following command:
$ stat <hacked_file.php>
Running this command will give the following kind of output:
Size: 161 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 39862334 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 634/ragnbone) Gid: ( 629/ragnbone)
Access: 2018-05-23 13:48:13.503005987 +0100
Modify: 2017-10-24 14:17:04.868686974 +0100
Change: 2017-10-24 14:17:04.868686974 +0100
Running the stat command on a file gives you the date it was last accessed, modified and changed, in other words it tells you exactly when the hackers uploaded the file onto your site. You can then use this information and look at your access logs for the website. The access log is a log of all the files that were accessed on your web space with details of the file that was accessed and other information about the date and time and details of the user that accessed it. This log should be available from your control panel. If you look for exactly the time just before they uploaded that file which should show you what files were accessed immediately before they uploaded the file. This will show you what other files they were using already in the website to get entry to the site. You can then remove those other files from your site.
Disclaimer
There is no guarantee that even if you follow these steps your site will not continue to be hacked, as it is quite possible that the hackers have left other avenues through which they can access the site, or have been able to hack into the cPanel itself, but in my case for my five sites these steps did work.
References and thanks
In helping me to both clean my sites and inform this article, the following links were very helpful:
Deleting user account on my drupal website
Drupal ico file hack, index.php hack
Drupal SA-CORE-2014-005 - How to tell if my server / sites were compromised?
Monitoring Changes to Files via a Cron Job
Thanks also to my website hosts Clook, for their support in helping to identify suspicious files and showing how to identify what routes hackers used to get back into the site.
- Log in to post comments