How to recover content/configuration from a hacked site 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?
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?).