Understanding Google’s Blacklist – Cleaning Your Hacked Website and Removing From Blacklist

Today we found an interesting case where Google was blacklisting a client’s site but not sharing the reason why. The fact they were sharing very little info should not be new, but what we found as we dove a little deeper should be. The idea is to provide you webmasters with the required insight to understand what is going on, and how to troubleshoot things when your website is blacklisted.

Get Your Bearing

While investigating the website, we found that some Google shortened URLs were being loaded and redirecting to http://bls.pw/. Two of the goo.gl links were pointing to Wikipedia images, their icon to be specific, and one was redirecting to http://bls.pw/ shortener.

goo.gl/9yBTe - http://bits.wikimedia.org/favicon/wikipedia.ico
goo.gl/hNVXP - http://bits.wikimedia.org/favicon/wikipedia.ico?2x2
goo.gl/24vi1 - http://bls.pw/

A quick search for this last URL took us to /wp-content/themes/Site’sTheme/css/iefix.sct. As malware writers like to do, it was trying to trick us into believing it was good code. In this case, the Sizzle CSS Selector Engine code (Real code here) was the target:

Sucuri  Sizzle CSS Selector Engine Modified III

Read More

WordPress Security: 5 Steps To Reduce Your Risk

Often you hear the question, “What plugins should I use for WordPress Security?”. It’s a valid question, but I don’t think it’s the best approach if it’s the only question you’re asking, or the only action you’re taking. If you’re leaving the security of your blog to a plugin from a 3rd party alone, you’re doing it wrong!

Risk reduction is the name of the game. A collective set of actions, tools, and processes all helping lower the risk of exploitation.

It’s Everyone’s Responsibility!

It starts with you. Follow these steps and you lower your risk floor significantly (without the use of a lot of plugins!):

Read More

Website Security – The Importance of Access

Not sure why more emphasis isn’t put on access, but I’ll spend some time on it today. Understand though that this emphasis is not just something pulled out of the clouds. Instead it has come from months of thought and research – courtesy of client environments, enterprise incident handling cases and our own honey pots.

Website Security - Importance of Access

The Importance of Access

For some reason, what I have gathered, is that website owners, in their minds, think they are really ingenious. We think that what we know, no one else knows; the harsh reality is that’s so far from the truth. The are also those that buy into the idea that information security is an absolute, if only it were. Website owners have to learn to set their expectations, the InfoSec domain is about risk reduction. That is the first thing to understand.

While software vulnerabilities are a real threat, without tangible evidence, I am willing to bet that access is gaining ground on software vulnerabilities more than most realize. Still working on evidence to support this. A good thing to remember is that as a product becomes more secure, and the attack vectors decrease, access only increases in importance.

Read More

Website Malware – Joomla SEP Attack – Pharma Injection

This was a fun, yet painful case. In the past we have written a few different posts targeting search engine poisoning attacks (SEP) that like to use Pharmaceutical keywords and their associated links to poison your search engine results.

Today we had an interesting scenario where Google had not yet blacklisted the client, but our free scanner, SiteCheck, was in fact picking up the injection. From what we could see it was being triggered by a referrer but it wasn’t the typical referrers you’d expect, it’s condition was if it came from itself.

If you’re wondering why that is, allow me to explain. That meant that the payload would not show up the first time you visit the page, only when you visit the same page and the referrer was set to itself. This actually a very good evasive technique, it would make detection that much harder by most conventional scanners. In short, if the user clicks on the paeg once, it wouldn’t appear. This makes it very hard to detect and replicate unless you start testing every option. In this case, it wasn’t until you clicked on the option two consecutive times that the injections would appear.

You could try any other variation and it’d never work, only if you clicked on it two consecutive times. How annoying is that !!! This probably explains why Google and many others never picked it up.

In either event, this was a Joomla site and so the question was, where the heck is this thing.

Read More

Website Malware Removal – FTP Tips & Tricks

When you clean as many sites as we do every day you start to come up with little tricks that help expedite the process, here is one where you can use FTP to your advantage.

This post will cover two features in FileZilla that any novice can quickly employ:

  • Using Filters
  • Using Comparisons

For those wondering I’m running FileZilla on MAC OS, version 3.6.0. But this goes back a couple different versions, it’s not a new feature.

Filter Out the Noise

This is perhaps the coolest little tool. From time to time we have to download sites, although we prefer to work remotely, its inevitable. When we do we have to filter out all the non-essential data, not doing so would add way too much time to the entire process. Some sites like to bloat themselves with images and videos and backup zips – you get the point. So how to get around that?

Glad you asked….

Read More

Dealing with WordPress Malware

A few months back I contributed to a post with Smashing Magazine on the top 4 WordPress Infections, it was released yesterday, and it couldn’t have been at a better time. If any one attended WordCamp Las Vegas you might even find some similarities. Fortunately in the process of preparing for the event and working with the team, we were able to compile a bit more information expanding on the things we originally discussed in the last post. It’s perfect timing for a number of reasons, and will complement this post very nicely.

WordPress Malware
The idea of this post, like many in the past, is to outline and discuss this past weekend’s presentation. In the process, hopefully you take something away. Unfortunately, the presentation was capped off with a live attack and hack, and I won’t be able to include that in this post, but I promise it’s coming.

**Note: If you plan to be at WordCamp Philadelphia 2012 you might be in for some treats, just saying. And if you don’t have it on the calendar, you should.

Read More

WordPress Security – Cutting Through The BS

I recently spoke at WordCamp Chicago 2012 on WordPress Security. In this post I’ll share my presentation but also provide context such that it allows the reader to better digest the presentations content.

Let me know how I do!!!

When putting the presentation together I found myself between a rock and hard spot, I felt as if all the presentations given to date are always about the same stuff. And maybe that’s necessary, repetitiveness is key they say, but is it?

Read More

SiteCheck – Got Blackhat SEO Spam Warning?

As of late it seems like we’re talking about a lot of SPAM related cases, this post will be no different.

Blackhat SEO

Before you start, let me preface this by saying that clearing a Blackhat SEO Spam injection is probably the biggest PITA (Google It) infection there is. They constantly evolve, making them difficult to detect and they employ both new and old techniques that, even after years, still prove to be annoying. This post will demonstrate one such case.

Read More

Automation is Key With Today’s Website Attacks

When trying to undertand the anatomy of attacks on websites you have to break it down into manageable parts. In my mind it really comes down to two types: Targeted and Opportunistic.

More important to understand is how the attack is executed, and that’s what I want to spend some time on in this post.

What do today’s attacks look like?

For most, targeted attacks will be rare, but they do happen every day. You might recall mentions on the news about the CIA website being defaced, or LinkedIn and eHarmony being compromised, in both those instances, I’d categorize those as targeted attacks. There are also examples like the most recent article that talked to the Gizmodo employee who appeared to have lost his entire digital identify, simply because the attacker liked his Twitter handle.

On the flip side, you have opportunistic attacks that are likely what most reading this get affected by. I provide a better discussion on it on our post, Understanding Opportunistic Attacks. The good news though is that in both instances you find many similarities in the attacks, specifically the use of tools that allow for automation.

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:

<IfModule mod_rewrite.c&>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|about|acoon|alexana|allesklar|
RewriteRule ^(.*)$ http://mytresca.com/counter.php [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 .* http://sweepstakesandcontestsnow.com/nl-in.php?d=1 [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 info@sucuri.net.