A brute-force attack is what it sounds like: an automated script tries username and password combinations against your login page, over and over, until one works. It is unglamorous, extremely common and almost entirely automated. Most WordPress sites see attempts within days of going live, however obscure the site is.
Why it works at all
It succeeds only where three conditions line up: weak or reused passwords, predictable usernames (admin being the classic), and no limit on how many attempts a script can make. Remove any one of these and a brute-force attack stops being a real threat, no matter how many guesses a bot throws at the site.
A variation called credential stuffing does not guess at all. It tries real email and password pairs leaked from other services, betting that you reused one. That is why a password that is strong but reused is still a risk.
What actually stops it
- A unique, strong password on every account. This alone defeats the vast majority of attempts. A password manager makes it painless.
- No "admin" username. It is the first guess in every automated run. Create an administrator with a different name, move the content across and delete the old account.
- Limited login attempts. Locking out an address after a handful of failures turns an unlimited guessing game into a dead end.
- Two-factor authentication. Even a correctly guessed or leaked password is useless without the second factor.
- Rate limiting at the server or firewall. It blocks the flood of requests before they reach WordPress, which also protects server resources. A tool such as fail2ban can ban an address that keeps failing; the firewall guide covers where this fits.
Do not forget XML-RPC
The login form is not the only door. WordPress also accepts logins through xmlrpc.php, and that interface can try many passwords in a single request, which sidesteps simple per-request limits. If you do not use the mobile app, Jetpack features or other tools that rely on XML-RPC, block or disable it. Many sites never need it.
Usernames are easier to find than you think
WordPress can reveal usernames to anyone who asks. A request like /?author=1 redirects to an author page that contains the login name, and the REST API lists users at /wp-json/wp/v2/users. Attackers use both to build a list before they start guessing. Give each account a display name different from its login name, and consider restricting the user listing if no theme or plugin needs it public.
What does not really help
Renaming wp-login.php or hiding the login page stops only the crudest bots that check nothing but the default address. It is a minor speed bump rather than protection, and other doors such as XML-RPC remain. It is fine as an extra layer, not as the plan.
How to tell if you are being targeted
Look at your server's access log for many POST requests to wp-login.php from a spread of IP addresses. From the command line, this lists the busiest sources:
grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
A short spike is normal background noise on the internet. A sustained, high-volume pattern is worth acting on. Also look at the other end: a successful login from an unfamiliar address, or an administrator you did not create, means a guess succeeded. In that case follow the five-minute hack check.
SiftWP's weekly scan looks for configuration that makes brute-force attacks more likely to succeed, including administrator accounts without strong, unique credentials, as part of its regular pass over the site. It runs over SSH with no plugin, so it works even when you have locked the login page down. Login limits and two-factor authentication still belong in your WordPress setup or at your host.