Malicious Redirects - Common Fixing Guide

A fixing guide for "malicious redirects" problem based on eVuln team experience. Here you will find our common algorithm of removing a redirecting malware from an infected website.

Important: before fixing we recommend to close your website with 503 error page: "Service Temporarily Unavailable". So, your website will not infect its visitors and Googlebot will not mark it as malicious while you are fixing it.

Important: before doing any modifications in files it is necessary to make a backup copy for 2 reasons:

  • file's last modification time is very important for further analysis;
  • you should have an ability to restore your files after unsuccessful fixing.

Before editing any file you may rename it (to save last modification time) like this: "filename.infected". Then make a copy with the original name and fix your file with the original name. These actions (rename and copy) allow to make a backup copy of an infected file with original last modification time.

1. How to diagnose malicious redirects.

Try to find your website in some famous search engine. You may search for "yourdomainname.com" and click on a link to your website. If your browser is redirected to a 3rd-party URL then your website is infected.

Another way how to check for malicious redirects is to use eVuln malware scanner.

2. Identify infected/modified files.

First of all, it is necessary to identify a website's file which has been modified without your permission. This step allows to discover the exact date/time when your website was hacked last time.

Redirecting code should be found in:

  • .htaccess file(s).
  • php (or any other language) file(s)
  • html files.

2.1 Redirecting code in .htaccess files.

If the main page of your website redirects visitors then you should check the main .htaccess file in the root website's folder. Check .htaccess in the upper folders also if possible.

Here is an example of one of the most popular malicious redirecting codes:

2.2 Redirecting code in PHP files.

If you have not found redirects in htaccess files then you should check your php files for some alien code. Usually you can find some malicious code at the beginning or at the end of file but keep in mind that it can be injected in any place of code.

Usually malicious redirecting code looks like a long obfuscated string of symbols with deobfuscation functions like: eval() base64_decode() preg_replace() gzinflate(). Here are some examples:



First of all, check the following files: index.php header.php footer.php and etc. If you know when your website was infected then you may try to find the recently modified files and check them for suspicious code.

Note: for any other scripting language fixing steps are very similar.

2.3 Redirects in HTML files.

HTML files may be infected with redirects using JavaScript or Meta tags. This is a less popular redirecting method but it may be also used. Obfuscation methods are usually used in Javascript code. So you should pay attention to long lines of code, unreadable code and functions like eval() unescape() fromCharCode().

3. How website's files were modified.

If you have found one or several infected files then your next important step is to discover how these files have been modified.

Website's files can be modified using the following ways:

  • webshells / hacked neighbor websites
  • website vulnerabilities
  • stolen FTP or admin panel login/pass

3.1 Webshells.

Webshell is a script which can be used to create/modify/delete website's files and do any manipulations with website's database. Bad sever configuration allows webshell to access files and DB of neighbor websites on the same server.

Here are some examples of short webshells:





You may also find big files (1-100kb) which are webshells with embedded file manager, database browser and other functions. A webshell code may be obfuscated and looks like a long encoded string as parameter for eval() base64_decode() preg_replace() functions.

Webshell is a file which was created by other webshell or website vulnerability or uploaded by FTP. Lst modification time of webshell file and logs analysis may help to discover this.

3.2 Website vulnerabilities.

Some outdated scripts (for example, Wordpress, Joomla and their modules/themes) or low-quality scripts of your website may have vulnerabilities like php including, shell command execution, sql injection or etc. These vulnerabilities may be used to upload a webshell or steal administrator password.

Logs analysis may help to identify this. If you have found strange http queries to some clean script then we recommend to update your website engine/component/theme. If you use your own scripts then it is necessary to do some security review.

3.3 Stolen password.

If administrator panel allows to modify website's files then it becomes a hacker's target. Admin password may be stolen using several ways:

  • Trojan/virus on your own PC - malware may steal FTP passwords by traffic sniffing or from local config files of FTP client software.
  • Webshell on hacked neighbor website - a bad server configuration allows to read config files and access DB of neighbor websites.
  • sql injection or xss website vulnerabilities - allow to get passwords or their hashes from site's DB or admin cookies.
  • brute force attack - easy passwords may be successfully stolen

4. Logs analysis.

Pay attention to the last modification time of infected files. Then you should find the exact date and time in HTTP logs or FTP logs.

4.1 HTTP logs.

In HTTP logs You may find something like this:

This is some POST query to the suspicious php file in the images folder. During HTTP logs analysis you should pay attention to:

  • POST queries. Attackers prefer to use POST queries to their webshells to prevent logging of parameters.

  • PHP files in the images/data folders or any other strange places.

When you see a suspicious query to some PHP file then it is necessary to check it for malicious code.

If you have several websites on the same server/account you should check log files of every website because one hacked website may be used to infect all others.

4.2 FTP logs.

Difference of 1-2 seconds in the last modification time says that a website has probably been infected using FTP (FTP protocol works slow enough with a big amount of small files). Anyway it is better to check FTP logs.

When you check FTP logs pay attention to unknown IP addreses and recently uploaded files. Any suspicious files should be checked for malware code.

4.3 Logs are unavailable.

If you don't have log files or an access to them then you may search for all infected files with similar last modification time. When all the infected files are cleaned you need to find some webshell (it should have an earlier creation date) or website vulnerability.

Webshells may be found by such functions like eval() base64_decode() preg_replace().

Website vulnerabilities are not so easy to find in a big amount of code. If you use some famous website engine (like Wordpress, joomla or etc) it is better to restore from backup and make an update to the latest version including all themes and modules.

Note: if you use Cpanel it is better to switch on an option ("Archive logs in your home directory...") to keep logs forever in "Raw Access Log" page. By default you have one day logs only.

5. Blacklists removal.

Blacklisted websites may be submitted for review using stopbadware.org website or Google Webmasters Tool. If your website is clean it will be removed from blacklists during 1-5 days.

6. How to prevent reinfection.

Here are some suggestions how to keep your website clean:

  • Keep your website engine updated (including all themes/modules and etc).
  • Use dedicated/virtual server for your websites if possible.
  • Change all the passwords and make them more complicated.

Good luck!



Alex (Aliaksandr Hartsuyeu)
eVuln.com