How Brute Force Attacks Work and How to Stop Them

Every WordPress site with a public login page is being probed right now. Automated bots continuously attempt to log in using lists of stolen credentials, common passwords, and username variations. It's not targeted — it's industrial-scale automation. Brute force is one of the most common attack vectors covered in the WordPress security checklist.

What a brute force attack looks like

A typical attack hits /wp-login.php hundreds or thousands of times per hour:

POST /wp-login.php  admin / password
POST /wp-login.php  admin / password123
POST /wp-login.php  admin / admin
POST /wp-login.php  admin / yoursite.com
POST /wp-login.php  administrator / password

The bots rotate through credential lists derived from previous data breaches. If your password was ever leaked in any breach (HaveIBeenPwned is a good check), it's in those lists.

Why default WordPress is vulnerable

WordPress shows a helpful error message that tells an attacker whether the username or the password was wrong. This lets attackers first enumerate valid usernames, then focus password attacks on confirmed accounts.

It also exposes /wp-login.php at a predictable URL and has no rate limiting by default.

The WO Security Shield approach

WO Security Shield applies layered brute-force protection:

Layer 1: IP-based lockout

After a configurable number of failed attempts (default: 5), the attacking IP is locked out for a configurable duration. Repeat offenders can be permanently blocked.

Layer 2: Custom login URL

Move /wp-login.php to a custom URL like /my-secret-login. Bots don't know the new URL, so they can't even attempt to log in. Direct access to the real /wp-login.php returns 404.

Layer 3: Two-factor authentication

Even if an attacker somehow gets a valid password, 2FA means they still can't log in. WO Security Shield supports both TOTP (authenticator apps like Google Authenticator) and email-based OTP. See our complete 2FA setup guide for step-by-step instructions.

Layer 4: reCAPTCHA

Google reCAPTCHA v2 on the login form stops automated bots that can't solve challenges.

Layer 5: Username enumeration blocking

Disables ?author=N redirects and the REST API user endpoint, so attackers can't discover valid usernames in the first place.

Emergency unlock

One concern with IP-based lockouts: what if you lock yourself out? WO Security Shield generates a unique emergency unlock token at activation. Visit {your-login-url}?wss_unlock=TOKEN to instantly clear the lockout for your IP.

Setting up 2FA

Go to your WordPress profile page, scroll to "Two-Factor Authentication" and click "Enable TOTP". Scan the QR code with Google Authenticator or Authy. From that point, every login requires both your password and the current 6-digit code.

For a deeper look at login-specific hardening, read our guide on WordPress login page security. Learn more about securing your WordPress login at wosecurity.com.

The Anatomy of a WordPress Brute Force Attack

Understanding how these attacks actually work helps you defend against them more effectively.

Phase 1: Username Discovery

Before trying passwords, attackers need valid usernames. Common methods:

• Author enumeration: Visiting ?author=1, ?author=2, etc. — WordPress redirects to /author/username/, revealing the login name
• REST API: /wp-json/wp/v2/users returns usernames by default
• Login error messages: "Invalid username" vs "Incorrect password" tells the attacker whether the username exists

WO Security Shield blocks all three vectors — enumeration, REST API user endpoint, and generic login error messages.

Phase 2: Password Spraying

Sophisticated attackers don't try thousands of passwords against one account (that's easily detected). Instead they:

1. Collect 100+ valid usernames across target sites
2. Try the same common password against all accounts
3. Wait, then try the next password

This "low and slow" approach stays under rate limits. That's why per-account lockouts are more effective than per-IP limits alone.

Phase 3: XML-RPC Amplification

The system.multicall method in WordPress XML-RPC allows hundreds of login attempts in a single HTTP request:

<methodCall>
  <methodName>system.multicall</methodName>
  <params><param><value><array><data>
    <value><struct>
      <member><name>methodName</name><value>wp.getUsersBlogs</value></member>
      <member><name>params</name><value><array><data>
        <value>admin</value><value>password1</value>
      </data></array></value></member>
    </struct></value>
    <value><struct>
      <member><name>methodName</name><value>wp.getUsersBlogs</value></member>
      <member><name>params</name><value><array><data>
        <value>admin</value><value>password2</value>
      </data></array></value></member>
    </struct></value>
    <!-- Hundreds more... -->
  </data></array></value></param></params>
</methodCall>

One request, 500 password attempts. This bypasses most rate limiting that only counts HTTP requests. Disabling XML-RPC entirely is the best defence unless you specifically need it.

Advanced Protection Strategies

Geo-blocking

If your business only serves certain regions, consider blocking login attempts from countries where you have no users. WO Security Shield supports country-level blocking at the firewall level.

Password Policy Enforcement

Force strong passwords for all users:

• Minimum 12 characters
• Reject passwords found in breach databases
• WO Security Shield enforces strong password requirements on password changes

Login URL Hardening

Moving your login page from /wp-login.php to a custom URL (e.g., /my-secure-login) eliminates 90%+ of automated brute force bots, which are hardcoded to target the default path.

Session Management

After securing login:

• Set session expiry to 24 hours for admins (not "remember me" for 14 days)
• Force re-authentication for sensitive operations
• Monitor for concurrent sessions from different IPs

Measuring the Impact

After implementing brute force protection, you should see:

• Failed login attempts: Drops from hundreds/day to near-zero
• Server load: Noticeable reduction, especially if you were getting XML-RPC attacks
• Activity log: Clean audit trail instead of noise from attack attempts

Check your WO Security Shield Activity Log to see the before/after difference. Most sites see a 95%+ reduction in malicious login traffic within the first week.