My Joomla Website Was Hacked Heres What I Did Next

When my Joomla website was hacked with rogue javascript, it was done unobtrusively: no massive deleting of files, or pwned claims on the home page.

So it was obviously done for a hidden, longer term purpose, rather than to take the site down, and that worried me too. Could it be rescued?

This is a long post, detailing the steps I took to trace the problem, minimise the damage and rescue the website, so the steps I took are linked in this step-by-step list:

Hacked Joomla Website: What I Did, Step-by-Step

  1. How I noticed something was wrong
  2. What is Microsoft Remote Data Services Data Control?
  3. HTTP Debugging with Fiddler
  4. Yourgoogleanalytics and Statscounter??
  5. Checking the Javascript files
  6. Preventing further infection
  7. Telling the Web Hosting Provider
  8. Checking my Desktop PC
  9. Securing the Web Hosting Account
  10. Tracking Down Hacking Attempts
  11. Online Tests for Malware in a Website
  12. Removing Googles This site may harm your computer Warning
  13. Links: Website Security
  14. Joomla Security Links

How I Noticed Something Was Wrong

Because I usually use Firefox, which hadnt had any problems with the site, I only realised my site was hacked when I tested a new page in Internet Explorer 8. There was an error message I hadnt seen before.

The message said, This website wants to run the following add-on: Remote Data Services Data Control from Microsoft Corporation. If you trust the website and the add-on and want to allow it to run.

Now this website and I have been through stormy times together. If Ive ever made a lot of sales calls, spent a whole day cold calling at trade shows, or Im at home with flu and a hyperactive toddler, thats the day the site will crash. True to form, I had just applied to some new affiliate programs and was about to stop work for the day and start cooking for my sons 4th birthday party. So did I trust this website? Erm

At first, I thought maybe there was a script I hadnt noticed in some content I had just added from Wikipedia, so I checked the source code, but I didnt see anything unusual there. I browsed to other pages on the same website, and then back again, and didnt see it again. I wondered if it was something left over from my MSN Internet Explorer home page, so I went back to that and it wasnt there. Then I went back to the same page, and there it was again.


What Is Microsoft Remote Data Services Data Control?

I tried searching for Remote Data Services Data Control, assuming it was some kind of Microsoft script, and found a post on a Microsoft Security newsgroup leading to this Can You Spot the Fake? post on Hosts News, warning,

any time you see that warning Remote Data Services Data Control watch out! this is NOT from Microsoft! This is the generic warning IE7 throws up when an exploit is trying to enter the system.

Starting to feel alarmed, I following a trackback from Hosts News to the post that saved my day (though ruining my night first  ) : the Little Big Tomatoes post The one with the evil jscript on my blog.

HTTP Debugging With Fiddler

The hacked site there appeared to be WordPress based, but the errors looked similar. The post showed a useful free web debugging tool called Fiddler, which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and fiddle with incoming or outgoing data. Theres an instruction video for Fiddler here.

So I downloaded Fiddler and ran it. Id never run Fiddler before, but when I loaded the web page again web link in Internet Explorer, Fiddler picked it up automatically. So I looked down the list of http requests, and in the middle of my normal HTTP requests (site name blocked out) I found these (dont go to any URLs listed here!):

Your googleanalytics And Statscounter???

Looking down the list, I saw statscounter and did a double take: I do use Statcounter for website statistics, but here its misspelt, and I hadnt used Google Analytics at all, so that was another red flag. Some Google Adsense HTTP requests appeared around the same time, but it just looked dodgy. Was this really something Google Adsense did?

The next requests, for were completely unfamiliar, and called PHP scripts called redir.php and in.php, whose names alone sounded worrying. I wondered: shouldnt hackers have called them something less sinister, perhaps kittens.php and flowers.php? Or had they just stopped pretending? Most of all, I wondered what was going on with my website.

I should say at this point that the website often needs work and doesnt get much traffic (a good thing, for once).  In  the words of Courtney Tuttle, its a time sucking money pit.   But I leave my money pits on my own terms, thanks.
So there werent any visitors right then and I thought I had a bit more time to figure out what was going on.

I searched for yourgoogleanalytics, and found nothing for, but there were posts about on Googles support forum from a site using Microsoft software, with a useful answer about rogue javascript added to external .js files:

Have you looked at the code in menus/milonic_src.js ?

What do you suppose is the long line starting with this: document.write(unescape(%3C%69%66%72%61%6D%65%20%73%72%63%3D ?

I suggest you check all of your external javascript js files for code tampering.

More reading turned up a couple more examples of obfuscated javascript being added to js files, creating invisible (0 x 0 dimensional) iframes, which would then call php files on other domains to pull in dodgy code such as trojan downloaders.

Andrew Martins security blog lists the domain as being used for Money Mule Recruiting, and gives an example of Money Mule Recruiting on a related domain:

During the trial period (1 month), you will be paid 2000 USD per month
while working on average 3 hours per day, Monday-Friday, plus 5
commission from every transactions or task received and processed. The
salary will be sent in the form of wire transfer directly to your
account. After the trial period your base pay salary will go up to
3,500USD per month, plus 5 commission.

I couldnt see my visitors falling for that, so I hoped if it was hacked it was for money mule recruitment rather than the various trojans and downloaders that were mentioned on other sites as possibilities.

Checking The Javascript Files

My site has a lot of javascript files, so I thought the best place to start looking for this would be the file Fiddler reported just before the odd domain names: moscom.js, moscom.jquery.js, and moscom.ui.tabs.js, which were all part of a comments extension I had installed a few weeks earlier.

So I downloaded those three files, and checked them one by one in Notepad, and when I got to the top of moscom.jquery.js, there it was:

document.write(unescape('%3C%69%66%72%61%6D%65%20%73 ... and so on.

I didnt know if the file had always been like that, but that line of code appeared before the header section with the package and file names and looked very suspicious, so that was enough for me: it was clear the website had been hacked.

I felt awful, thinking of people visiting my website, and being at risk from trojans and viruses.

Back to list

Preventing Further Infection

I didnt want to be infecting my visitors with malicious downloads, so I took the site offline via the Global Configuration settings.

I set off a backup of the database and files, in case uninstalling or repairing anything might trigger off some kind of malicious code. Then I noticed that the backup program itself was trying to access the malicious files, so I stopped it and downloaded the files and database separately.

Telling The Web Hosting Provider

Then I emailed my web hosting provider, told them the situation, and apologised for the inconvenience. I told them that I had identified the infected files and taken the website offline to visitors, and that I would be uninstalling the infected components and upgrading everything that needed upgrading.

I also asked them to let me know if they could please check for anything they knew of that could have got the javascript into the site, so I could prevent it from happening again.

I was pretty nervous about this, having heard of other hosts deactivating hacked accounts, and I stared at the backups, willing them to go faster

That didnt work. My web hosts were really helpful though, and sent me this reply:

It appears that your site has been subject to an attack via a method known as script injection. Typically, this works by forcing a site to execute code when it was expecting to process another input, fake .txt files are often used for this purpose.

Because script injection attacks the site code itself, it is able to completely avoid webserver security. Unfortunately, some content management systems (especially older versions of Joomla) are extremely susceptible to this form of attack.

Heres the best way to get your site back up and running:

  1. Begin by clearing out your public_html directory, ensuring no anomalous files or hidden files are left, this way you know that any backdoors the hacker might have left in are completely eradicated.
  2. Change any passwords relating to the site, along with the ftp password.
  3. At this point we can turn scripting back on for you as the hackers entryway is now gone.
  4. Restore the site from your last known good backup.

If you feel confident removing this infection by hand, please inform us when the site is completely clean and we will turn it back on for you. However, if the infection does recur, we would ask that you completely clear the public_html directory before we reactivate the site again.

I would also suggest contacting the author of the script as it appears there maybe some security issues with the code.

Script injection? Id heard of cross site scripting, and SQL injection (see the Bobby Tables cartoon about this), but not script injection. A quick look at the Wikipedia page told me that script injection (or code injection) is the more general name for the type of website hacking that adds extra code to a computer program, and can be accomplished using cross site scripting or SQL injection, among other methods.

Back to list

Checking My Desktop PC

Id like to say the next thing I did was to run the virus and spyware checker on my local PC. But in fact, I changed all my hosting accounts FTP and database passwords, and then thought, What if I have  keylogger spyware on my local PC? Then I ran the virus and spyware checker on my desktop PC and changed my passwords all over again.

When your website has been hacked, your desktop PCs security is easy to overlook (apparently!), but can be crucial. This post from Brian Teemans blog discusses why its important to consider keylogging trojans and viruses when dealing with hacked Joomla sites.

Checking on the Joomla security forums (the Joomla 1.0.x security forum and the Joomla 1.5.x security forum), I found advice to check the desktop PC with several different antivirus and spyware tools, as each of them might miss something different.

I was able to run AVG antivirus, PC Tools Anti-virus, and Lavasofts Ad-Aware. I also tried Kaspersky, but it wouldnt install because it found remnants of an old AVG version, which I couldnt find and couldnt uninstall.

Some more recommended security tools can be found listed here:

Free Virus Checkers

  • AVG free anti virus
  • House Call
  • Bit Defender
  • Kaspersky
  • F-Secure
  • PC Tools free antivirus for Windows XP and Vista

I ran the quick check first, then the thorough ones, but my desktop PC was apparently ok.

I also discovered Secunias free check for vulnerable software on desktop computers.

Back to list

Securing The Web Hosting Account

Just in case, I had changed the FTP and database passwords again, because it was easy to do. Looking through the files, I didnt find any others that were infected, but wasnt convinced they were safe either. I didnt see anything else like the encrypted Javascript, but neither do I know every line of code like the back of my hand.

So I decided that in the long run it might be quicker to take the drastic route. I uninstalled the infected component first, then deleted all the files. While the files were deleting, I used phpMyAdmin to export a text file of the database, and I searched it for anything I could think of that had been out of place so far.

Finding The Vulnerabilities

Obviously, I wanted to avoid this happening again, so it would help to know how the hackers got in.

Id added extra code to my php.ini and .htaccess files that was recommended on the Joomla Security forums for blocking common exploits, so Id thought my site would be safer than most, but apparently part of it wasnt. So where was the problem, and how could I track it down?

The first place I looked was in the new component with the infected files. The infected files had the same date stamp as the others from the same component, so either they were infected on the day I installed them, or the date of hacking had been hidden. So I checked the same file in the installation package, and the rogue javascript wasnt there.

I emailed the author anyway, as advised by my web host, and eventually received a reply telling me not to store my files with permissions set to world writable. Ok, thats valid advice, except that wasnt what happened and I dont know why he thought it was.

Another place where I have often seen hacking attempts is the Friendly URLs list of my Search Engine Friendly (SEF) URLs program. When hacking attempts arrive via the browser URL, they are not known URLs, so the SEF program makes FURLs for them. In the past Ive often checked through these to see which components are being targeted, but this time Id recently cleared them out and deleted the invalid FURLS. So I didnt find anything there.

The next thing I did was to download the access and error logs from my web hosting server. All I found from the error logs was that one of my graphics files was missing. The access logs were long text files, but only went back to about 5 days after I installed the files that became infected.

I started looking back through them. Ive seen SQL injection attempts in my access logs in the past, and there was one almost immediately in the most recent log file. But when I looked up references to SQL injection in the component that was targeted, the attack I saw was known and the vulnerability had been patched many versions previously. I contacted the author and he confirmed this (although not long afterwards they did produce a new security release). I also didnt see any administrator activity or unusual file accesses in the log entries around it.

I found lots of hacking attempts by the bot libwww-perl, which is often used for automated hacking attempts. Many were targeting Community Builder, which I hadnt seen targeted before, and many were bringing up my page not found page.

I continued trawling through the logs, finding nothing that looked successful. Occasionally, the infected files appeared when I didnt think they should have done. Eventually, the log files ended, leaving me with that half a week gap.

I changed tack and itemised the components in the website to see what needed upgrading.

Joomla itself was up to date, but Community Builder was known to have an exploit, and I had put off upgrading it because the new version required PHP 5, and I had only had PHP 4.4.7 on my server. In the meantime, however, my web hosts had installed a capability to switch hosting accounts to the upgraded PHP version.