More on the W32/Kuluoz malware attack

A short time ago, I wrote about a malware attack in which hacked sites were being used to spread the W32/Kuluoz malware. Kuluoz is a password-stealing Trojan; when it’s installed, it scans your password files for Web browsers, password wallets, and so on looking for bank, PayPal, eBay, FTP, and other sites. People infected with Kuluoz may see their bank accounts emptied, their PayPal accounts drained, and if they use FTP to manage Web sites, their Web sites may be infected with the same malware.

Since I first wrote about it, the attack has changed and grown a lot more aggressive.

I saw the first sign of this attack on November 26 of last year. At the time, the attack was still quite crude: the victim would receive an email claiming to be from FedEx (though the body copy of the email said UPS) that had a message saying a package could not be delivered, and the victim would have to click a link to print out a receipt to pick the package up.

The link, of course, went to a hacked Web site being used to spread the malware. Clicking on the link would download a copy of W32/Kuluoz.B, regardless of what kind of computer the user was using. The first infected link I saw was

http://elbosquedelaherrezuela.com/wp-content/plugins/akismet/track.php?c003

hosted on Spanish Web host Arsys. The compromised site was running an outdated copy of WordPress; it has since been pulled down by the host.

In the time between last November and this March, the attack grew more sophisticated. The emails attempting to lure marks to hacked sites got more polished, and grew to resemble actual FedEx emails quite closely. The malware downloaders placed on hacked sites changed; they now examine the browser’s “user agent,” a header that tells a Web site what kind of computer you are using. If you’re on a Mac or Linux computer, you see a bogus “404 not found” error; only if you are on a vulnerable Windows browser does the hacked site download malware. And the malware itself changed rapidly as well; VirusTotal identified the first malware as W32/Kuluoz, but later downloads, with different file sizes and MD5 hashes, are identified as W32/Kuluoz.B or W32/Kuluoz.3.


Since I wrote the report last March, the attack has ramped up significantly and changed again.

At first, in November and December, I averaged 6 emails a month trying to get me to click on links. Now I’m seeing an average of more than 15 of these emails per day.

The emails themselves have changed, too. The fake FedEx emails, though I still get them occasionally, have become quite rare. Instead, the new wave of attacks involves emails that look like American Airlines ticket confirmation emails:

Needless to say, if you get an email that looks like this, DO NOT click on the link.


Right now, there is a hack attack of unprecedented scope and tenacity going on against WordPress and Joomla sites. The attack uses tens of thousands of compromised PCs to try to log in to WordPress and Joomla sites with the username “admin” and a vast number of common passwords. The attack is so severe that some Web hosting companies are reporting that WordPress and Joomla sites on their servers are slow to respond or not loading at all.

I believe that those hack attacks are related to the W32/Kuluoz malware distribution.

I don’t have any direct proof of that. The people attacking WordPress and Joomla sites are covering their tracks well, using botnets and IP spoofing to carry out the attacks.

But the circumstantial evidence seems strong. So far, every single compromised site I’ve seen that’s hosting the Kuluoz downloaders is running WordPress or Joomla. As time has gone on, the number of infected WordPress and Joomla sites has scaled rapidly. The recent wave of emails trying to lure people to infected sites coincides with the ramping up of attacks on WordPress and Joomla sites.

None of this is incontrovertible evidence. It could be coincidence–two different organized crime gangs attacking the same kinds of sites at the same time and ramping up their efforts coincidentally. But my gut says they’re related.


One of the most frustrating parts of this problem, for me, has been how slow Web hosting companies are to respond to reports that their systems have been penetrated and they are hosting computer malware.

I’ve compiled a list of statistics about infected Web hosting companies. Since November 26, I’ve started keeping track of which Web hosting companies are affected by the attack, and how long they’ve taken to remove a malware dropper once they’ve been notified it exists.

Not all Web hosts are created equal. Here, for example, is a graph showing the number of malware infected Web sites I’ve seen on various Web hosts since November, with the Web hosts identified by Spamcop:

The worst of the worst of the lot in terms of sheer number of virus droppers hosted, by a large margin, is GoDaddy.

Now, some ISPs host more Web sites than others, so if all ISPs were equally vigilant (or equally lax) about security you would expect to see larger hosting companies hosting more viruses than smaller companies. But this graph shows that isn’t really how it goes. Hostgator is larger than most the other hosting companies listed here, but has only a small number of malware-infected sites. Dreamhost and OVH are disproportionately represented for their size by a significant margin.


Another place where hosting companies are not created equal is in how speedily they remove malware droppers once they’re notified. The best Web hosting companies will do this within 24-48 hours, which to my mind is still quite a long time to leave a malware dropper active. When I’ve complained to Hostgator, arsys.es, and Lunarpages, for example, they’ve typically taken action quite quickly.

On the other side of the coin, some Web hosting companies take months to remove malware droppers…or don’t remove them at all.

I don’t know if it’s because they are easily fooled by the phony 404 errors or if they simply don’t care, but a number of Web hosting companies on this list appear unwilling or unable to deal with malware-infected sites at all.

The worst of these are Dreamhost (which has not removed one single malware site from its servers–every single one I’ve notified them of, without exception, is still active as of the time of writing this), GoDaddy (which used to be one of the top most responsive Web hosting companies, but no more; sites that they are notified of typically remain active on their servers for months, with one site I notified them of last December finally being taken down this April), OVH (which, like Dreamhost, appears not to deal with malware-infected sites at all), PrivateDNS.com (a site they were notified of in January is still active and spreading malware as of the time of writing this), and, sadly, Bluehost (which keeps emailing me to say the problem is resolved but the malware droppers remain active on their servers nonetheless).

Other ISPs on the Walk of Shame include 1 and 1 (which typically won’t remove a malware dropper until I’ve emailed them three or four times), Peer 1 (which has several malware droppers active for two months or more), and Calpop (which typically leaves malware droppers live for about six weeks after being notified).


Now it’s time for the practical bit.

If you have a WordPress or Joomla Web site, what can you do to keep it secure?

The two most important things you can do are to use very, very strong admin passwords and keep on top of security updates religiously. When a security update for a popular Web package is released, organized crime gangs will examine it and then roll the security holes it fixes into their automated exploit tools, because they know that most people don’t install them right away. If you don’t install a security patch within a day or two of its release, you run the risk of being pwn3d.

So, here’s a quick list of dos and don’ts to run a WordPress or Joomla site:

DO

  • Use strong passwords.
  • Install updates immediately.
  • Consider locking down your /wp-admin or Joomla admin directories with an .htaccess file that does not permit access without a password. If you don’t know how to use .htaccess files, there are some plugins that can do this for you. A WordPress plugin that can lock down your wp-admin directory is Bulletproof Security. A similar Joomla plugin is JHackGuard.
  • If you have more than one WordPress site, install InfiniteWP. This is a WordPress administration console that will notify you by email when any component of any of your WordPress sites needs to be updated, and allow you to update all your sites with one button click. It’s free.
  • If you create your own WordPress or Joomla themes, consider removing the WordPress or Joomla footers. Automated tools are used to scan for these so that the bad guys know what sites to attack.
  • Make sure you remove the /install directories when you install any CMS. (Joomla requires you to do this.)
  • Use a Web host that is proactive about security and responds quickly to abuse complaints.

DO NOT:

  • Assume you don’t have to worry about security because you have a tiny little site that nobody visits. The organized crime groups don’t care what your site is or how much traffic it gets. They use automatic tools that search through hundreds of thousands of Web sites a day searching for vulnerable sites. If you are vulnerable, you will eventually be cracked.
  • Leave your plugins or themes directories indexable. If you don’t know what that means, the easiest way to make sure you’re not indexable is to create an empty file called index.html in your plugins directory and your themes directory. This will keep people from getting a list of all the files in those directories, which they can use to search for vulnerabilities.
  • Set up a WordPress or Joomla Web site and then just walk away from it. If you are not actively maintaining it, take it down.

12 thoughts on “More on the W32/Kuluoz malware attack

  1. How would I detect if a WordPress site is infected? My Makerspace has a tiny little site that nobody visits, we don’t know how recent our updates are, and while we use it, I’m not sure how actively we are maintaining it. On DreamHost. Sounds like we hit the “DON’T” trifecta.

    • Typically, the attackers drop a PHP file whose name is a period followed by several random letters and numbers (such as .w6zfvb.php) in the /wp-content directory (on WordPress) or the /components directory (on Joomla). Starting today, I’ve also seen it in the /images directory on either type of site. You may have to configure your FTP program to show invisible files to see it.

      Additionally, the hackers may tamper with other files and/or install back door SSH shells, which may be present anywhere on the site, including one level up from your WWW or public_html directory if it’s writable.

      I saw some early hacked WP sites where the malicious PHP script was located in the akismet directory in the plugins directory, but I haven’t seen that recently.

  2. How would I detect if a WordPress site is infected? My Makerspace has a tiny little site that nobody visits, we don’t know how recent our updates are, and while we use it, I’m not sure how actively we are maintaining it. On DreamHost. Sounds like we hit the “DON’T” trifecta.

  3. Typically, the attackers drop a PHP file whose name is a period followed by several random letters and numbers (such as .w6zfvb.php) in the /wp-content directory (on WordPress) or the /components directory (on Joomla). Starting today, I’ve also seen it in the /images directory on either type of site. You may have to configure your FTP program to show invisible files to see it.

    Additionally, the hackers may tamper with other files and/or install back door SSH shells, which may be present anywhere on the site, including one level up from your WWW or public_html directory if it’s writable.

    I saw some early hacked WP sites where the malicious PHP script was located in the akismet directory in the plugins directory, but I haven’t seen that recently.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.