I have a situation where I am faced with two sites which were vulnerable to the Drupageddon SQL injection exploit. I am looking at what is the best strategy for recovering these websites. Given that the sites were not patched within the alloted window of time, I am forced to assume they have been compromised.

There is a lot of information on what to do after one's Drupal site has been hacked; but one question that is not really addressed is the workflow for recovering content from the compromised site.

In the case of one site, no pre-exploit database backup is available. For the other website, there is a pre-exploit database backup; however, there is a large amount of post exploit content which has been created/updated.

What would be the workflow for recovering content (other than recreating everything by hand). Issues I can think of are:

  • How to clean up existing content?
  • What tools to use to achieve this?
  • How to get the content out of the old site and into the rebuilt one?
  • If site is being rebuild from previous DB backup does it make sense to try to only import content which has changed or been added since previous backup? or does it make more sense just to re-import everything?
  • How to recover site configuration? Would it be possible to create features and then 'clean' them before installing into rebuilt site?

4 Answers 4


I have never used this module, but it might be worth researching and using on a COPY of your site - Drupalgeddon module.

The first step to recovering from a hacked site is to do an audit of the activity that has taken place. If you have HTTP server logs (apache access logs, etc) you can review the various attack vectors (e.g. POST /node/add, POST /node/3/edit) to identify areas that were compromised. Based on this activity you can formulate a time window when the attacks occurred and search for content edits within that (e.g. checking the "changed" date on the node table). I do know Drupalgeddon does modify records in the users table, so definitely check that.

Either way I think a full audit of the entire database and file-system (pretty sure Drupalgeddon does write to your docroot; hope you have version control to see changes?).

  • From everything I have read, it seems that with Drapalgeddon vulnerability there is no reliable way of confirming if the site has been compromised or not. But my main question I have here is what is the workflow for recovering "content" from compromised site. Is there a process for vetting content from a compromised site (e.g. export and then search for embedded php or JS code) or does one have to rebuild all content by hand?
    – Benjen
    Commented Mar 30, 2015 at 2:35
  • Recreating content by hand vs. vetting content depends on the length of the content. If the content is short enough, it might be quicker to recreate it by hand. What I typically do is scan content for suspicious "src" attribute values and embedded javascript blocks.
    – blazindrop
    Commented Mar 30, 2015 at 2:39

Base on what I have read about "Drupalgeddon SQL injection exploit" the best way to be 100% sure that your website is not vulnerable is to go a old back which you are sure that is not been hack. Ideally it would be anytime before the 7.34 release.

  • 4
    OP's first bullet point is: "No pre-Drupalgeddon database backup is available." Commented Mar 30, 2015 at 4:17
  • Start a new site
  • Use a new clean drupal and download all needed modules which are used in the old site.
  • Setup feeds for every cType from old site to new site. Depending on volume add a manual check of every batch of XX pieces. Check all content after the exploit.
  • Re-import everything is the safest way.
  • check the roles of all acccounts manually. If they are oke the are within the your wanted restrictions.
  • Personally i would do the site configuration by hand but that's depending on how big/small the site is. It is the safest way.

I also used the module Hacked. It gives a indication not more.

  • 1
    Thanks for your answer. Would be interested to know how would one actually go about checking the content types? In addition, how should users and other things like taxonomy, views, blocks be sanitized and imported into rebuilt site?
    – Benjen
    Commented Apr 15, 2015 at 1:22

First of all, keep in mind that the sql injection vulnerability does not only involve possible compromised content; for example an attacker may have benefit from this exploit in order to log in as user with uid 1 (or create a new user with advanced privileges), thus gaining the possibility to alter content, structure (views, menus, taxonomies, panels e.t.c) and even upload/inject malicious php code (and of course execute it). It is good that you assume the worst case scenario of your sites being compromised, but I would first advice you to actually check/look for confirmation (possible compromisations and their extent) before acting.

How? Unfortunately, mainly manually. Here is a list of some things you should check out first. Then I would personally check the server access logs (using log analyzer software depending on your web server) and Drupal logs (watchdog) for suspicious actions of any kind (e.g. user creation/edits, content deletions/edits, structure alterations in views/panels/CTs). Then, Hacked module, will help you identify any code changes. You might want to skip this step, but answers to these questions and acquiring a general overview of the server/site status will affect the decision/strategy on how to rebuild/clean up your sites:

You are talking about re-building your sites. In the first case you will use the available pre-exploit database backup. OK, this will make sure that content/configurations/structural elements are reverted back to their original state. What about the code? Drupal core, contributed/custom modules? You will use the current live one(s)? Are you sure they are 'clean' and malicious-code-free? What if they are compromised as well? This is why the damage assessment step is highly important. Only after ensuring that your 're-built' (up to the restore point) is safe then you should worry about the additional content missing from the backup. And this gets even harder for the second case - the second website for which no backup is available.

The reason that documentation is missing a data restore/clean up plan, is that simply there is not an optimal plan/solution for all usecases. And the complexity increases if you think the endless ways an attacker might have compromised a site; for a news site for example an attacker (having gained access to a user's account) may have edited an article and changed the original author's opinion or the presented facts (looks like a legitimate edit, no spamming or weird markup, thus it is very difficult to spot). However, there are plenty of tools, modules and processes that can be used to address similar situations/problems.

I would be more than happy to help you compile a recovery strategy, but I need more feedback:

  • Were you involved in the development phase of those sites? (as manual checks might be needed, it is preferable if you have a general idea on how the sites are supposed to operate by design and prior to any possible alterations)
  • How big/small your sites are? How many CTs? How many fields each? How many instances/nodes in total? Taxonomies? Views? Panels? Webforms?
  • Have you been using Features when building those?
  • Is code versioned (e.g. git, subversion)?
  • Do you have development environments set up for those sites/projects? Are those up to date/synced with their current production versions?
  • During the sites' lifecycles, if any additional structural changes were necessary (e.g. change the configuration of a view, add an extra field to a CT), how those were performed? Directly in the live site? Or they were performed/tested in a staging/development environment first?
  • Have you created/implemented any custom modules for those sites? Custom themes?
  • Thanks for the detailed reply. I can appreciate there is no one-size-fits-all solution. for that reason I was more interested options for recovering content and configuration. As I see it, content is exportable, as is configuration (via features). I guess I am kind of fixated on the idea that one could either manually (or automatically) scan such data and then sanitize it. For example, manually remove suspicious code from exported features. If reviewing manually what does on look for? What tools could be used instead?
    – Benjen
    Commented Apr 16, 2015 at 2:07
  • Perhaps this is a issue too big for stack exchange. Would be great to have a Drupal doc page dedicated to this. I originally posted to here out of desperation as I have not been able to find any information about the options/techniques available for this kind of thing.
    – Benjen
    Commented Apr 16, 2015 at 2:10

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.