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:
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.
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.
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:
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:
Selecting phpMyAdmin from your console takes you to the next step:
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 backupFTP 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:
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:
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.
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:
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.