SQL injections on websites carrying backdoor scripts

We’ve seen this for awhile now, but recently it seems to be a growing trend.

Many of the websites we’ve been cleaning have the backdoor scripts injected into the SQL database so that when the webpage is accessed, the backdoor is available, but invisible to the visitor.

To a hacker who knows what page or which website is carrying their code, it’s easy for them to send a string of code and on their screen the backdoor shell script appears.

When we have the access logs available to us, we have analyzed them and it does not appear to be a regular SQL injection (SQLi), but it does appear that the hackers find a point of entry to the website, then search for the file that contains the database information. They upload a shell that provides them with something like phpmyadmin, then they add their infectious code to selective fields in the database.

We know that many people believe that moving their wp-config.php file outside of the public_html folder keeps their database login information safe. This is not true. When a hacker infects a website, they typically have full access to the hosting account. This includes the areas outside of public_html. We’ve seen this thousands of times.

At times the code has been an infectious iframe or other javascript string, however, finding full backdoor shells buried in the SQL database is even more alarming. The hackers have created various ways of hiding this so when a legitimate user visits the website they don’t see any suspicious code. When a hacker sends their code to the specific webpage, it opens their backdoor shell. This will hide their code from many of the online scanners. We still feel these online scanners are helpful, but the hackers are finding various methods to hide their activities.

This makes repeat infections extremely easy for the hackers. As a website owner you could be searching all the code on your site and find nothing. To find this malicious code, you’ll have to export your database and then scan it for any script tags and for any php tags. If you find any, you’ll have to analyze the string to determine if it’s malicious or not.

One key we’ve found is that their backdoor shells need a field in the database that’s large enough to contain their lengthy code – at least for the backdoor shell scripts. Smaller javascript or iframe infections could be anywhere in the database. You’ll have to be familiar enough with the database layout for your website to know where to look.

If you’ve been subjected to repeat infections, you might want to look in your database. Even if you haven’t been subjected to repeat website infection, you might still want to look in your database to see what might be lurking.

If you need help analyzing your database, please send an email to:

If you have any more insight to this infection, or have additional questions, please leave a comment.

Thank you.


Attack of the BrowserDetect

This infection has been around for awhile, but it’s been more popular recently.

We’ve been seeing it after the closing html tag in index.html files:

There have been other domains in place of too, but the bottom line is that the above script performs a series of browser checks then creates an iframe.

This infection has been seen in Zen Cart, osCommerce, WordPress and Prestashop websites by us, but I’m certain that it’s just the infection used at the moment.

If you’ve experienced this infection and need assistance with it, please call us at (847)728-0214 or email me at

If you have any comments to add to this, please leave a comment below.

Thank you.

By infection changes to

As you may know from our previous posts, we’ve been watching the infection of millions of e-commerce websites over the past few weeks.

Now, it appears that many of these are still infected and the hackers have now changed the infection to:

hxxp://tiasissi. com .br/revendedores/jquery

What’s really frustrating from our perspective, is that these are so easy to prevent. To date, we’ve cleaned 1,179 of these infections and no repeat infections – our methods work!

With the willysy infections we’ve seen many entries in the admin section of the osCommerce database which shows that the hackers have taken total control of these websites and this is just the infectious code they prefer to use for now.

There are many different backdoor shell scripts the hackers are installing on these websites and code inserted into the payment processing files that allow the hackers to steal the credit card information as it gets processed.

This is all cleanable and prevention is quite easy.

Contact us to have your website cleaned or email me at:

If you have questions about this, please leave a comment. We’ll respond promptly.

Thank you.

By infection of osCommerce sites

UPDATE August 6, 2011: The number of websites infected with this had risen to over 5 million. The prevention of this type of attack is really quite simple – and something we’ve been applying to clients websites for some time.

Currently 100,000+ osCommerce (and variations of osCommerce) pages have been infected with an iframe that points to: willysy(dot)com.

Our research finds these iframes in the title tags and at various img tag locations throughout the webpages which led us to look in the database. iframe injected near title tags

We see the code in the title tags at the top of the page, inserted as the description of the store logo, following the “images/store_logo.png” or “images/logo.gif” and other similar logo links. and also in the copyright section in many web pages:

Our suggestion is to export the entire database, download it to your local computer and search for any strings with “iframe” (no quotes) in them. A few of these iframe strings have been obfuscated, so also look for the string: document.write.

Other domains used in this attack are:


It’s certain that more will follow.

Our research indicates that most of these websites are osCommerce or an osCommerce related website. In 89% of the websites we investigated, they have left the admin folder unchanged, which means they have not followed the recommendation of renaming the admin folder. Since this is a simple process, I would tend to believe that they have not followed other security recommendations and left their websites open to an attack.

You may see entries in your log files like this:

XXX.XXX.XXX.XXX – – [08/Jul/2011:02:19:54 -0500] “GET /admin/configuration.php/login.php HTTP/1.1” 200 24492 “http://(domain removed)/admin/configuration.php/login.php” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)”

The key here is the “200” following the HTTP/1.1 string. This means the above GET request was successful.

This will be followed by:

GET /admin/configuration.php/login.php?gID=1&cID=1&action=edit HTTP/1.1″ 200 24835 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)”


“POST /admin/configuration.php/login.php?gID=1&cID=1&action=save HTTP/1.1” 302 – “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)”

To prevent this, you should:

  1. Rename the admin folder to something that does not include the word ‘admin’
  2. Depending on what version of osCommerce you’re running, you should modify the code in application_top.php (2 files) to eliminate the $PHP_SELF
  3. You should disable define_language.php and file_manager.php
  4. Use various methods to prevent the configuration.php/login.php in the URL

You may also find additional users in your administrators table. Hackers have been adding these as well. Many of them will have their own email address as well so that a request to reset a password will go to them.

Various .php backdoors and some Perl shell scripts might be added to your website as well. The hackers have been using a variety of these in order to maintain control of the website.

First, make a backup of your database. Then after all these database entries have been found and removed, you’ll have to change the password to your database as they obviously know what it is and then import your database.

All of this needs to be cleaned up.

If you need help in cleaning this up, please send an email to or call me directly at (847)833-5666


FCKEditor Attacks

I realize we’re not the first to write about this, but my intention is not to be a ground-breaking news source, but for our readers, I hope to be at least educational.

We’ve been seeing more log files, ever since we’ve been beta testing our new log analyzer, with probes for fckeditor and also editormonkey. This has led us on a journey to see why.

What we found was that many people are using editormonkey, even though it’s been “shelved” for some time. This means, no updates, nobody to fix bugs or more importantly – no security patches.

Here is a screenshot from the Editormonkey website:

Screen shot from editormonkey website

For those of you unfamiliar with FCKeditor and Editormonkey, they work with various programs like WordPress, Joomla and other Content Management Systems (CMS), to provide a more robust writing platform.

These programs were designed to bring more text editing features to web based programs.

According to the CKEditor website:

CKEditor and FCKeditor
The problem with any plugin, component, module, etc. is that they often times provide a file manager. A file manager for an editor is key so you can upload graphic files without leaving the editor. For instance, if you wanted to add a picture to something you’re writing about, you would upload it to your website and then insert into your text. A good editor will enable you to perform that task, without ever leaving the editor.

When you have multiple ways of uploading files to your website, you also introduce multiple exploits for hackers to abuse and infect your website.

Let’s see what is so bad about this.

First, let me begin by saying that if you follow our security principles, you’ll know that all software should be kept up-to-date.


Yes, that means even web based editors.

For older versions of FCKeditor, like 2.0 -> 2.2, this string is dangerous:


This allows an attacker to upload a file, like a backdoor shell script to the vulnerable website without any real “hacking” skills.

How would a hacker know you have this installed on your website?

Google is a hacker’s best friend. They can search using:


And find websites that Google has indexed and found that string.

What can you do to prevent this?

I’m glad you asked.

First, you can update your software. As posted above, FCKeditor has been renamed CKEditor. Update immediately.

Next, you can also use “security by obscurity”. In your robots.txt file you specify what the search engines index on your website. Does the world need to know what plugins you’re using in your WordPress blog?

Probably not.

You can use something like this in your robots.txt file:

# Hide certain folders from spiders
User-agent: *
Disallow: /(path to your editor folder)

We’re not big fans of relying on security by obscurity so you should also locate the config.php file. It’s usually located here:


Open it with a text editor and search for the line that looks like:

$Config[‘Enabled’] = true ;

And change “true” to “false” (no quotes). That will disable that connector.

Other safety precautions you can take is to password protect the editor folder. Usually your hosting provider will have that option in their Control Panel for your account.

You could also delete the filemanager folder altogether. This eliminates the vulnerability completely.

If you absolutely have to upload files to your website via the editor, then I suggest you pick some area of your website to designate as an upload folder, but you should know that the permissions on that upload folder have to be set to 777 (world readable/writable). Again, you are warned not to do this.

In review, always use a multi-layered strategy for website security.

  1. Keep all software updated – even editors
  2. Hide folders from search engines
  3. Hide folders by using password protection
  4. Disable potentially vulnerable functions
  5. Hire a good security company (like us!)


Fake google-analytics code

It’s rare for me to post twice in the same day, but I thought this one needed your attention.

In some infected osCommerce and WordPress sites we’ve been seeing this line of code:

< scr ipt snc=hxxp: // www. id=googleanalytics>var emob = googleanalytics;var emsk = 126853 * 4;var emsp =,0);var k = 1;var t = emob.innerHTML.split…(removed)< /scr ipt >

In the osCommerce sites it was in:


In the WordPress sites it was in:


Usually at the end of a div tag in the body of the page code. This has been noticed more and more. It used to be that the malicious code was somewhere either in the beginning or near the end of the page code.

This code works by looking like legitimate google-analytics code, but notice that in the opening script tag, that’s not a src variable. It’s snc. Which looks at first like src, but it’s not.

What the code does is replace use the id variable and replace it with a different URL and then the code at the end of the malscript sets the source for the script src with:

emob.src = emsp.substr(15)

Of the ones we’ve cleaned, so far, they’ve all pointed to:


We’ve gathered the log files for these sites and processed them through our log analyzer and found that the hackers are using file inclusion strings in already vulnerable sites to infect them.

We can remove this from your site and help protect it or, if you have your files downloaded to your PC and have already installed grepWin, you can use this regex to find and remove these strings from your website files:

Please post back here with any comments, other URLs that this script is directing to or any other pertinent information.

Thank you.


What to do if your site is showing “Cannot redeclare corelibrarieshandler” error

We’ve been seeing more infected websites that when viewed with a browser show the following:

Fatal error: Cannot redeclare corelibrarieshandler() (previously declared in /home/content/(all changed)/index.php:4) in /home/content/(all changed)/includes/defines.php on line 11

The error always appears to show the error on line 11. As of this writing google shows 3,570 results for this error message. Some of these have already been flagged with Google’s warning: “This site may harm your computer”. Some haven’t. We’ve also seen where some of the websites showing for this search term have already been cleaned.

The code that is causing this error is:

The above code is inserted into many, if not all, .php files which makes clean up a little difficult.

For this clean-up, if you don’t want us to clean it for you, you can use grepWin.

First you’ll have to download all your website files to your local computer.

Then, if you’re on Windows, you can use grepWin along with this regex search string:

<\?php\s*\/\*\*\s*\*\s*Gets some core libraries and displays a top message if required.\s*\/\*\s*\*\/\s*function CoreLibrariesHandler\(\).*?\?>

Then set grepWin to scan all files, create a backup and to scan the folder with your downloaded files in it and hit replace.

Then you can copy the new files up to your website.

You’re not finished. If you don’t close the point of entry, the hackers will be back. Many of the infections we’ve seen are either the result of stolen FTP passwords or out dated software. Some have been WordPress, Joomla, or osCommerce that have not been properly secured.

I think this will be growing more over the next few days. Update your sites now.

Please post back with a comment if you have anything to add to this or have further questions.

Thank you.


What Hackers Won’t Do for SEO

First an announcement: The number of websites we’ve cleaned just passed 75,000!

In reviewing our recent activity, I noticed a number of sites that have a certain similar characteristic – a large number of infected websites have a folder added to the named .log or .logs

The dot (.) in front of a folder name causes it to be hidden by default so many FTP programs wouldn’t show that folder.

In addition to the “hidden” folder, we also found .htaccess files with the following:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /31.php?q=$1 [L]

The part that would be different is the 31.php. Often times this was any random 2 digits, but we’ve also seen some files that were a random name:


The contents of the those randonly named .php files was always about the same:

This file was used by the hackers as the “backdoor” to the website for future infections, etc.

Inside the .log or .logs folder was another folder named the same as the infected website. Inside that folder was a file:


in the case of the folder named .log, the contents of which lead to a website that the backdoor can request new instructions or other malicious code from. In the cases where we found a .logs folder, we found the same structure, another folder named with the infected website, then a file:


The contents of which were similar to the xmlrpc.txt file, a website where the 2 digit file could get further malicious code or additional files.

Some of the websites we’ve seen listed in this xmlrpc.txt/re.xmlrpc.php are:
and many others...

This line of code is inserted somewhere in a .htm/.html/.php file:
img heigth="1" width="1" border="0" src="hxxp: //imgaaa. net/t.php?id=8021025">

usually at the very end of the file, after the closing html tag.

The hackers are using different domains in this img tag, but most of them are similar to:
( you get the idea )

and obviously the id at the end is different.

This begs the question: Why?

What’s the purpose of all of this? What are the hackers gaining by this and how are they getting in?

First, the why.

Inside many of the .log folders we’re seeing many, many hundreds of .html files for various products/services. For instance:


One common thread with these files is that they all start with h1 tags, the above text, or some other topic, all in upper case, a variety of links to more files on that same infected website and content all optimized for search engine results.

So the hackers are using this scenario to drive traffic to various websites – mostly images. What’s at those websites? Mostly we found the fake anti-virus websites waiting for the unsuspecting visitor.

Now the how.

How does this happen?

In most cases, after our log analyzers finished their work, we found that this resulted from stolen FTP credentials. In other words, a virus is on a PC. That PC has been used to FTP files to the infected website. The virus can either “sniff” the FTP traffic, and since FTP transmits all data in plain text, it’s easy for the virus to see and steal the the username and password from the traffic, or the virus steals the FTP login credentials from a file saved on the PC.

Many free FTP programs store their saved login credentials in a plain text file on the local PC. When a virus infects a computer it looks for these files and steals the information.

After the virus steals this information, it sends it to a server which then carries out the infection.

What can you do?

You can make sure that you’re running a good anti-virus program on your PC. Then make certain that it stays updated and runs full system scans everyday. I know it takes time and I know it’s a hassle, but so is cleaning up your website.

Also, if your hosting provider supports FTPS or SFTP, switch to that instead of FTP. The reason is that FTPS and SFTP send their traffic encrypted, not in plain text. This makes it much more difficult (not impossible) to sniff and steal.

To clean this up, find and remove the entire .log or .logs folder. If you have an account with many sub-domains, you’ll have to check each sub-domain or add-on domain folder as well.

  1. Using either the file manager from your hosting provider account or your
    FTP program, delete the entire .log or .logs folder.
  2. If you can download all the files from your website to your local computer, search all files for:


    and remove those files.

  3. Check all .htaccess files for the code listed above in the .htaccess content I provided.
  4. Change all FTP passwords.
  5. Update your anti-virus signatures and run a full system scan. Insist that anyone else with FTP access do the same and do not give them new passwords until they have run a full system scan with an updated anti-virus program. Ask them for the report at the end.

We recommend that each person with FTP access have their own FTP account. Also, check with your hosting provider to be sure that FTP and access logging is enabled. That way, if your site is ever infected again, you can search through the logs, or we can do it for you as part of our service, and determine who’s PC was infected, or at least how the code was inserted into your website.

If you need help cleaning up your website, please send me an email: – we’ll clean it up for you.

If you have any further comments about this infection, or questions, please post a comment.

Thank you.


The latest website infection

We’re seeing more and more obfuscated javascript infections recently.

The latest one:

(z,c,k,ru,ck,nc,q,j,b,ut,zh,pl,gl,pe,ye,v,pj,r,e,qk,pr,bi,g,n);var bo=document.createElement(gz);

deobfuscates to:

iframe setAttribute src = hxxp: //


iframe setAttribute src = hxxp://

Which are listed as suspicious by Google:

What is the current listing status for

Site is listed as suspicious – visiting this web site may harm your computer.

Part of this site was listed for suspicious activity 2 time(s) over the past 90 days.

What happened when Google visited this site?

Of the 5 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2011-04-09, and the last time suspicious content was found on this site was on 2011-04-08.
Malicious software includes 440 scripting exploit(s).


What is the current listing status for

Site is listed as suspicious – visiting this web site may harm your computer.

Part of this site was listed for suspicious activity 1 time(s) over the past 90 days.

What happened when Google visited this site?

Of the 4 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2011-04-27, and the last time suspicious content was found on this site was on 2011-04-27.
Malicious software includes 334 scripting exploit(s).

In gathering data and searching for the source of the vulnerability that leads to this infection on websites (now totaling about 38,500), there is no common denominator with the infected websites.

It doesn’t appear to be WordPress or Joomla or osCommerce or any of the other popular website packages.

It might be more stolen FTP login credentials.

If you have further information on this, please post here, or email me at

Thank you.


Let’s go phishing

A fishing buddy of mine describes fishing as, “a jerk on one end of the line, waiting for a jerk on the other end”.

As we have been “beefing-up” our phishing detection, I started thinking about my friend’s comment. Couldn’t phishing be described the same way?

We talk with people everyday who’s websites have been infected by hackers and quite often we hear, “What do these jerks want with my website?” So there is a jerk on one end of the line, waiting for a jerk (or unsuspecting person) on the other end.

Phishing as you probably know, is the act of “fooling” someone into providing their Personally Identifiable Information (PII). In the early days of phishing, you would get an email that may have had all the correct graphics to make it look legitimate, however, there would typically be common mispelled words and other grammatical errors that would indicate that something was amiss.

Now days, the emails look legitimate and so do the websites that are linked to, from the bogus emails.

You may see emails with subject lines like, “PayPal security alert”, or “Attempted change to your banking login”, in order to alarm you into action.

In this post, I’m going to educate you on what hackers do to websites to get them ready for phishing.

First, realize that when a website is compromised (hacked) by someone, they have many options:

  • They can inject a script that attempts to infect the computer of any of your visitors
  • They can store their games and other illegally obtained software on the site
  • They can add phishing files and use the compromised site to steal PII
  • Or, in worst case scenarios, they delete all the files to cover their tracks
  • For now, we’re going to focus on using compromised sites for phishing.

    When the hackers turn their attention to phishing, they want to hide their “work” from prying eyes, but yet make it widely available to their potential victims.

    How to determine if your website is being used for phishing?

    We typically find the phishing files deep inside a multiple level folder structure. It’s not unusual for us to find phishing files buried 10 sub-folders (directories) deep on a website. It’s so common that you could almost classify it as a characteristic of phishing files.

    Hackers are so determined to keep their phishing files hidden that they even protect them. We’ve found on numerous sites where the hackers have used a .htaccess file to help keep their files hidden.

    Some of the entries in an .htaccess file are:

    setenvifnocase Referer spammer=yes
    setenvifnocase Referer spammer=yes
    setenvifnocase Referer spammer=yes
    setenvifnocase Referer spammer=yes
    setenvifnocase Referer spammer=yes
    setenvifnocase Referer spam spammer=yes
    setenvifnocase Referer phish spammer=yes
    setenvifnocase Referer spammer=yes

    Order Allow,Deny
    Allow from all
    Deny from env=spammer

    Let me explain.,,, and all scan the Internet looking for phishing pages. This .htaccess says that if the referer is one of these sites, then identify that traffic as spam (spammer=yes). The Order Allow,Deny section says to allow all traffic (Allow from all), but deny any visitors previously identified as being a spammer.

    Of course these sites are not spammers, but that’s what the hacker has identified them as for their own protection. Also, the hackers believe that if someone, such as yourself, looks inside this file, you may just think it’s some security measure and leave it alone.

    If you get an email from one of the above organizations, you may want to check your website files for phishing folders.

    Some strings to search for are:

    HSBC Premier
    By United 4U
    Personal Banking Online Verification
    Lloyds TSB FullZ By GhostRideR
    Northern Rock Online
    Your mother’s maiden name
    Your Security Number
    Barclays Secure Form
    Log in to Digital Banking
    RBS Refund Form

    There are many, many others but this should get you started.

    If you have any questions about phishing, or identifying phishing files on your website, please email me at

    If you have any information about phishing that you’d like to share, please leave a comment.