Support

I recommend reading the following page on our site: https://www.akeebabackup.com/documentation/walkthroughs/unhacking-your-site-index-html.html

If they got into cPanel it's game over on many levels.

At this point you should consider everything compromised:

• cPanel logins, obviously.
• DNS, if it's managed through cPanel.
• All FTP / SFTP accounts. Remember to check for any SSH keys added.
• All email accounts.
• All sites (files and database).
• Any third party services you had stored credentials for in your sites.

If you have this kind of compromise you need to torch everything to the ground and start from scratch.

This kind of attack is nowhere near as novel or widespread as Sucuri wants you to believe. My friend and Joomla co-founder Brian Teeman had written about an identical attack he encountered back in 2009. Admin Tools can already do something about it. If you read Sucuri's post carefully you will see that they themselves admit that the malicious ico file (or any other static media file) can do sod all by itself since it's not an executable file. Its malicious code is executed by a new or modified .php file. Guess what the PHP File Change Scanner is designed to do? Tell you about which files are unexpectedly created or modified! Therefore what you ask me to do has been in place since the first incarnation of the PHP File Change Scanner back in September 2010, nearly 10 years ago.

If you feel exceedingly paranoid you can tell the PHP File Change Scanner to treat ICO files as potential PHP executables and scan them regardless. That's why it's configurable.  If you really want to go down that path login to your site's backend, go to Components, Admin Tools, PHP File Change Scanner, Options. Find the “Extensions to scan” further down the page and set it to php, phps, phtml, php3, inc, ico, ICO

Doing that will make the scanning very, very slow BUT it will scan the contents of ico files for malicious PHP code. Still, I think this is unnecessary because malicious code under a non-executable prefix is by and of itself inert. There is a new or modified, executable PHP file to call that code. The code these hacking kits generate does increase the Threat Score. So, Admin Tools out of the box will notify you about these attacks.

The problem is that if your site was compromised BEFORE the first PHP File Change Scanner you very likely marked the hacked file as safe. In this case, adding the .ico files to the report is unlikely to make any difference as you're not going to be poring over hundreds of reported files after the very first run of the PHP File Change Scanner on a site. You'll still mark it as safe. That's why the documentation tells you that you should only do the first run on a site you can verify is not hacked to begin with.

I'd also like to make it clear that Admin Tools is designed to prevent your site from being compromised with an attack initiated by someone or something interacting with the Joomla site itself. It cannot protect you against someone who, as you said, compromised your hosting account. When that happens it's game over. Usually, the problem is that the password was already compromised, too short, hadn't been changed in a very long while, noted down outside of encrypted storage or a combination thereof. The only reasonable protection you have against that is you following best practices:

• Never reuse passwords. Ever.
• Do not store your password anywhere except a reputable, encrypted password manager. Exception: written on a piece of paper which is stored in a safe.
• Lock the password manager right after you use your login information.
• Use the password manager to generate random, long (32+ character) passwords consisting of alphanumeric characters and symbols. Do not create your own passwords. Humans don't do random even when we type "random" characters on a keyboard.
• Change your passwords often.
• ALWAYS use an encrypted connection to your server with a valid TLS certificate or an otherwise verified encryption certificate. That is to say use HTTPS, not HTTP. Use SFTP or FTPS, not FTP.

Sorry, I must have misunderstood your request for changes. I thought you were under the impression that we had not implemented something yet and / or that it was possible to protect cPanel itself. It was not a blowback, I was just explaining what is and what is not possible. I am also very direct in my communication which might be misconstrued as aggressive. I don't do aggressive. I do direct.

My question was whether AdminToolsPro had a means to suppress the injections themselves, but I take your answer to that as 'no,' but you never advertised it as such and I am not disappointed at all with the software. Rather, the opposite. AdminTools Pro is doing more than I could have possibly expected.

This is a misleading question to ask yourself because it lacks context. You still don't know where the attack came from. You have made an assumption but you don't have hard evidence. So let's start with where.

If the compromise came from a vulnerability in Joomla or one of its extensions running inside Joomla it is possible to configure Admin Tools in such a way as to prevent it. If your site was compromised because your hosting account or, worse, your server or your entire host network was compromised you can't prevent it. If the attack doesn't come through the Joomla application, inside of which Admin Tools runs, it cannot be stopped by Admin Tools or any other security exception. Likewise, if a file is uploaded by an extension which circumvents the Joomla file upload protections (either by disabling them or by having a directly web accessible .php file) the upload cannot be stopped by Admin Tools.

But that's a third of the story. There are another two layers of protection.

The .htaccess Maker will prevent direct web access to pretty much everything except static (non-executable) media, Joomla's index.php files and whatever you explicitly allow. Depending on what the attacker did it's conceivable that they did upload malicious files but can go nowhere with them because they cannot execute them.

The third layer is the PHP File Change Scanner. This is meant to help you figure out if you did get hacked by something which didn't go through the Joomla application. As the article you linked points out, the malicious files are inert. They need a change in a system .php file (usually index.php) to include the malicious code. However, such a change will be caught by the PHP File Change Scanner. That's what I was trying to tell you before when I was explaining why you don't need to add ICO files to the scanned extensions list.

That's why I am saying that your question is misleading. Even if you see the files on your site, Admin Tools may be already protecting you from the attack.

I'm not sure they successfully hacked our 32-character random username and our 32-character random cPanel password - my guess is the break happens at the hosting level (a bigger problem, and it seems specific to cPanel). And I agree, it's not novel - it's widespread and well-documented. 

Objection on two counts :)

Brute forcing a password is rarely an issue unless you use a compromised or short password with a relatively short username. This doesn't mean your credentials can't leak. For example FileZilla on Windows was notorious for a while for including what is basically spyware. Even before that and long after that, it would store credentials unencrypted in a deterministic location. Needless to say, malware was hoovering it up and use it to automatically hack sites. All it takes is one person dropping the ball on operational security for credentials to be compromised. Again, though, you are not sure that this is how the attacker got access.

I also object the assertion that it's a cPanel issue per se. All my sites and our business site are on cPanel. No such incidents, like with millions of sites hosted using cPanel. Now, if your host is using an outdated version of cPanel with known vulnerabilities that's another issue. But making the assertion that cPanel itself is definitively vulnerable is a stretch and unwarranted.

I do understand your frustration dealing with an attack that seems to span multiple hosting accounts. I'd recommend finding out where the attack came from before leaping to conclusions. Confirmation bias is a thing.

Hm, if your root account was compromised I would look at how the server itself was configured and whether cPanel updates were installed before I spent a considerable amount of time moving and reconfiguring dozens of sites. Anyway, it's not my place to tell you what to do. You know your business needs better than I do and we've definitely gone beyond our support scope :)

Have a great day!