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.

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.

We look for each trace where the attack left it.

  1. Database

    On Drupal 7 we check menu_router: a callback to file_put_contents, assert or similar functions is a critical alert.

  2. Files

    PHP in sites/default/files, a changed protection .htaccess, signatures like the Coinhive miner injected into misc/jquery.once.js.

  3. Accounts

    Every new administrator, even one created straight in the database, shows up at the next sync.

Want to try it on a real site? The 30-day trial needs no credit card.

Start free trial

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.

Try it on your clients' sites.

Connect your first sites today and see what SitePing finds on them.

  • Every Complete feature except backups
  • Up to 10 sites
  • No credit card needed to start
  • At the end you choose a plan or move to Free, and nothing is charged
Start the 30-day trial

Already have an account? Log in. Prefer to look at one site first? Free read-only audit.