Drupalgeddon
Detecting Drupalgeddon and Drupalgeddon2 backdoors on Drupal sites
Drupalgeddon (October 2014) and Drupalgeddon2 (March 2018) were large automated attacks. Many sites hit back then were never fully cleaned, and the same techniques are still in use.
The problem
Backdoors stay after the update.
Updating Drupal closes the hole, it does not remove what the attacker already left. drupal.org's PSA-2014-003 was clear: sites not updated within hours had to be treated as compromised.
The traces sit in different places: a database row, an extra user, a PHP file among the images, a few lines at the end of a core JavaScript file.
How it works
We look for each trace where the attack left it.
- 1
Database
On Drupal 7 we check
menu_router: a callback tofile_put_contents,assertor similar functions is a critical alert. - 2
Files
PHP in
sites/default/files, a changed protection.htaccess, signatures like the Coinhive miner injected intomisc/jquery.once.js. - 3
Accounts
Every new administrator, even one created straight in the database, shows up at the next sync.
In detail
Tested with inert samples.
- A
menu_routerrow with the structure of the 2014 backdoor, on a path nobody requests - A commented Coinhive miner appended to a core script, also caught by the integrity check
- A PHP dropper and a
.php.jpgfile in the public files folder - Critical alert even when the infection was there at the first scan
- No sample runs code or contacts real domains
FAQ
Frequently asked questions
Do you find every malware variant?
No. Signatures look for documented structures of real incidents. A match always needs checking, and core integrity covers changes signatures do not know.
Does the menu_router check apply to Drupal 8 and later?
No, routing changed in Drupal 8. There, core integrity, suspicious files and new administrators matter.
Related features
Goes well with
Try it on your clients' sites.
During the beta we let in a few agencies at a time and set up the first sites with you.