Webmaster Tools

This step pertains to sites hacked to host spam, often with the warning "This site may be compromised" displayed in search results. It's one of the lengthiest steps in the recovery process. The list of damaged files you'll complete during this step will act as comprehensive notes for Step 7: Clean and maintain your site.

If your site was affected by malware, likely displaying the warning "This site may harm your computer" in search results, please see the corresponding article, Step 5: Assess the damage (hacked with malware).

You'll need:

• Shell/terminal administrator access to your site's servers: web, database, files
• Knowledge of shell/terminal commands
• Verified ownership of site in Google Webmaster Tools

Next actions:

This step has three sections:

• Preparation
• Preliminary investigation of spam content (you'll complete this step before you log in to your server)
• General filesystem damage assessment

1. Preparation

1. Create a document to record findings from this step. The document will eventually include (at minimum) the name/location of each file damaged and notes about how it was infected, and will serve as the basis for Step 7: Clean and maintain your site.
2. Watch the video above to see how hackers use sites for spammy purposes, and how they can hide their tracks.

2. Preliminary investigation

1. Copy the URLs listed in the Webmaster Tools' "Notice of suspected hacking" to your new damage assessment document. These URLs will be the start of your investigation.
2. Learn three techniques to safely investigate pages without logging in to your server. Do not open infected pages in a browser as the hacker may have recently configured the spammy page to distribute malware (i.e., opening the page in a browser could damage your computer). Using one or several of the techniques below, make note of how the hacked URLs provided by Webmaster Tools were damaged. Your site will need to be back online for much of this investigation.
• Perform a cache: Google search for the URL to see what Google previously crawled/indexed for the page
• In the Google Search box, type "cache:", then the URL: [cache:http://www.example.com/page.html]
• The hacker's undesirable content may be obvious from the cached result, but if not, click text-only.
• Take detailed notes of any damage you see.
• Use the Fetch as Google feature in Webmaster Tools to see the content served to Google in real-time
1. Make sure that your site is back online.
2. Sign in to Google Webmaster Tools.
3. Select the site that you verified in Step 4.
4. Click Health, and then click Fetch as Google.
5. Enter the URL of the page you want to fetch (for example, page.html). Generally, you won't have to change the dropdown menu from Web. Then click Fetch.
6. If you see a Success link, click to see the contents of the page as retrieved by Google's crawler, Googlebot. As you view the content, note any of the following:
   • Spammy text and links. These may be obvious, but if not, try searching for common spammy keywords like the names of pharmaceutical products or words like "cheap," "free," "casino," and "amateur."
   • Obfuscated spammy text, links, or meta refreshes (which can be harder to detect). Try searching the page code for words like base_64. For example, text like

     eval(base_64_decode("aisiYSlbYlaws..."))

     might be used for cloaking.
   • No damage found through Fetch as Google. In this case, the hacker may have configured your site to only serve the spammy page at certain times of day or only to users who come from a specific referrer (such as from a search result page or only to users of a specific browser). To simulate this behavior, you can try using cURL or Wget, explained below.
• Use cURL or Wget

  These freely available tools can include referer or browser information when performing HTTP requests. For example:

  $curl -v --referer “http://www.google.com” --user-agent "Mozilla/5.0 (Macintosh; Intel 
  Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30" 
  http://www.example.com/page.html
        

3. Broader web-based investigation

Perform a site: search on Google to find more pages damaged by the hacker. The site: operator search, such as [site:example.com], returns results limited to the pages that match the specified site.

• Skim these pages for spammy content. If all results look clean, try including additional query terms to the site: search, similar to: [site:example.com (cheap|free|viagra|cialis|casino|amateur)]
• Continue to make note of any affected pages uncovered through a site: query.

4. Filesystem damage assessment

Next, you'll need to log in to your site's filesystem for more in-depth investigation. Be aware that -- among other things -- the cybercriminal may have modified existing pages or database records, created entirely new spammy pages, written functions to display spam on clean pages, or left "backdoors" that will allow the hacker re-entry to your site or that will continue performing malicious tasks if not deleted.

If your site is online, you can take it back offline for this step.

• If you believe you have a clean backup of your site, work to identify files which have been created or modified since the backup:

  $diff -qr <current-directory> <backup-directory>

  For example:

  $diff -qr www/ backups/full-backup-20120124/

  You can also use

  $md5sum <current-page> <backup-page>

  For example:

  $md5sum www/page.html backups/full-backup-20120124/page.html

  Add all findings to your list of affected files.

• Log in to the filesystem and investigate both the URLs listed in the Webmaster Tools message and the URLs from the site: query.
  • Damage may not be limited to the affected HTML page, configuration file, or database record. It may be caused by a function in a JavaScript or PHP, located in a separate script or system file. Again, take note of the page and the hacker's damage.
• Perform a broader filesystem investigation to thoroughly record all damage to your site.
  • Check server, access, and error logs for any suspicious activity, such as failed login attempts, command history (especially as root), the creation of unknown user accounts, and so on. Be aware that the hacker may have altered these logs for their own purposes. (If helpful, some examples are shown in the video for Step 6: Identify the vulnerability.)
  • Check configuration files, such as .htaccess and httpd.conf, for redirects. Hackers often create conditional redirects based on the user-agent, time of day, or referer.
• Check folder and file permissions for too-lenient write privileges, such as 777 (which equates to world-writable access). Often hackers tamper with permission in hopes that if they remain undetected, they'll have a way back into the site.
  • Check folders with permissions greater than 755 (rwxr-xr-x). Make sure any looser permissions are really necessary. On Unix-based systems, try:

    find <your-dir> -type d -not -perm 755 -exec ls -ld {} \;

  • Check files with permissions greater than 644 (rw-r--r--). Again, make sure any looser permission are really necessary.

    find <your-dir> -type f -not -perm 644 -exec ls -la {} \;

• ​If you have a database, investigate records as thoroughly as possible. You may want to use tools like phpMyAdmin for easier visibility.

5. Determine the hacker's intent

• The hacker may have intended to steal confidential or sensitive information from you or your site's visitors, such as with phishing pages. In this case, check out available resources at antiphishing.org. 
• Perhaps the hacker was trying to exploit a good website to drive traffic to, or improve rankings of, her less-reputable online business by adding spammy text or links to her site. In this case, completing the remaining Help for hacked sites steps, can address this issue.

Step 5: Assess the damage is now completed. The next step in the process is Step 6: Identify the vulnerability.

Step	Technical expertise required
1. Watch the overview	Beginner
2. Contact your hoster and build a support team	Beginner
3. Quarantine your site	Intermediate
4. Touch base with Webmaster Tools	Intermediate
5. Assess the damage (hacked with spam) or     Assess the damage (hacked with malware)	Advanced
6. Identify the vulnerability	Advanced
7. Clean and maintain your site	Advanced
8. Request a review	Intermediate