Blackmuscats Conditional Redirections to Fake AntiVirus

We are seeing many sites today compromised with the Blackmuscats conditional redirection. This malware causes anyone visiting the hacked site to be redirected to a Fake AV (AntiVirus). Why Blackmuscats? All the compromised sites have .htaccess redirections pointing to files ending in “blackmuscats?5″.

So far we have detected more than 8,000 sites with this type of redirection and the number is growing (last night we had only found a few hundred).

Note: this is a conditional redirection, so you are only sent to the malware site if you are coming from a search engine, not if you visit the site directly.

Here are some of the domains being used as part of this malware campaign:

Read More

WordPress and Server Hardening – Taking Security to Another Level

The biggest problem today with most content management systems (CMS) and web applications is the adoption of what we call the “Win95 security model”. Do you remember the Windows 95 security model? With everything running under the admin role? No separation of privileges? No separation of processes? One vulnerability and you take it all?

Confused as to how this relates to today’s CMS’s (including WordPress, Joomla, and others)? Let us explain using WordPress as an example (most popular CMS out there):

Read More

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/

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:

<IfModule mod_rewrite.c&>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|about|acoon|alexana|allesklar|
RewriteRule ^(.*)$ [R=301,L]

<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 .* [CO=cookie-visited-name:1:%{HTTP_HOST}:10000,R,L]

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:


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


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:

and the second sends them here:

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)



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 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

Backdoor Tool Kit – Today’s Scary Web Malware Reality

We often talk about the importance of keeping your server clean. You can see it in a number of our articles and presentations, this post will likely drive that point home.

This past week we came across a nice little package that we felt compelled to share with you. In it, the attacker makes use of a number of tools designed to help them infiltrate your environment. What’s likely most annoying about this kit is that it’s loaded into your environment, and uses your own resources to help hack you. That’s like being punched in the gut and slapped at the same time, not cool.

Read More

Pharma Hack Backdoor Analyzed – PHP5.PHP

Some of you might remember my last Pharma hack post, Intelligent (Pharma) SPAM Decoded, today I will spend some time looking a different variant of the same infection type but focus on a payload that is not encoded or embedded within an existing file, instead it resides in its own file – PHP5.php.

“Hmm, maybe it’s a good / system file, it does have PHP in it, I won’t bother looking at it…”

If you have ever come across this file and find yourself thinking this, we highly encourage you not to and take a minute to see if any of its components resemble what we’re about to share.

Dissecting the Payload

Read More

Sucuri is Hiring: Senior PHP Developer

It’s that time again. We’re actively looking for a Senior PHP Developer to join the family. If you are passionate about web-based malware, and you want to help build awesomess, we want to hear from you.

Details can be found here Sucuri employment.

Fake jQuery Website Serving Redirection Malware

This just in, hot off the press, careful with the jQuery libraries you’re using on your websites.

We received word from @chris_olbekson via Twitter about some hacks being reported on the WordPress forums:


Read More

Sneaky vBulletin Script Injections

In the past few days/weeks we have been seeing some nasty vBulletin infections that are proving difficult to find. In this post we’ll describe it and what we have done to remove it.

We recently wrote about Conditional Malware, this is but another instance of that. In this instance, the conditions are set around specific referrers and user-agents.

When a user visits the forum via Google search engine result pages (SERP), they are greeted with this payload:

Read More

Website Malware Removal – WordPress Tips & Tricks

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. Alternatively, if you’re already hacked, you can enlist our help to clean your website regardless of CMS.

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:

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/

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 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:

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

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

New Web Malware Attacks Using .Ru/In.CGI?16

What does an orange roller, a purple beetle, an orange moth, a green pillar, and a green cricket have in common? Not much, but they are all being used as malware domains to distribute .Ru/In.CGI?16 which is affecting thousands of web sites lately.

Read More