What To Do When Google Says Your Drupal Site May Be Hacked

This one is always a fun fire drill. If you haven't setup Google Search Console (formerly Google Webmaster Tools) for your Drupal site, you get an email from a co-worker or customer that says something along the lines of "Someone said the site is showing up as hacked in Google!" You scramble and see it for yourself. "This site may be hacked." Shows up below your website's title in search results. Lovely.

If you did set up Search Console and you got a nice "there goes my morning" email bomb that says "Google has detected that some of your web pages have been hacked by a third party who may have created spammy or malicious content on your site..." Now what?

Thanks Google, but those steps seem a little daunting...

Before you do anything, I highly recommend taking a minute to communicate with your team, including upper management. They're going to find out about it one way or another. It's best to be proactive so when someone reports it to them, they'll be prepared. Let them know that 1.) You know about it and you're on it. 2.) This sort of thing is common and can usually be resolved quickly.

Time to get your hands dirty. If you're unfamiliar with Google Search Console, you need to familiarize yourself with it, as it is your key to resolving the problem. You can learn about it in their helpful guide "What is Search Console", or watch the explainer video below.

 

IFrame

 

The first thing to do is get into Search Console and follow the instructions to review the flagged content. If you don't have Search Console set up, now's your chance to make some time for it. Sign up and then verify that you own or control the website. For a high-level quick-start Drupal tutorial on site verification, check out the documentation on Drupal.org. For a detailed explanation from Google, visit their documentation on verifying ownership and also check out the video below. We recommend the metatag verification method as it is the easiest and doesn't require DNS changes so you can get it resolved faster.

 

IFrame

 

Once you're able to get into Search Console, you'll immediately be directed to a screen that looks like this:

Go visit each link and look for clues as to why the pages or files might be flagged. With Drupal, we've seen this issue a few times on high-traffic sites and all but once it's been due to a misconfiguration or false positive (Google flagging legitimate content). 

Here's how to deal with the most common reasons we've seen this happen and get your site back on track. 

False Positive
Google misinterprets some content and flags it as suspicious. This can easily happen when an author starts making content on the site and accidentally publishes a post while it's still in progress. The short post with little content raises the red flag.

Solution
Review the hacked content list in Google Search console. Visit each page and unpublish the content or finish up the work in progress, then submit a "Reconsideration Request" saying "This is all real content. Some of it was work in progress that we've removed or updated." Then wait for a reply from Google. They usually reply within a day.

Anonymous Uploads
If you have a Webform on your site that allows anonymous users to upload a PDF or other file type, a nefarious hacker will eventually exploit it if you're not careful. Here's how the exploit works.

Your form allows an upload, your attacker uploads a PDF for their own purposes and because there's no spam prevention measure on the form, like CAPTCHA, the form is saved. The file is just sitting in the files directory on the site and is accessible to anyone from the outside. The hacker then simply links to the file they uploaded. Eventually, Google puts two and two together and figures out that shady website is linking to your legitimate site and flags your site as being hacked.

Here's the tricky and really confusing bit about this exploit. The form doesn't even need to be submitted. Files are automatically uploaded and stored temporarily in Drupal as soon as it's uploaded to the form. It won't get stored permanently until the form is submitted, but the hacker doesn't care though. The mission is accomplished for them.

This can be frustrating if you already have spam prevention on your form, like a CAPTCHA and you've been exploited anyway. This causes some head-scratching too because you go hunting for the submissions with the files attached so you can delete them and they're nowhere to be found! This scenario can get even more confusing when you have Varnish caching involved. In that case, the files might show up if you go to them in your browser but they're not even on the server anymore!

Solution
First, change your webform. There are a few options that will work. The first option is to change your file upload setting to use the Private File System. This prevents the uploaded files (either permanent or temporary files) from being accessible to the outside world.

We've had cases where the form submission needed to be accessible to the outside, such as resumes being sent to a regional office and franchisees. In that case, we set the form up with multiple pages/steps. The first steps collected the basic form fields, the next page collected the resume file. Spammers wouldn't make it past the first step so the exploit was stopped.

Now that your form is fixed, make sure you clean up any submissions that might have gotten saved, and check each URL that Google flagged as hacked to make sure the offending PDF has been completely removed. If you're running Varnish, (included in hosting with Acquia or Pantheon) make sure you flush the Varnish cache to remove those files completely. Finally, go ahead and submit your Reconsideration Request to Google and explain that you've cleaned up the issue.

Content Creation Permissions
In one of the worst cases we've seen, bots were creating gobs of content on the site autonomously. The exploit goes like this: An attacker tries to hit a special page, /node/add. That page is a little magical in that it will list any content that a visitor can create on the Drupal site. In a worst case scenario, anonymous visitors can post something there. In a more common scenario, users can register for the site and once they're registered, they get an elevated permission set, something that includes the ability to create content, like a forum post.

Solution
First, head over to the permissions page and go do a permissions audit on any content creation permissions. Do you see a security hole for one of your roles? If so, change the permissions. Dealing with spammers in this sense is outside the topic of this article, in that there are many different scenarios and for business reasons, you may not be able to simply change your permissions. You may need to dig deeper into a spam prevention technique, such as verifying new accounts or adding additional CAPTCHA forms even for logged in users.


This sort of thing has "bad day" written all over it. Hopefully these tips help you resolve the issue and get back on track.