Cyber-Investigations: A Brute Force Attack on Word Press
They came in the morning. Over 800 emails, John said. Looking like the ones in the picture below. John was concerned but relieved that he’d enabled the WordPress plugin “Limit Login Attempts.” He said his company’s web site was in no immediate danger because he’d already replaced the default password with a very strong random string. Although brute force attacks can send thousands of messages trying every word in the dictionary (and more) to guess the password, the odds of guessing that string so easily are extremely low. John observed that multiple logins on common accounts such as “test”, “user” and “admin” had already been attempted.
Moreover, John reset the account lockout after three failed attempts to 96 hours, limiting the number of retries available to any one attacking IP address. This alone would foil attacks from any one person’s computer, but not necessarily against a botnet. Botnets are made up of thousands or even millions of computers that have been compromised by previous hacking campaigns. It is common for botnets to be rented out in cybercrime underground markets. In this case, the botnet controller system was probably running a script to perform the brute force attack against a list of domains.
John still had some questions: “Since 11:35 this morning until now we’ve had a brute force attack on our Apps site. We are now up to over 2300 attempts. I’ve purged WPengine cache. I’ve hidden [our authentication plug-in’s] password login form but still getting failed attempts which tells me that they can still see the login form. Unless they use another way to bypass the form and try the login with code(?).”
If the login attempts weren’t coming from the web site’s login screen, then where? John eventually determined with the help of hosting provider WP Engine that the attacks were not coming via the web browser protocols, but instead through the FTP or SSH back-end file transfer protocols. These login attempts were directed not at the login form but at a PHP file exposed to enable web services, or to configure the site.
ANALYSIS
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.
POST SCRIPT
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.”
RELATED POSTS
You might also like to read