Brute Force Uptick

Okay, so just to clarify, am I actually breaking this news? No. Definitely not. But my automated log scanner picked up a jump in malicious activity yesterday on my network, so it’s worth taking a closer look. First, we see the jump in numbers:

Note that addresses have been lazily obfuscated but do not actually belong to the same class C, though some do share common ASNs (and some do indeed share a common class C). Wonderful, so let’s take a look at the log itself (a small sample is presented below for brevity):

This pattern of 5 IPs making quick attacks and rotating out repeats throughout the set of the botnet, possibly as an attempt to avoid brute force mitigation. Also, notice the user agent string?  Yeah, hooray for modern web infrastructure relying on arbitrary data on which non-repudiation cannot be established.

Looking at the timeline of the attacks, we see it lasted about an hour and a half:

Wait, that’s interesting. What’s that first hit doing? A GET is sent to wp-login.php with no referer. Let’s look at all of that IP’s traffic:

This pattern indicates that X.X.X.141 functions as a crawler, searching for targets. Once the bot’s victim is identified, the labor of distributed brute force is assigned to other members of the attacking group, with each attacking host working in serial, again, likely as an attempt to avoid detection.

So what’s a sysadmin to do? Most people will resort to plugins for this sort of defense, but most brute force detection plugins come packaged as an all-in-one framework. I’m partial to a WAF approach with mod_security:

4 thoughts on “Brute Force Uptick

    1. Thanks, I forgot to cite that. The mod_security rules posted above are lifted from http://kb.liquidweb.com/wordpress-modsecurity-rules/. They’re intended to demonstrate one method of using a WAF to defend against a WordPress brute force login attack, not as a production-ready copypasta. In my specific situation, I use homebrew scripting and automation to add offending IPs to my server’s firewall, blocking traffic at the NIC, rather than having it processed by my HTTP daemon. Most people would argue that this is overkill, and I would tend to agree, but I’m root and IdowhatIwant.

  1. So I’m curious. Is the botnet automatically stopping login attempts from individual IPs after five instances or is that your security software kicking in? What you’ve written and what the log shows suggests the former, but I haven’t played enough with this kind of thing to be sure.

    1. Matt- this behavior actually appears to be a function of the botnet itself, not any configurations on my part. The scanner I mentioned above is a passive analysis tool.

Leave a Reply

Your email address will not be published. Required fields are marked *