25 Years of Programming
An open source source for C, C++, OWL, BASIC, MDB, XLS, DOT, and more...
How to remove the "This site may harm your computer" warning from your website's listings in Google search results, step by step
What is the warning?
Google puts this warning flag in its search results for pages where its automated web crawler was attacked by viruses or spyware when it visited the page. The purpose of the warning is to help protect web surfers who are using Google search results, by steering them away from malicious pages. Yahoo provides similar warnings on its result pages.
The warning is not a punishment or penalty, and it does not mean that Google, Yahoo, or StopBadware think you designed your site to be malicious. They all know that the overwhelming majority of webmasters do not create malicious pages on purpose and that you probably didn't, either. However, they don't want to send their customers to dangerous pages, so they require that your site be cleaned before they will start referring people to it again.
Why is your site flagged?
Here are reasons why your website can be flagged with the "This site may harm your computer" warning in Google search results:
StopBadware provides a description of what they consider to be malicious website behavior.
The Firefox 3+ and Chrome browsers use data from the Google Safe Browsing Service to warn users about suspected malicious sites. When your site is flagged in Google search results, Firefox users receive a warning that says, "Reported Attack Site!", and they are blocked from going there.
Internet Explorer does not use the Google service. It uses a Microsoft database. If Firefox gives a warning but Internet Explorer does not, it does not mean that the site is safe in either browser. It just means there is different data in the two databases. The Google database is nearly 100% accurate. If Google says your site has become harmful, it is safest to assume they are correct. False positives are rare.
Why antivirus scanning might not find the bad code
The first idea that occurs to many webmasters is to do an AV scan on the site, but in many cases that will not find the problem. The next sections explain why.
A) Scanning your website files on the server
Scanning your server with an antivirus program will only work if the site is actually hosting the virus, which it often isn't.
The remote viruses aren't pulled in until the page is loaded into a visitor's browser. Then their browser fetches the code referred to by the src= property, and then they get a virus alert.
If you scan your site with an antivirus program and it finds no viruses, that does not mean the site is clean.
B) Downloading your site files to your PC and scanning them there
Using a tool like FTP, Wget, or cURL to download the source code of your pages to your local PC and AV-scanning them there is also unlikely to find the virus, for the same reason given above: the actual virus is probably not on the pages.
Wget in "recursive download" mode can retrieve all linked files, including ones from remote sites, but if some of them are viruses, you will be taking the unnecessary risk of downloading them directly to your PC.
C) Risky - browse your pages with an antivirus program running on your PC
If you are determined to use the facilities of an AV program to scan your site, you can browse the site as if you were an ordinary visitor. This is risky because an increasing number of viruses are "polymorphic". Their code changes so frequently (every day or every time they are served) that antivirus programs can't keep up, and they do a poor job of detecting them:
In summary, antivirus scanning is not definitive. If it finds a problem, that's useful. If it doesn't find a problem, it means nothing because the virus might be on a different website, or might be encrypted or polymorphic, or your website's problem might not be a virus at all. It might be a malicious redirect in the .htaccess file that only occurs for users coming from search engine results.
So the most thorough way to examine the site is to learn what to look for and then inspect your source files manually.
1) Discover which pages are flagged for malware and get clues about why they are flagged
Now that you have preliminary information about which pages are affected and what seems to be wrong with them, you can start searching for bad code. Some of it might have been identified already in the steps above.
2) Remember to search your source code for badware
Whenever possible, view and search the source code of your pages, on your server. This allows you to see ALL the code, even if it is only put on the pages sometimes.
Some exploits put malicious code on pages only under certain conditions such as if the visitor is using Internet Explorer or if they came to your site from a Yahoo or Google search results page. Your particular viewing might not meet those conditions (such as if you're using Firefox or you went directly to the site without going through a search engine). If you examine pages with your browser's View Source command, you can think the page is clean even though at other times, or when other people view it, it's not.
Examining the source code on your server lets you see all the code that's there.
3) Programs for searching pages for malicious code
3a) Search one page at a time (recommended)
Starting with the most important flagged page (such as your home page), visually inspect the source code of each file for the types of malicious text described in Section 4 below.
Malicious code is often inserted into web page files by robots (programs) using very simple rules for where to put it. Common locations are:
If your pages normally validate at W3C, go there and check your badware-flagged pages. Any errors you get might point directly to where the bad code is.
3b) Multi-file searching
With multi-file searching, a program scans all files for the search string you specify, and reports all the instances it finds. This is an efficient way to search if you already know how to do it. Otherwise, this is probably not the best time to learn, and I'd recommend the one-page-at-a-time method, above.
Do your search directly on the server with an operating system tool like grep.
If you're already familiar with cron and grep, you can create a cron job to do the grep search as though you had shell (command line) access.
Otherwise, download the pages (or your entire site) to your PC so you can search them there. Download with:
After downloading the pages to your PC, you can do the searching with any program that supports searching multiple files. Some examples:
4) Search strings to find malicious code
These are useful search strings, whether you are searching one file at a time or all files at once:
Make sure all instances of src= and http:// refer to files on your site or to external sites you know and trust.
Some common trusted sites that are not a problem are:
4a) What do malicious or invisible iframes look like?
iframe code looks like this. If you don't recognize remotesite.com, the code is suspicious. This example combines two separate methods of making it an "invisible iframe", either one of which would work by itself: the width and height settings, or the style:
<iframe src="http://remotesite.com/path/file" width="0" height="0" frameborder="0" style="display:none"></iframe>
Whenever you find an iframe like this, do a web search on remotesite.com to find security-related websites, blogs, or forum posts that discuss it:
remotesite.com malware OR hacked
Be careful to avoid clicking any result that is the malicious website, or is a website that was infected by it! Some iframes are always associated with a particular type of exploit, so information about the one you found can save a lot of time discovering how your website got hacked. For example, iframes referencing gumblar.cn, martuz.cn, and a growing list of others are the result of FTP password theft from the webmaster's PC, so the security problem is on the PC, not the server.
Sometimes VBScript is used instead, so the code starts with:
If in doubt about whether a block of code is malicious, take a snippet of it and do a web search on it.
5) Which pages to search for malicious code
Search all the files that have any part in your web pages: .html, .htm, .php, .asp, .aspx, .inc (include files), .cfm, .css (style sheets).
If you find nothing in your text files, it might be necessary to search your database for malicious code, which will be discussed later.
6) Forum posts and blog comments
Examine user-generated content on your site for malicious uploads or attachments posted by visitors or spambots. To be efficient, start with posts from a few days before the site first got flagged. Or start at the end and work backwards.
7) Advertisements that Google considers badware
There are a few advertising networks that intentionally do things in their code that StopBadware and Google consider badware behavior. Other ad networks fail (either consistently or accidentally) to fully screen the ads submitted by advertisers for distribution, so sometimes malicious ads get into their network.
Make a list of the advertisers you are affiliated with. To find out if other publishers are experiencing the same problem as you with this network, do a web search on them or ask about them in a forum where there are people who might be up-to-date with which advertisers are currently causing problems. An example of a web search I have found useful is:
advertiser badware OR StopBadware OR malware OR virus
Bad ads can slip into even the big ad networks such as DoubleClick and MSN. When this happens at the biggest networks, it is usually resolved quickly.
If you suspect bad ads might be your problem, the solution is to stop displaying the ads on your pages until the ad network problem is resolved. Report the problem to the network with as much detail as you can provide.
An increasing amount of advertising is being served in Flash .swf files. These files can be flagged as badware, too. See the next section.
There have been numerous security vulnerabilities found in Flash. In addition, Flash scripting allows authors to embed badware behavior such as redirecting to a different website while the user is helpless to prevent it.
Whether your Flash files serve third-party advertising or merely your own content, they will get flagged if Google determines they have malicious scripting or are otherwise a hazard to a visitor's PC.
The easiest way to determine whether .swf files are the reason for your site being flagged is to remove the files as part of your initial site cleanup. After the badware flag is removed from your site, put the files back. If the flag returns, they're a problem. You can also try scanning your .swf files with the AdopsTools Online click checker, which gives you a report about the file's content.
These links might help you investigate further:
While you are investigating and fixing your site, you might want to keep Flash disabled in your browser in case you have a bad .swf file.
In Internet Explorer, go to Tools > Manage Add-ons > Enable or Disable Add-ons > Add-ons that have been used by Internet Explorer. Disable two items: 1) Shockwave Flash Object and 2) Shockwave ActiveX Control (if present).
9) Advertisements from otherwise legitimate ad networks that have been hacked and are now serving badware
Even if your advertisers normally use only legitimate methods, their ads might have been replaced with malicious code, which would start appearing on your pages instead of the usual ads.
This is a danger anytime your pages pull some of their content from other sites.
This is one case where the only way to detect the malicious code is to visit your site pages with your browser, to make sure all the ads are the legitimate ones you expect. If you are affected by the problems an advertising network is having, you won't be the only one, so a web search should turn up other similar reports.
10) Other third party content
If you use any code that includes content from a remote site, such as
there is always the danger that a problem at the other site could affect your pages.
11) Database content from your CMS.
If content for your site pages is stored in a Content Management System (CMS) database, it is possible that an SQL injection attack inserted malicious code into the database tables, and it is getting into your pages from there.
One way to search or visually inspect and clean the data in your database tables is with cPanel > phpMyAdmin.
Another way that should sometimes be workable is to go to cPanel > Backups and download a backup of the database in sql.gz format which is a plain text file when it's decompressed. If your antivirus software allows you to keep the downloaded file (it might detect the malware and quarantine the file instantly), and if the database isn't huge, you can view the text in a text editor, search and replace the malicious code, and upload the cleaned database back to the server.
The easiest way to clean the database is to restore it from a known-good backup.
If you suspect SQL Injection, you can use the online hack attempt identifier to determine whether your site has been receiving attacks of that type. If you write your own database connection and query code, it is possible to prevent SQL Injection.
12) Rewrites or redirects in your .htaccess file(s)
Examine your site configuration files such as Apache .htaccess and httpd.conf for code that sends your visitors to a malicious site. Look for lines containing the words Rewrite or Redirect with references to sites that aren't yours, and RewriteRule lines referring to google.com or yahoo.com. htaccess exploits often redirect only if the visitor came from a search engine. If your visitors report being redirected and you can't reproduce the behavior yourself, try going to your site from a Google search result.
In your existing .htaccess files, search carefully and scroll all the way to the bottom of the file. Sometimes hundreds of blank lines are inserted before the malicious code.
Look for new .htaccess files that might have been added to the site. Search all the folders inside /public_html and also the folder(s) above /public_html.
You can test for, confirm, and study redirects as they happen with the Firefox add-on Live HTTP Headers.
14) Meta-refresh redirects
An HTML meta-refresh is yet another way to automatically redirect visitors to a different website. Look for code like this within the <head></head> sections of your documents:
<meta http-equiv="refresh" content="0;
These examples redirect to the other page after 0 seconds.
15) Check your error pages
If you have custom error pages that you created and that are stored within your website, you probably examined those files already in the previous steps.
However, many websites don't have custom error documents. In that case, the server uses its default error documents which are stored outside your website. You can test those by provoking a server error and checking the page you receive:
If you find bad links or viruses on your server's default error pages, it is a sign that the server, not just your website, has been compromised. Continue to the next step, and notify your webhosting company.
16) Server has a rootkit installed
A rootkit is a type of infection that installs malicious programs to partially replace the server's operating system. It performs ordinary operating system tasks just like the OS would, but it also performs whatever malicious activity it is programmed to do. Because it controls operating system tasks, it can hide itself. A server compromised with a rootkit-type infection cannot be trusted at all, not even to properly report on its own status or give accurate directory listings.
If you have thoroughly investigated all the preceding possibilities and you are sure everything inside your site is clean, it is possible that areas of your server outside your website are compromised (such as the default error pages in the previous step), or the server itself might be infected with software such as a rootkit. It might be injecting malicious content onto your pages in real time, after the pages are read from disk and just before they are sent out.
The behavior described above is not proof of a compromised server, however. For example, it is possible for the hacker to put new pages -- or even an entire website -- inside your website and then use .htaccess rewrites or PHP code to serve those pages instead of the requested ones. In this case, the pages are actually in your site and there is no server-wide compromise. With any luck, the investigation you've done to this point would already have uncovered either the hidden files or the rewrite code that is causing them to be served.
If you truly believe your server is compromised and you're on shared hosting, there is nothing you can do to repair the damage to the server. File a support ticket with your webhost and ask them to investigate. While you wait, you can:
If you run a dedicated server, reformat the hard drive, reinstall and configure the operating system and server software, reinstall your site from known-good backups, --> fix the security vulnerability that allowed the compromise to occur <--, and start fresh.
Server-wide compromises used to be rare. In 2009, with exploits such as beladen, the incidence is increasing. It is still almost the last thing you should suspect, but it's not as unlikely as it used to be.
You might find the following articles useful if you suspect a server-wide compromise. The attacks discussed were from 2008, but their methods may have evolved into the more widespread attacks being seen today:
17) DNS cache poisoning
People think of website addresses as text like http://website.com, but web addresses are really numbers called IP addresses. Before a browser can fetch a web page from a site, it must first send a query to a DNS Server to get the site's correct numeric address.
Occasionally, someone manages to inject bad data into a DNS server so the IP address translations it returns are wrong. If someone tries to visit your website but their browser gets your IP address from a poisoned DNS server, they will be sent to a completely wrong website. That site might have malicious content, which could cause your site to be flagged for badware.
When investigating your badware flag, this is a "way-out-there" scenario, rare and unlikely, but it has happened, so it's included here for completeness.
18) Request a review from Google or StopBadware
After you have found and resolved all the likely reasons your site got flagged, file a request for review in the Webmaster Tools section of Google Webmaster Central, or on the StopBadware Request for Review form. If they find that the malicious behavior is gone, the warning flag is usually removed within 1 to a few days even though their submission form says to allow longer.
If you changed nothing on your site, but only submit the review request, the flag will not be removed. If you did nothing but delete the pages that were flagged, the flag will not be removed. The flag is removed after Google finds that the previously infected pages are still there, and clean.
Keeping badware off your site
The most important ways to keep badware off your site are
Comments, questions, and discussion welcome in the Forum.
In case you're wondering, no this site has never been flagged. I have helped numerous webmasters get the warning removed, both in discussion forums and for hire.
Copyright ©2012 Steven Whitney. Last modified Sun 07/29/2012 10:53:28 -0700.