Cyber-Investigations: A Brute Force Attack on Word Press
Summing up all the information, I concluded that this doesn’t appear to be a serious incident. However, John should circulate the following report to his company’s management and technical staff for additional feedback.
Assets attacked: [Name and describe web sites] – each is a separate WordPress virtual machine (VM) instance.
Nature of attack: Brute force attack (over 2000 attempts each) from multiple IP addresses. Attack is attempting to access the wpengine.php file over FTP using common usernames such as “test” and “admin” and passwords. This attack bypasses the site’s authentication plug-in because it accesses a back end file. If the authentication attempt succeeds, however, the attacker could modify the PHP file and gain control of the site.
Risk: The consequences that might result if the attack succeeds differ depending on whether it’s a “random” attack or a “targeted” attack.
- Random attack risk: It’s normal for hackers called “botnet herders” to try and continually expand the fleet of compromised computers (“bots”) they control. If the company’s assets (WordPress VM instances running in the cloud) are incorporated into a botnet they could be used to distribute spam, distribute malware, or host phishing content. This could affect subscribers, partners, or prospects viewing the company’s site. If people were adversely impacted and the fact was publicized it could negatively affect the company’s reputation and customer relationships – this is especially concerning for companies in the security business or with a trusted brand to protect. It’s also likely that hackers “data mine” the list of bots and sites they control and put the interesting ones up for sale. From there, the company’s web site could fall into the hands of an unscrupulous competitor, hacktivist or other adversary. What had been a “random automated attack” could transform into a more dangerous “targeted attack.”
- Targeted attack risk: The site could be vandalized or infected in an attempt to sabotage the company’s reputation in any number of vicious, slanderous or deviously creative ways. If the site has any functions whereby it interacts with customers, targeted attacks could be directed against those customers as well. The attack could leave a trail of broken customer relationships and even lawsuits in its wake.
Counter-measures: We’ve already deployed a very strong (unguessable password not in the dictionary) and installed the “limit login attempts” WordPress plug-in. The plug-in is configured to send us email about failed login attempts so we’ll know if the attacks resume. We’ve configured the plug-in to lock out failed authentication attempts for 96 hours. We’ve emailed WordPress support, and they have turned on a firewall rule to block botnet access to our affected assets.
Follow up: We need to monitor to see if the attacks stop and/or the counter-measures result in problems for us or our audience to access our site, or other false positives, higher bills, or lower performance.
Bottom line: This was probably a random attack by botnet herders, not a targeted attack. If the attacks stop or are greatly reduced due to the counter-measures, we need not investigate further. Otherwise we can look deeper into the matter. Doing that well might require working with a threat intelligence company that could identify the specific botnet involved, search for any “chatter” among hacking groups about our company and try to identify the source, motivation and probable intent of past and future attacks.
Lesson learned: Threats are real, not theoretical. Configuring strong security settings is necessary to block unexpected attacks. Having an ability to monitor the counter-measures is required to tighten defenses at need. Staff must be alert and available to monitor. Attacks can come through unexpected vectors bypassing planned counter-measures (e.g. 2 factor authentication) suggesting the need for periodic penetration testing if the risk warrants.
WP Engine Support wrote the following to John:
“I’ve dug into this issue you were seeing and applied a setting on our platform to block traffic from bots attempting to force entry into your site. This way we are able to block traffic that causes these “brute force logins” using a rule applied to our server. These attacks have become more and more common with WordPress itself and WP Engine has taken the steps to ensure security for our customers.”
John asked me: “They write that they changed a server setting to prevent bot attempts. Why the heck isn’t this their default for all their customers?”
I answered: “They might have just blocked access to the PHP file through their firewall. Or, they may have a reverse proxy with category-based URL blocking to identify IP addresses blacklisted as belonging to “botnets.” Or some combination of a firewall rule and reverse proxy setting. These settings may result in false positives (access from legitimate users or programs blocked) and calls to your company or WP Engine’s help desk. That may be why they don’t turn the “anti-botnet” settings on by default. The settings may also reduce the performance of the firewall or reverse proxy due to additional packet inspection required.”