Case Studies: XML-RPC Brute Force Attack and Hacked Website
No website is 100% hack-proof. Nothing on the internet is 100% hack-proof. But that doesn’t mean you should give up and accept the inevitable. There are safety measures you can take to help prevent your site from a brute force attack and becoming an unanticipated business expense. It’s much easier, and far less expensive, to keep your website maintained and as safe as possible than it is to clean up and/or replace a hacked website.
Basically, a “brute force attack” is a hacking method that uses excessively forceful attempts at guessing passwords, login credentials, and access to your accounts. Brute force attacks have been around for years and remains a popular tactic with hackers, especially since people tend to use unsafe usernames and passwords (i.e. common words found in a dictionary). There are various types of brute force attacks, all with the same goal in mind: gaining access to your website, and any online account you use, to steal personal data, spread malware, or hijack a system for malicious activity. Sometimes it’s simply to ruin a company’s reputation.
Unfortunately, a good block of my time this entire month has been spent on cleaning up hacked websites. In one case, the site owner had no idea that his site had been hacked until he tried to log in.
On another site, it was the hosting provider that notified their client by email that they were taking their site offline due to malware. Typically, when a hosting provider takes your site offline it means that your site has been infected long enough for the hackers to do serious damage to your site as well as to other sites on the same server, and also to the innocent bystanders visiting your site.
Two examples of a half dozen different types of hacked websites I’ve seen this month:
CASE 1:
PROBLEM: The hacker set up a username and password for himself (as the admin) and deleted the website owner’s username and password. The site owner had absolutely no idea his site had been completely taken over by the hacker. Everything looked fine when he looked at his site. It wasn’t until he tried to log into the site that he discovered he couldn’t even get to the login screen. Once I got into the site I saw something I’ve never seen before; the entire WordPress dashboard had been replaced by massive quantities of code, mostly directing visitors to the website to the hacker’s various websites.
RESOLVED: In this particular case the server needed to be wiped clean and the site restored.
This wouldn’t have been a huge problem if he had a clean backup copy of his website that was not stored on the server, and if he had any idea as to when the site was hacked. He had neither, and his hosting provider did not have a backup copy. He hadn’t logged into his site in about a year, which also told me that he had not been keeping up with any/all security upgrades. Even if his web host had a backup, there was no way he would know how far back in the archives he needed to go in order to restore a clean copy.
Not all hosting providers will have backup copies of their customer’s websites, especially those on a shared server. It’s not their responsibility to keep backup copies. When they do make backups, it’s for THEIR convenience; not yours. Furthermore, if they do have a backup copy, they do not guarantee that restoring the site from their backup will work properly and that your site will look and function the way it did before something went wrong.
TIP: Check your site frequently and do not depend on your hosting company to keep backup copies of your website.
CASE 2:
PROBLEM: Website was under heavy Brute Force attack; XML-RPC DDoS and also the garden variety type of hack attempt.
RESOLVED: In this case, I had to reach out to the web hosting company’s tech support as this site is usings VPS hosting, as opposed to shared hosting. I requested that they insert a RewriteRule in the .htaccess file and also temporarily turn off the xmlrpc.php file. It took them a couple of days to get this task done, which isn’t bad considering that one (or more) of their servers was also under DDoS attack so it was All Hands on Deck at this hosting provider.
Is there a downside to turning off the XML-RPC? The only one that I’m aware of is that by doing so, you will not be able to use mobile apps or remote connections to publish content on your website. However, not everyone needs this ability enabled. If you do decide to turn this off and you notice that some of your plugins no longer work, you will need to turn it back on again.
Turning XML-RPC on and off like a water faucet can be done by using a plugin such as “Manage XML-RPC,” or “Disable XML-RPC,” but I prefer not to use any more plugins than absolutely necessary. If you would rather not add yet another plugin to your site, you can add the following order deny,allow rule to your .htaccess file. You can also harden this further by including a deny from all along with the allow from 111.111.111.111 (insert your IP address).
Order deny,allow or the order allow,deny rules can also be — and should also be — used to protect other files on your site, such as protecting the most important WordPress core file: wp-config.php.
As an added measure of security, and while I waited for tech support to get back to me, I installed a plugin with a country blocking feature and proceeded to block every country on the planet!
As you see in the below snapshot of the activity screen, the above steps completely stopped the brute force attempts.
Brief Explanation of Complex Attacks and Brute Force Attacks
A complex attack is when a visitor makes a request to your site that is specifically crafted to exploit your site or find a vulnerability they can later exploit. Not keeping up with the required upgrades makes it easy for hackers to find vulnerabilities.
Brute force attacks are username/password-guessing attempts. Oddly enough, I still see people using the default “admin” username that gets set up during the initial WordPress installation when you don’t change it as you’re doing the installation. If you forget to change the dealt username be sure to IMMEDIATELY after the install. Also remember to use strong passwords, and not include words that can be found in the dictionary.
TIP: Do Not use the same username and passwords for multiple accounts. A POSSIBLE explanation for this massive increase in brute force attacks may be linked to a database of hacked credentials. This database contained over 1.4 BILLION username/password pairs.
Can You Tell if Your Website has been Hacked?