I work for a charity and look after our website built on Drupal 7. I missed the recent March alert and didn't update in time, and about 3 weeks ago we were hacked. Some (not all) users get redirected to a malware site.
Sadly our daily backups are only stored for a week (I didn't realise the host only stored a week) so I didn't have a clean backup to go back to. Lesson to myself is download them to my PC on a regular basis.
I went through the site and removed multiple index.php files and another other file that I did not recongise and thought I had cleaned it all up and updated, but what happen is they must have a backdoor because each night the index.php files are put back. I now have a clean backup which I restore each morning and the website is fine until midnight'ish when the backdoor is used.
I can't find the backdoor. I have done a fresh install of Drupal (7.5.9) and all module files, I have used a very old theme backup which should be clean but they still get back in. I am the only user on the website, the passwords for that account, database, FTP and even server have all been changed.
So I can only assume the backdoor is in the database? Is that likely to be the case or could it still be a file I am missing? If the database, I know how to use phpmyadmin and run SQL commands, but I am not technical enough to know how to find a recent database change or where the issue may be. Does anybody have any advice to clean up the existing site?
We were already building a new website and rewriting all text as it goes on a new server, so we can wipe everything and start again but that is still 2/3 weeks down the line. So I just need to do what I can to keep our existing site up for another couple of weeks.
Any helpful suggestions would be very much welcomed. Thank you.
Comments
There are several threads on
There are several threads on this so I will summarise my own contribution, writen elsewhere at greater length, briefly.
If there are other sites on the same server where the codebase is wrtiable by the web server, the backdoor is probably in all of them. That is standard practice among low-grade hackers.
The main problem you are looking for in the database is an admin user who does not show up under 'People.' On the sites I cleaned there were two hacker's users, one called Alex, one with a number. Look at the user table, especially the users with the highest user IDs, for users with admin permissions who should not be there.
Other hacks can appear in a database, both in the form of scripts in content which redirect a page or something like that, an in terms of bits of code which infect your codebase, such as file_put_contents
You should also ensure your codebase is not writable by the web server. If it is not, then unless the hacker has got elevated privileges (rare) they cannot infect your codebase. Documentation: https://www.drupal.org/node/244924 Of course the files/ folder needs to be writable. Files like index.php really should not be.
Clear out your /tmp directory.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Thanks for your reply John.
Thanks for your reply John. It was more of an informational portal so not an interactive website so there is only one user in the user table (makes it easy), so definitely no unauthorised users there just the main charity admin account.
One way of looking for odd
One way of looking for odd code in the database is to dump the database, and open it in a text editor and look through and search for odd things like <script> tags and code.
Anyway, make your code unwritable.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Consider filesystem backdoors
Consider filesystem backdoors and cron jobs.
The attacker may have been able to write a server-executable file (php) or browser-executable file (js) to an obscure but accessible location in the filesystem - so as mentioned, completely clean out your /tmp directory, and look very hard at all your public html and file directories, including the .htaccess files in those - a hacker may turn on php-parsing for any file extension via .htaccess and hide code as innocent-looking file extensions. Check where symlinks go, and any files and .htaccess files in the symlinked destinations.
Look for php or javascript tags in the database. Look for obfuscated code that may be interpreted (a backslash followed by hex, octal, decimal or ascii code. Drupal output filters should catch much of the javascript in field content but it is totally possible for bad theme code to pass unfiltered output through for execution.
If you are on hosting that runs the webserver under your unix account username (most shared/cloud hosted accounts), then the attacker may have installed a cron job that writes files to the filesystem, or manipulates the database - so the hack will reappear even if you find and delete it. Check your hosting control panel for suspicious cron jobs.
But if the attacker has managed to gain admin, webserver-user or root privileges you are basically screwed. Bottom line: rebuild the server environment as a new account, and rebuild the website from known-good sources. No fun, but the only way to be sure.
Like Ripley said: https://www.youtube.com/watch?v=uhfPyreR_sE