“File appears to be malicious or unsafe”. A dozen or so of those messages in an email from a client’s website is not what I want to see of an afternoon, but it’s exactly what arrived in my inbox recently.
It has been years since we saw a hacked client site, largely because we take multiple steps to ensure they are not soft targets.
These include:
- a global DNS and security provider which can block bad actors from trying to scan or use automated attacks against the sites it protects
- maintenance plans to keep sites up to date with security patches and updates, which ensures they are not sitting around with known, published vulnerabilities
- active monitoring software which watches the site’s files for any suspicious changes – this is almost always the first sign of a breach
It was the third item which alerted us to the recent client incident – a bunch of modified files on their website, both in the site theme and in the content management system. The active monitoring software quickly detected these files contained suspicious code and raised the alarm.
Within a couple of minutes of receiving this notification, we had locked the site down so there was no external access to it. We then set about finding exactly what had happened, so we could close whatever vulnerability had been exploited.
What happened?
This client was up to date with their site maintenance, yet the site was still compromised.
It turned out there was no vulnerability in the site’s files or plugins; one of the site’s administrators had their password breached. With administrator access, someone had logged in and installed their own malicious plugin, complete with a kit to compromise a lot of random files to provide remote access and execution.
In a sense this was good news, because the root cause was clear and the fix relatively easy – we could roll back to the most recent backup which was less than 24 hours old, and change all the site passwords.
We also took a couple of steps to further harden the site against future attacks, which we would strongly recommend to anyone.
The first and simplest was to require MFA (multi-factor authentication) for all administrators, which goes a long way towards stopping password breaches turning into website breaches. Even if your password does get leaked somehow, an attacker can’t log in unless they’ve also nabbed your MFA app, most commonly on your phone but also available on desktop computers.
The second hardening measure we took was to block overseas access to the site’s login page, since none of the administrators are based overseas and the overwhelming majority of would-be attackers are. This is a really effective way to stop password guessing attempts (also called brute force attacks).
Fortunately there was no serious harm done here – no sensitive client information stolen or transactions intercepted – but this incident was a good reminder that even with regular maintenance and care, a site can be vulnerable if someone with legit access has their password breached through some other means.
MFA might be a small inconvenience when you go to log in to your site, but there’s a good reason your bank and other important platforms all require it as a matter of course these days.
If you’d like to secure or harden your site, or you’d like a second opinion on your security setup, please get in touch – we’re always happy to help.
