{"id":595,"date":"2026-06-12T16:17:11","date_gmt":"2026-06-29T11:16:44","guid":{"rendered":"https:\/\/brutefort.com\/blog\/how-bots-attack-wordpress\/"},"modified":"2026-09-03T09:04:01","modified_gmt":"2026-09-03T09:04:01","slug":"how-bots-attack-wordpress","status":"publish","type":"post","link":"https:\/\/brutefort.com\/blog\/how-bots-attack-wordpress\/","title":{"rendered":"How Bots Attack WordPress Sites (And How to Stop Them)"},"content":{"rendered":"\n
\"Binary
Photo by Pixabay from Pexels<\/figcaption><\/figure>\n\n\n\n

Nobody is sitting at a keyboard trying to guess your password. That’s the part most site owners get wrong when they picture an attack. Attacks against WordPress sites are almost entirely automated.<\/p>\n\n\n\n

It’s not personal, and it’s not because your site looks vulnerable. Bots \u2014 scripts running on networks of compromised servers \u2014 scan millions of sites at once, probing the same paths and trying the same credential lists on every one. No human is watching. No human needs to.<\/p>\n\n\n\n

Understanding how bots operate shows exactly why certain defenses work and others don’t. Bots have predictable behavior, and that predictability is their weakness. This guide walks through each stage of a typical attack and the setting that shuts it down.<\/p>\n\n\n\n

Quick Answer:<\/strong> Bot attacks follow four predictable steps: find your login page, test credentials at scale, distribute attempts to dodge detection, then exploit any successful login. A custom login URL breaks step one. Rate limiting breaks step two. Together, they stop the vast majority of automated attacks before they get anywhere.<\/p>\n\n\n\n

Step 1: Finding Your Login Page<\/h2>\n\n\n\n

Bots don’t need to guess where your login page is. WordPress installs it at \/wp-login.php<\/code> on every site. A bot scanning a range of IP addresses or a list of domains just appends that path and checks for a valid login form. If it finds one, the site goes into the attack queue.<\/p>\n\n\n\n

This discovery phase is completely silent from your side. No error, no slowdown, no alert. Your site just gets logged in a database somewhere, and the credential-testing phase begins.<\/p>\n\n\n\n

Step 2: Testing Credentials at Scale<\/h2>\n\n\n\n

Once a valid login page is confirmed, bots start submitting credential pairs. Most start with the username admin<\/strong> \u2014 still the most common WordPress username on older installs. From there they cycle through password lists: common passwords first, then lists pulled from public data breaches.<\/p>\n\n\n\n

Speed depends on the bot and your server’s response time, but hundreds of attempts per minute is typical. Without rate limiting, WordPress accepts each attempt, checks it, returns a failure, and waits for the next one. Indefinitely.<\/p>\n\n\n\n

\"Server
Photo by Manuel Geissinger from Pexels<\/figcaption><\/figure>\n\n\n\n

Step 3: Distributing the Attack to Avoid Detection<\/h2>\n\n\n\n

More sophisticated bots distribute their attempts across many IP addresses to dodge simple IP-based blocking. Instead of 1,000 attempts from one IP, they’ll send 10 attempts each from 100 different IPs \u2014 making each one look almost normal. This is why IP blocking alone isn’t enough: rate limiting needs to work at the account or session level too, not just per IP.<\/p>\n\n\n\n

They also throttle requests to stay under alert thresholds and rotate user agents to blend in with real browser traffic. This infrastructure often runs on botnets of compromised devices \u2014 home routers, IoT devices, web servers \u2014 that were hacked themselves and are now launching points for someone else’s attack.<\/p>\n\n\n\n

Step 4: What Happens After a Successful Login<\/h2>\n\n\n\n

If a credential pair works, the bot usually doesn’t do anything visible right away. It creates a new admin account as a persistent backdoor, installs a web shell for server-level access if possible, and reports the compromised site back to whoever runs the operation. Actual exploitation \u2014 spam injection, redirects, malware \u2014 often happens hours or days later, from a different IP, using the backdoor account.<\/p>\n\n\n\n

Why Standard Defenses Work Against Bots<\/h2>\n\n\n\n

Bots rely on predictability \u2014 the same paths, the same credential lists, the same patterns. That predictability is exactly what makes a few targeted defenses so effective.<\/p>\n\n\n\n

BruteFort implements the defenses below directly, which is why they work as well as they do against automated bots.<\/p>\n\n\n\n

\n