If Google detects that your website is hosting malware, it is pretty clear your site has been attacked. Attackers are consistently using automated attack tools looking for SQL Injection points, trying to include files remotely, or attempting to determine ssh passwords via guessing. A frightening trend with SQL Injection attacks concerns how an attacker will insert links to javascript content used to serve malicious links that may try and automatically compromise the users of your website.  When this happens, Google will automatically detect this and actively deter users from visiting your  website. Here are some of the  basic recovery steps that need to be taken to ensure all content that was  possibly modified by the attacker will be removed. It is also  important to note this is not legal advice and should not  be used as such. If you are experiencing monetary loss, consider engaging the proper authorities and hiring a consultant  who is certified to handle these situations. The steps below are  simply a very rough set of guidelines on one way that a security  analyst might approach securing a hacked website.

___

 0. Disconnect from the Internet

      The last thing you need is to get attacked again while

      performing forensic analysis or restoring your database/

      website to its former glory. Remove your server from this

      possibility by disconnecting it from the Internet.

      If your website was hacked, simply turning

      off the webserver is probably a sufficient countermeasure.

 1. Backups!

      You need to backup your entire site and backend database at

      this point. It is important to perform this step as later you

      will actually be deleting all your current content and replacing

      it with a backed-up version. This is recommended to ensure

            the attacker has not modified anything on your site. For example,

      the attacker might have installed a backdoor or a dynamic script that

      would allow shell access to the server.

 1b. Save All Logs and Analyze Them

      All server logs should be saved from the attacked machine. If

      your organization has familiarity with web/network based

      attacks, then spending some time looking through logs would be

      beneficial as it may help identify the attackers point of

      entry. This will obviously help in remediating the issues and

      detecting how widespread the vulnerability may be.

 2. Change all Authentication!

      If an attacker has been able to modify your database or

      filesystem, it is very likely he/she has also stolen the

      credentials needed to access your website. This includes

      usernames/passwords needed to login to any private areas

      on the website, and any usernames/passwords that are

      also users on the local machine such as the root user or the

      administrator passwords, especially if any remote

      administration (like OpenSSH) is used on the website. Don't

      forget to remove any ssh/rsa private keys either as they can

      no longer be trusted.

 2b. Reinstall OS (optional? maybe)

      Pedantic administrators worried about security and not able

      to pinpoint the vector used to compromise their website

      would completely reimage the webserver, as bots or key-loggers

      may have been installed. This is most likely a severe case.

      However, it may be an acceptable precautionary step depending

      on how sensitive the webserver or content is to the

      organization.

 3. Restore Previous Backups

      You can no longer trust the code or data that your website

      is serving or using to serve data. Thus you need to restore

      to a point in which you did trust your code and data. This

      is probably going to be a painful process, but it will still be

      better than being consistently hacked multiple times in the

      future.

      If you have no database backup, don't give up. Consider using

      the OWASP Scrubbr utility. This utility is designed to analyze

      database records and look for suspicious looking links that

      will help you identify and remove malicious content. It also

      has the side affect of helping you pinpoint where your

      problems may lie. Generally writing to specific fields within

      the database only occurs on a few pages, so the search for

      where the input validation needs to occur will be limited.

 4. Perform Some Simple Code Audits

      You already have accepted that a hack has occurred, so it

      makes sense to spend some time looking through critical

      path code to make sure no obvious mistakes were made.

      This could mean hiring a consultant to analyze your codebase

      or utilizing your developers to examine the code by running opensource

      tools like Nikto on your site. Both would provide beneficial

      data as to where to suspect malicious activity, and improve

      your security posture. If you found something suspicious in

      the logs of your webserver, you should spend some time

      verifying those specific areas but it is important to note that

      even though the attacker used door #1, that doesn't mean  door #2

      isn't sitting there available right now. Security is an ongoing process

      and especially after an attack time should be spent securing and analyzing your

      current codebase. This is important because generally

      mistakes within webapps are systemic and not just a one off

      error that only happens in one place within your codebase.

 5. Turn the Site Back On

      Feeling better, hopefully having identified some issues, it is

      now time to turn on the web server (hopefully with a clean

      bill of health).

___

Your probably thinking to yourself, "this seems like a lot of work, is it really all necessary?". The answer to this question is maybe. Of course this is a nebulous answer to that question, but the actual recovery from an attack might only require a few of the steps listed above. The real trick is in deciding which of those steps are needed (optimization) and the answer to that depends on the type of attack you've encountered. For example, if your site was attacked by just a simple drive-by SQL Injection bot then it is probably sufficient take the following subset of steps.

(1 + 1b) To make sure you have your bases covered and by looking at the logs you can identify the injection points the bots were trying to exploit. (4) Once you've identified the pages being attacked, you (or a consultant) can then verify those pages either have or do not have SQL Injection vulnerabilities. (3) Clean up your database, make sure all offending links can be cleaned, whether this is manually, with your own tool, or using OWASP's Scrubbr.

Of course it is not always easy to identify what type of malware has been attacking your website. There are services available that will perform this types of analysis for you. You can contact either Armorize (http://hackalert.armorize.com/default.php) or ClickFacts (http://www.clickfacts.com/) who will audit the types of malware being served by your website. Since they have specific knowledge in these areas, they will probably be able to tell you specifically which attack has been used and recommend steps for cleaning up your website.