Support

If your site has already been compromised it's not sufficient to simply install Admin Tools. It can't protect you if your attacker has already installed a back door to your site. Remember, Admin Tools is the bouncer at the door. If the bad guys are already in, there's no point in having a bouncer. Our plan is find them, kick 'em out and make sure they aren't coming back on our watch. Are you with me?

The first course of action is unhacking your site. The link points to a comprehensive guide. While unhacking your site I strongly suggest putting all compromised sites in Emergency Off-Line mode using Admin Tools. The reasoning behind this is complicated, so you might find a story about the incident inspiring this advice entertaining as well as informative. By now you should have realised that in such an elaborate hacking condition the only way to ensure that one compromised site won't be used to hack the other ones is making sure that the other sites are not accessible. That's what the Emergency Off-Line feature if Admin Tools is designed to do.

The next step is tightening your security. The unhacking walkthrough contains some solid advice: make sure everything is clean installed, updated and all files accounted for. It will take a while to do that (or you can pay someone to do it for you - it depends on what you have plenty, time or money). After making sure that your sites are in tip-toe shape you can install and configure Admin Tools on each site. Don't forget applying the .htaccess Maker. In case it blocks more than it should, just follow the troubleshooting advice. Please don't try to cut corners by not applying the .htaccess; it might cost you a hack.

Finally, let me note another two below the radar attacks you might suffer, even if you are using any security component.
1. If you have third party scripts, running outside of Joomla!, installed on a site's subdirectory (such as WordPress, phpBB3 and so on) do note that these are not protected by your Joomla! security extension. You have to follow the best security practices for each one of them. If they are compromised your site gets compromised as a whole. By the time the attacker manages to upload executable code or run SQL queries on your site, you're screwed.
2. Which brings me to the next point. If a site is hacked on a server, you can safely assume that all sites on the server are compromised. It would require a very skilful system administrator to secure a server to prevent that from happening. The problem is that such admins are hard to get, expensive and their solutions do secure the server but have a toll on the ease of use and sometimes on performance. As a result very few hosts perform such security optimisations. On the rest of them (the majority) a hacked site on the server can hack other sites on the server. The best you can do to minimise (but not nullify!) the risk is having all files owned by the FTP, not the Apache, user and use the FTP layer. But remember, this solution can backfire if a hacker infiltrates your site as they will now have your FTP passwords too.

Restoring from a backup is not enough for two reasons:

1. It is common for smart hackers to infiltrate your site and merely put a back-door script on it. Then they lay low for a while before doing something which might trigger your suspicion. As a result, all your backups are compromised. Restoring a backup simply restores the backdoor as well. Remember Brian's final words from the article I linked in my last reply:

Just because you keep your server secure and your software up to date you may have been exploited yesterday, ready to be hacked tomorrow.

2. Restoring a backup merely overwrites the files which were present in the backup with the backed up versions. This is good if a. you have a trusted, clean backup and b. the attacker only modified, not added any files. Experience tells me that the first is questionable and the second is improbable. Therefore all that restoring a backup before identifying how you were hacked does is wipe out the evidence which would let you investigate the attack and does nothing, nada, zilch to fix your site in most of the cases.

To be honest, i saw results (of protection) before doing the htaccess process so i just stopped before that.

Big mistake. In the first hacker m.o. I described above, the attacker drops an executable backdoor script (usually a C99 / r57shell variant) in your site. Usually the give it an innocuous name –like README.php, config.php, includes.php and so on– and shove it deep down your directory structure. From that point all they need to "pwn" your site is a web browser from a random Internet café at the other side of the city. The premise of this attack is that their back-door script is executable. Our .htaccess Maker makes sure that no executable PHP file on your site is directly accessible unless you explicitly allow it to run. Having configured .htaccess Maker properly would fend off such attacks.

The only reason was i feared having issues with the layout and wiring of the sites and having to fix each on of them!

I hate being pedantic all the time, but this is a very typical reaction :) You have to remember that for every boring minute you spend securing your site you are gaining one day in utter frustration and a lot of money unhacking your site. Security has a relatively small immediate cost compared to the alternative, as you can now tell anybody interested.

how much do you think this should cost me to outsource the whole issue ?

First let me clarify that I don't have the time to take freelancing work. What I am about to say is based on prices I've heard from other consultants. Depending on the extent of the hack it may cost upwards of 600$ per site. If all of your sites have been compromised with the same method, I guess you're looking at an expense in the area of $5,000 or more. That's why I first said that unhacking your site depends on what you have plenty, time or money.

The steps look in the correct order.

I would add a Step 0: Enabled Emergency Off-Line mode on all of your sites. Don't leave them on-linen and don't simply use Joomla!'s off-line mode. Use Admin Tools' Emergency Off-Line.

In step 3 I would also suggest two additional substeps:
i. Replace all core Joomla! files, even if Joomla! is up to date.
ii. Re-install all extensions (components, modules, plugins and templates) even if they are up-to-date.
These two substeps should help you in making make sure that there are no compromised files left behind.

Your plan seems quite good.

Regarding your question about #3, Joomla! core files are all files shipped in the Joomla! full installation ZIP file available from http://www.joomla.org/download.html. If a file is in there, it's a "core" file. If it's not but was installed by a third party extension it's considered an extension file. If it is external to Joomla! and its extensions (e.g. a phpBB3 installation in a subdirectory) it's a non-Joomla! file.

And now the million dollar question:

What happens if i am not managing a site on my fps and the client is using an outdated script/cms - if the shell/malicious file is uploaded there in that account, will it affect my websites????

The answer is a disappointing "maybe yes, maybe not". It depends on the VPS setup, as well as the ownership and permissions of each folder and file we're talking about. For example, if you are using suPHP this can't happen unless the other site's account has directories with 0777 permissions and the home directory has 0755 instead of 0700 permissions. There are so many factors involved that nobody can give a reply to that except for the person who has set up the server, provided that he knew what he was doing. The latter is not always the case, especially in the era of "we do it all for you" prepackaged setup scripts which allow people with near-zero knowledge set up servers.