Welcome to the third post in our Drupalgeddon 2 series! This series of blog posts are intended to give Drupal site administrators and agencies guidance and advice on what to do following exploitation due to vulnerabilities discovered as part of Drupalgeddon 2.

For clarity, Drupalgeddon 2 is the term being used across the web to describe the recent vulnerabilities in the Drupal 6, 7 and 8 platforms.

These vulnerabilities have caused widespread chaos over the entire web; not least because many of the world’s largest and most important organizations use Drupal as their public-facing content management system of choice — namely for their official websites.

Our advice is provided by a world-class team of web development and server security experts based in the UK and addresses common questions we have received, after the monster known as Drupalgeddon 2 begun.

In this post, we’ll discuss some of the most common symptoms reported by Drupal site administrators who have experienced a breached Drupal 6, 7 or 8 website due to the vulnerabilities that were recently discovered, being termed Drupalgeddon 2.

We’ve put together a simple, concise list of signs and symptoms that Drupal site admins and agencies should look for to quickly identify a hacked Drupal site.

Bear in mind, however, that the presence of the signs is not a 100% surefire indication of a breach, and nor should you assume that your website has not been compromised simply due to a lack of any of the common symptoms below.

Attackers are getting cleverer by the day, and many Drupal sites, particularly those who are targeted individually, rather than attacked by malicious botnets, may not display any signs of a successful breach at all - which is something you have to be super careful of.

In fact, we wrote another blog post on this specific issue, as part of our Drupalgeddon 2 series which you can find here.

So, let's begin to explore some common signs of a compromised Drupal site:

The Drupal Site is Defaced

In other words, it’s fairly evident that the installation has been compromised, because your ordinary content is not displaying as it should. You may see additional content added to pages, content or images that is either modified or removed, or less often, simply a splash page left by the attacker indicating that the site has been compromised.

Cannot Login Using Normal Admin Credentials?

If you’re unable to login to your site using your regular Drupal administrator login credentials, you’re in for trouble. Before you let the panic set in, take a quick breather and ensure you’re entering the correct administrator login details, and in the correct case. Remember, Drupal usernames are not case sensitive, but passwords certainly are.

New Admin Users? Yep, that's a Hack

If you are still able to login to your Drupal administrator account, you may find that new users have been created.

If your website does not accept anonymous registrations, then, of course, this is a big problem and a sign of trouble.

If your site does accept anonymous user registrations, however, you will need to look out for any new (or old) users who may have been assigned the default administrator role, or a new role which you did not create.

Sometimes the new role can be named something obscure, such as ‘config’, or ‘admins’, but it could also be something ridiculous such as a random string of characters, or simply ‘hacker’, or the hacking organization’s name.

New Roles Which You Did Not Create

Again, expanding on the point above, if you’re able to identify new user roles which you did not create, potentially with obscure names as exampled above, there’s something to be worried about.

New Files in the Drupal Installation

If you’re able to identify files present in the Drupal root and subdirectories that were not placed there by you, it’s pretty much a surefire sign your installation has been compromised.

Common files placed in the Drupal root directory may either be named obscurely or something such as ‘index2.php’, ‘1ndex.php’, etc.

Also, look out for more common files placed by attackers, such as ‘payload.php’, which is a particularly nasty one, and again, a surefire way to tell your site has been subject to a significant breach.

Keep a look out for files placed in other subdirectories inside the Drupal installation, as this is likely where an attacker will have placed ‘backdoors’, which are easy entry points for them to re-infect the site once you’ve cleaned it out.

Google’s Your Friend

Notification from Google Search Console (formerly known as Google Webmaster Tools) regarding an additional user being added as a property owner, which is a change you did not make yourself.

Sometimes, attackers will add themselves as property owners to your Google Search Console, in order to upload obscure sitemaps linking to non-existent or maliciously injected pages on your Drupal site.

The White (or Black, or Blue, or Whatever Color at All) Screen of Death

If your website is entirely inaccessible, meaning that you cannot see anything when trying to load the website, there is a chance that the site has been compromised.

Of course, there are a multitude of reasons why the white (or colored) screen of death may occur, but if you’re able to rule out other possibilities, there is a chance of a breach.

You’ll have to investigate further to see whether you can identify any further symptoms of an attack before declaring the site officially compromised, though, as it could be a simple server error or overloaded server.

Another symptom is that the website may seem as if it’s trying to load something, but ultimately nothing actually appears and the page loading times out.

An Inability to Access Your Control Panels

Okay, in this case, your problem is likely larger than you thought.

Because this was such a dangerous vulnerability, it’s possible that the attacker could have escalated their server privileges and gained access to cPanel/Plesk/SSH, or your web hosting control panel, particularly if you use the same password (or an insecure password) for your accounts.

Strange Images or Text Appearing on the Site

This point builds on some of the previous ones above, but we think it’s important to reiterate — strange images, text, code or scripts that have been added to any of your website pages by someone other than yourself is a fairly indicative sign that Drupal has been compromised as part of Drupalgeddon 2.

Bizarre Redirects

One common feature of recently reported compromised Drupal sites, as a result of Drupalgeddon, is external linking or flat-out redirecting to other websites, which may be an attempt at the attacker trying to sell illegal products, or install malware on the user’s computer.

Phishing Warnings from Search Engines

A phishing warning from Google, Safari or Internet Explorer (or any other reputable browser) notifying the user that your site is not safe to visit is a scary position to be in.

This likely means that the attacker has installed some kind of malware on your server, or the search engine identifies some kind of content present on the page (such as code for an external redirect to a malicious website) which could be harmful to visitors.

Unusually Slow Load Times

If your site is taking a particularly unusual amount of time to load (let’s take a site which usually loads within 5 seconds, and now takes upwards of 30-60 seconds to load), there is a chance that either Drupal or the web server could be trying to load external resources that the offender has installed.

It could also be a sign that a PHP or SQL injection is being processed during the page load, which is bad news all-round.

Changes to Other Sites on Your Server

One of the features that makes this vulnerability particularly unique (and did we say dangerous?), is the fact that the attacker has the ability to compromise far more than solely the isolated Drupal installation itself.

In fact, they may even be able to drill down to the server-level and execute tasks which are outside of the Drupal installation entirely.

As such, if you’re hosting other sites, email addresses, or databases on the same server, even if they are not running Drupal, you may be up for a challenge — as these sites could very well have been compromised too.

Changes to the Server Configuration

The vulnerabilities exposed as part of Drupalgeddon 2 are rated by the Drupal Security Team as highly critical.

Essentially, the problem is so bad that changes can be made directly to the configuration of the server if an attacker is able to penetrate the application layer — Drupal.

If you’re noticing changes such as modifications to the directory structures outside the Drupal root, or changes to passwords or user groups and accounts which you haven’t made yourself, further investigation is definitely in order.

Altered Module Configuration

The enabling or disabling of modules which may, or may not, have already existed in your Drupal installation, is a pretty clear sign that the website has been altered by somebody other than yourself, who has gained elevated access to the site’s module configuration.

You need to be careful with modules, because even if none have been enabled or disabled as far as you can see, the attacker may have left entry-points, or ‘backdoors’, so investigating the state of each module may be imperative.

Changes to the Drupal Configuration

Attackers may occasionally make alterations to the configuration of the Drupal site itself, in order to gain access to what they are looking for, or fully accomplish the exploitation they are attempting to make.

Often times the configuration changes will be reverted by the offender, but sometimes, there may be traces left behind — particularly if the attack was targeted.