[wp-hackers] Detecting the present botnet attacks

Nikola Nikolov nikolov.tmw at gmail.com
Wed Jul 10 13:37:21 UTC 2013

Hi David,

When the attacks began I started blocking users on the second incorrect
login attempt for the longest time possible via the Wordfence plugin. That
was sort of ok - but as you stated - it's a waste of server resources.

The following solution is at the WordPress end - I know that this is not
what you're really looking for, but you can take a look at it(and it might
help someone else as well).

At the end I got really annoyed with the attacks and I did a simple thing(
I'm warning you that it's probably not suitable for most of the people out
there, although it might be plausible with a filter that would automate one
part of the solution ) - I manually changed the wp-login.php file.

I know - modifying core files is not a good thing. But hey - I don't want
someone to poke at my site/server.

So my solution was to check at the top of the file for the presence of a
$_GET variable and check it's value. Basically if you go straight to
/wp-login.php you would see "Unauthorized access!" and that's it. You have
nowhere else to go and you can't do anything. If you go to
you would actually see the form. From then(that's the harder part) I had to
manually change the "action" attribute of the login form to include the
above $_GET parameter. After that the login form would work.

I'm not sure how well that's working - but I believe that this solution
works better than not using anything...

Okay - I played a bit and made this really quick and dirty mu-plugin. You
can find it here - http://pastebin.com/pTyCMd1z . Put it in your
wp-content's "mu-plugins" directory to make it run automatically. It should
have no impact on your site's performance since it's code only works on the
wp-login.php page. Once you upload the file, change the "define( ..." lines
to something that is actually more secret than the defaults.

This plugin will wp_die() (you can probably switch to just die() ) with
status 500 displaying just the "Unauthorized login" message unless you're
visiting the proper URL - with the defaults it would be "
http://mysite.com/wp-login.php?mysecretkey=myv3ry53cr37n0nc3". Some
JavaScript will then run and fix all of the login-related links and the
login form's action attribute, so that you don't have to.

Once you have that in place, just save the URL as a bookmark and that
should make things a bit easier.

I'm not sure whether the return code 500 has any effect on the attacks
intensity(like discouraging them) - I've had 93 POST and GET requests to
wp-login.php for the last 10 days - I remember that the attacks were very
intensive at some point, so it might have some minor effect.

Hope that helps,

On Wed, Jul 10, 2013 at 3:14 PM, David Anderson <david at wordshell.net> wrote:

> Hi,
> As most of us know, there are ongoing brute-force password attacks going
> on worldwide, that are distributed and hence can't be prevented with
> single-site "deny after X failed logins" heuristics. The individual IPs
> only connect to each site once or twice. We are protecting some of our
> websites with BruteProtect, but unfortunately not enough people are using
> that solution yet to make it effective - in our analysis of our logs, it
> catches about 10% of bad hosts. That's better than none, especially if a
> site gets broken into, so we'll persevere with it - and mention it so that
> others may perhaps take a look at it and help boost that figure for all the
> users!
> But regardless of that, the multiple attacks on various websites on the
> same box are causing significant resource usage - perhaps around 25% of all
> resource usage on the server in question. We'd like to kill the attacks at
> an earlier stage - before the full WordPress load completes. We're thinking
> of adding a single line of code using PHP's auto_prepend_file feature (in
> php.ini) that will immediately die if an attack pattern is detected. This
> solution has the beauty of being something we can centrally manage fairly
> easily (our webserver's configuration file is written on-the-fly by a shell
> script, including per-site PHP-options). (Adding plugins to every site
> would be much more cumbersome).
> This line would detect that the URL being visited is wp-login.php, and
> then apply some other tests. Looking at the logs we've collected from the
> attackers, we see these two patterns:
> 1) The POST payload does not include [wp-submit] => 'Log In', which you
> would have if logging in from the normal wp-login.php page.
> 2) The usernames are all one of:
> * admin
> * administrator
> * the domain name of teh website being attacked
> * {domain} (literally - presumably a bug in an earlier of the attacker's
> code)
> So, we're considering banning all those usernames from the hosted sites.
> But, it looks like we could get a quicker result by blocking based on 1)
> instead. Question: Does anyone know if that's reliable? i.e. are there
> scenarios in which a likely user POST to /wp-login.php does not include
> that field? (Note that the popular Theme My Login plugin doesn't POST to
> /wp-login.php, so differences on its login form aren't important). (Of
> course too, if someone's built some legitimate automated WP tools that
> don't include that field, then this'll break them too - but we can deal
> with that if it ever happens. I'm just interested in normal Joe User WP
> usage).
> Of course we could also combine 1) and 2) to reduce the risk. But I'm
> still interested in the answer to the question.
> Many thanks,
> David
> --
> WordShell - WordPress fast from the CLI - www.wordshell.net
> ______________________________**_________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.**com <wp-hackers at lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>

More information about the wp-hackers mailing list