A new customer called us a few hours ago, and told us that his website was really slow. He told us that his website was hacked, and that his hosting company “fixed” the problem, but after they “fixed” the problem, his website became super slow. We thought that it might be a simple thing as enabling the System Cache plugin, but when we visited the website, we knew that there was something wrong…
It took, on average, 35 seconds to load a page on his website. Enabling caching fixed the problem, but 35 seconds without the cache? There must be something terribly wrong with the website, especially when taking into account that the whole website consists of a handful of pages (and each page has just 3 modules).
Our usual suspect, in this case, is a heavy query somewhere that is slowing down the whole website, so we printed all the queries that were running on the homepage, and then we started running each and every query on phpMyAdmin. To our surprise, all queries executed in milliseconds! Which means that what’s causing the problem is something else…
We thought that it might be a DNS issue, so we added the following code to the beginning of the index.php (which is located under the root directory of the website):
if ($_SERVER['REMOTE_ADDR'] == '[OUR IP]'){
die('Hello itoctopus!');
}
We uploaded the index.php file, and we loaded the page, and it loaded instantly, which proves that there is no DNS issue whatsoever…
We started thinking, could it be something wrong in the .htaccess file causing the issue? So we just renamed the .htaccess file to htaccess.old, and tried to load the page (after reverting the change that we did in the previous step, of course), but the page still took more than 30 seconds to load.
What could it be?
As a last resort, we checked the HTML source code of the page, maybe there’s an iframe somewhere that is delaying the whole loading of the page? We didn’t see an iframe, but what we did see was many hidden links to malicious websites! Aha, the website was still hacked! With that knowledge, we used our easy method to quickly discover which Joomla file(s) was(were) hacked, and we had an immediate winner! It was the application.php file located under the includes directory. The application.php file had a block of code (that was injected) that was using curl to retrieve content from a (very slow) malicious website located far, far away!
We removed the curl code and the website became, as we expected, super fast! Problem solved!
But what should one learn from this experience?
Well, there are two lessons learned here:
- Never, ever dismiss the idea that the website is still hacked when your hosting company tells you that it’s fixed – especially when your hosting company tells you that it’s fixed. First of all, it’s not the responsibility of the hosting company to fix your website, second of all, support personnel in hosting companies consists of, at best, system administrators, who may or may not have the required skills to fix your website, and who may or may not care about your website as much as you do.
-
Extreme slowness in loading time might be a sign that the website is hacked. This is almost 100% true when the website in question is a very simple website that consists of a few pages/modules.
Now, if your website is extremely slow, we suggest you check if it’s hacked or not, and if you feel that you need some experts’ help, then just contact us! We’re experts in Joomla security, we’re very professional, our rates are very affordable, and we know that we can fix your website!
[…] a long time to load, and then eventually it was displaying a blank screen. We first thought that his website was hacked, but then, when we enabled error reporting, we saw the following error on Firefox: “This Page […]
[…] remember reading our post that states that slowness in Joomla might be the sign of a hacked website, so you do all the necessary checks, and you rule that out. “Might it be my host?”, you […]
[…] yesterday evening and told us that his website was extremely slow to load. Our first guess was that it was hacked, but it was not; his website was very clean. What could it […]
[…] Changes to the application.php or framework.php files, mainly adding some malicious content from a remote website, thus infecting your visitors’ machines with malware and slowing down your whole website. […]
[…] immediately thought that the website was hacked (since extreme slowness is a sign of a compromised website) but it wasn’t. The website was perferctly clean. We then thought, it might be a firewall […]