A digital ocean of bots

Last week I noticed yet another ongoing brute-force attack against our managed WordPress hosting. The botnet is very low key and each bot connects on average only once per day. Up until now, I’ve collected in the ballpark of 3100 unique bots.

The rule it triggered was (as usual) repeated login failures from a specific user-agent:

188.166.3.175 - - [24/Mar/2019:03:44:02 +0100] "GET /wp-login.php HTTP/1.1" 200 3000 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
188.166.3.175 - - [24/Mar/2019:03:44:02 +0100] "POST /wp-login.php HTTP/1.1" 403 2936 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
188.166.3.175 - - [24/Mar/2019:03:44:03 +0100] "POST /xmlrpc.php HTTP/1.1" 403 2936 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

The user-agent of choice for this particular botnet is: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0". However, the attack has one major flaw as it sends an empty referer with all POST requests. For that reason, every login attempt from this botnet received a 403 forbidden in return from my servers thanks to preexisting rules.

Please refer to the following post for an example on how to restrict access to wp-login.php or xmlrpc.php: An insignificant WordPress brute-force attack.

Attack of the clouds

This time around the attacks are not originating from the usual suspects, but from your favorite cloud providers. Of the 3111 collected bots, the following cloud providers provided 32% of the compromised hosts:

• Digital Ocean: 16.43%
• Amazon: 11.57%
• Google: 4.17%

Unsurprisingly, a lot of these hosts are running compromised WordPress installations. One would presume that the botnet also adds any additionally successfully “brute-forced” WordPress installation to its rank. However, the list of compromised hosts is by no means limited to WordPress installations.

But the cloud is more secure, right?

Only marketing people refer to somebody else’s server as “the cloud”. When you’re renting a VPS instance you’re supposed to secure and maintain it after clicking that big shiny “Create Server” button. You know, that geeky stuff your on-premise IT department used to take care off before you moved everything off to the cloud and fired them that is.

The complete list of compromised IP addresses is available from the following repository.