Fake Googlebot WordPress Login Bruteforce

… sigh.

A few hours ago we started seeing an interesting trend. A highly distributed set of clients is attempting to authenticate to WordPress sites using a very distinct pattern. Captures and initial analysis below.

Nothing particularly out of the ordinary here at first glance. The source IPs are be coming from a large number of hosting providers, including OVH (go figure), Rackspace, AWS, and O2Switch. Each requests spoofs a Googlebot user agent, which initially makes sense as an evasion tactic, until you realize that a). verifying Google’s botnet range is trivial, and b). there’s no reason Googlebot should be hitting that URL, so developing an IPS signature is trivial. The other interesting tidbit we see is the ‘redirect_to’ param, which is a URL that WP core uses as part of the login process, contains the string ‘tes1a0’, to which I could find no references for having any meaning. Perhaps it’s just a marker for success?

I’m going to keep some packet captures running on a few honeypots and see if there’s any correlation in source address or target host. In the meantime, I’ve shot off a quick note to SANS ISC; I’d be interested to see if this behavior gets widely reported in the next few days. I also posted a signature for this behavior for FreeWAF.

Update 1: After groking through some honeypot logs, the earliest I’ve seen this looks like 1100 UTC on January 13th (give or take a few hours). Because we first noticed this pattern while investigating an unrelated issue, it looks like the low-and-slow approach used by this botnet has been successful at avoiding detection so far.

Update 2: Started doing some brief analysis of honeypot logs from the last few hours. In one sample, 347 unique client IPs were captured. The most common one seen is an AWS instance, followed by servers from OVH and French service provider VeePee, all with more than 100 attempts; a number of sampled addresses were only captured once. The credentials used vary by domain, and seem targeted to users associated with the installation, indicating that iteration had previously been performed prior to the launch of the authentication traffic we’re seeing now.