| Security

Good day, if you are reading this, I hope you will take a few moments to really consider the need for a good incident management plan for your website. Ask yourself, What WOULD you do if you were hacked?

Here's a few 'common' responses, I've heard:

  • I'd just restore it
  • I would remove the hacked code
  • I don't know
  • I would change hosts
While there's a few others, these are the one's that make me scratch my head. Just playing along for a second, "I'd just restore it" - that implies you have a backup, and you know where its at. And you know it has not been corrupted.

The same mindset applies to the "I would remove the hacked code", and so on. My question is how would you find it? I'm not suggesting you couldn't, I'm asking "HOW".

What each of these responses lack is a structured response plan.

In this article, I want to lay out a simple response plan that will help you get back online and hopefully result at a minimum the reporting of the bad guys to their ISP.

Stage 1 : You realize you've been hacked

In this stage, you probably are feeling a range of emotions, including anger, frustration, possibly some measure of fear. After a short time this will subsided.
However in the mean time its important that you set all that aside - and get busy.
Tip: Understand that while you are justifiably angry, that emotion shouldn't stand in your way.
The first thing you want is the LOG files. It is very important for many reasons such as evidence, remediation and so on.
In a CPANEL enabled host, you can retrieve those very quickly. In your CPANEL control panel, scroll down till you see LOGS, then click Raw Access Logs.

You should see something like this:

Help! I've been hacked! - Now what?
Under the Download Current HTTP Access logs, you should see a number of zip files. Grab those and pull them OFF the server. Many times, however you may not have clicked the 'Archive Logs' check box as shown above - If not, finish reading this article and go do that right now. If you don't there will not be much in the way of log files.

The reason for this is that in almost all cases, the log files will contain a footprint of what the culprit did, and where they may have put stuff. You might see a FTP log as well. My suggestion GRAB every log file you can.

Write down or take a snap shot image of the time stamp on the files. You'll need that.

Next you will, if possible, need to log in to your administrative console and turn Joomla's built in MAINTENANCE mode on - this is to prevent further Damage/Infection. Again, depending on the hack you may not be able to. If not do the right thing, create a quicky html page, and post it as index.html in the root of the site. This will prevent spreading any infection.

If you do happen to have a good backup, then its a simple matter of restoring.

CAUTION: Restoring doesn't mean you wiped out the bad guys..

Our next step is to gather up the Database, usually obtained by visiting phpMyAdmin in your cpanel. You're likely to see something like this:

Help! I've been hacked! - Now what?
Selecting phpMyAdmin from your console takes you to the next step:

Help! I've been hacked! - Now what?

Select your Database and click EXPORT - this will bring up several options, take the defaults, scroll the bottom, name the DB and select .GZ (compression)

This will download the database file.

Stage 2: now you're starting to get somewhere

This next step is dangerous. If you've been hacked, you will likely have something or many very bad and contagious things on the site. They could impact and infect your computer. So the following is presented as an academic exercise and should not be tried unless you have the proper safeguards in place. IF THERE IS ANY DOUBT - THEN  DO NOT HANDLE ANYTHING ELSE ON THE SERVER.  Contact me at joomlarescue.com for cleanup.

In other words, I am NOT recommending you try this. This has the potential to destroy your local machines data, install some kind of trojan horse or other dangerous stuff on your computer.

Download the local files, scan them with the most up to date Virus scanner. I recommend Kapersky - by doing so you will have a semi clean version of the files.  If you have a backup, make sure its on a different media.

Method 1: Restoration from a KNOWN GOOD backup 

FTP into your site, (again ONLY if you have a KNOWN GOOD backup) - DELETE all the files in the public_html directory. This will ensure you have wiped out the bad stuff. If you restore, you may not write over the files. A recent example is a client came to us at JoomlaRescue.com and the site had been hit pretty hard. The hacker had  put in a file called gifimg.php, which of course,  restoring a backup, would not have fixed the issue.

Thus wiping the entire sub-directory has the effect of cleaning up and starting over. Many variables can come in to play, such as a root kit, or inability to restore, etc. So this is a tough option, but sometimes the best. Be sure and look ABOVE public_html for anything that should not be there. As a recent example I saw, there was a payload called Fungible.php above the public folder - that was being used to launch the attack.

If you don't have any custom hacks, to Joomla itself, then the next step ensures that you are at the latest.

Once you restore - download (do not depend on your current copy) the latest Joomla for your series (i.e. 1.5) and unzip. Upload ALL the sub-directories, and index.php and index2.php in the root of the site. This will make sure you have not only the latest and greatest, but also clean copies.

Method 2: Clean up existing files and restore

Not having a clean backup will lead you to the next choice - that is  cleaning existing code. This is a tedious and time consuming process. In essence it follows a few steps:

  1. Make a second copy of the files you pull down - this is your failsafe copy - keeping it in tact
  2. Run a virus scan on the files (first copy) and remove any malware, scripts, bad stuff..
  3. Copy over the fresh and latest copy of Joomla
  4. DETERMINE (this is the hard part) if there is hidden stuff a virus scanner won't detect (there's a lot of these that fall into this category)
  5. Remove anything found in 4
  6. Rescan
If you are successful, then remove all the files from the public_html folder, and copy your cleaned files up - once you are certain its good. Delete all local copies.

As you can see Method 2 is a very dangerous option...AGAIN - DO NOT ATTEMPT ANY OF THIS IF YOU FEEL IT WILL RESULT IN PERMANENT DATA LOSS.

Stage 3: What happened and how do we prevent it

This part is important, because if you were hacked, it means there is a vulnerability of some sort on the site. And it needs to be addressed.

My best advice is to review the following and remedy it:
  1. Update ALL extensions - even if they are not suspect (CAUTION: If you have a highly modified extension, the updating will wipe out your modifications.)
  2. Check joomla.org to see if any of your extensions are on the vulnerable list
  3. Consult with your hosting company to determine if any ports are open
  4. Check your Apache, Linux, MySQl and other server components to ensure they are not suspect
  5. Check permissions

Remember our log files from earlier? Look at the time stamp on your original files. That time is going to help you narrow down the entries in your logs. Let's say you discover a Chinese hacker has been at work, the logs and time stamp match. This is a clue and evidence you need.

Block that IP, in fact, if you don't need any traffic from those countries to your site, I suggest you block the entire country. If you do need traffic, then block that IP in your .htaccess file.

Stage 4: Preventing future drama

I prefer a Drama free site, so should you. What could you have done to prevent this from happening? How can you be better prepared in the future.


  • Make patching your site, as regular as brushing your teeth - check it daily - it only takes a few minutes
  • Review your logs DAILY, if its a busy site, review them more often. After a time you'll learn how your normal traffic looks and you'll be able to spot bad traffic
  • If a patch is made available - then - apply it
[Note from author: A reader PM'ed Cory and disagreed with the concept of reviewing your logs daily, due to Good Hackers not leaving log traces. Conceptually that is true, IF the hacker thinks to write over the logs, which many times in my experience they do not. However, other good reasons to review are general site health. Logs include, Apache logs, Errors logs, Visitor and FTP logs. For instance, a site I removed a hacker from just this week, did not clean out the FTP logs...and we were able to locate them by IP. Therefore "Quod erat demonstrandum" - Thus it is proven that you should do a regular log review
Thanks to the reader for prompting us to clarify this for the readership

Reaction to future events

Get a plan in place for reacting to a future event. This should include:

  • A current backup of your site and your database
  • All license keys for extensions (if applicable)
  • All URL's of extension developers
  • User name and passwords for site, database and third party sites
  • A current virus scanner
  • Pad or paper and a pen
  • USB Key (for storing suspect code)
  • Technical support information for your host
  • Make sure you turn on LOG archving
  • Make sure (when you finish reading this) that your site is patched properly

There are many more items that go into a Disaster Preparation Guide, but that is beyond the scope of this article.

Again, preperation is the key to preventing an attack and if you are attacked, keep in mind that time is of essence when it comes to restoration, removal and remediation of the bad guys. Lastly, my disclaimer, DO NOT ATTEMPT TO REPAIR AND CLEAN YOUR SITE IF YOU ARE IN THE LEAST UNSURE OF WHAT TO DO.

Each hack is different and presents a unique situation thus this article has been presented as an educational tool and you are fully responsible for any action you take from it or do not take from it.