What attackers actually type in your WordPress login box

Short answer: almost never “admin”. Hostney’s analysis of 8,007 WordPress login attempts over 90 days found that the username admin accounted for just 3.4% of them. More than half the attempts used a username that appeared on exactly one site, which means it was not guessed at all. It was read off the site first. That changes the defence completely: you cannot pick a username clever enough to avoid a list your own website publishes.

This is what the data looked like, and what actually reduced it.

What we looked at#

Every WordPress installation on the Hostney platform can send login telemetry back to the control panel: the username tried, the source IP, the result, and the time. Between 24 June and 22 September 2026 that produced 8,007 login attempts across 14 WordPress installations, 11 of which were attacked at all.

We refer to this dataset throughout as the Hostney login telemetry, 2026. If you want to cite any figure below, that is the source, and the sample size and date range are stated with every claim so the numbers can be checked against their limits.

Everything below is based on the 7,517 failed attempts. We left the successful ones out on purpose, because they are dominated by site owners and their developers logging in normally, and mixing those into an attack analysis would be misleading.

Two things to be upfront about, because they decide how much weight this deserves:

• This is a small number of sites. 2,942 distinct attacking IP addresses is a substantial sample of attacker behaviour. 11 sites is not a substantial sample of the web. Treat the patterns here as real and the proportions as indicative.
• We are not naming anything. No usernames, no domains, no customer names appear in this article. Where an example would help, we have invented one and said so.

"Admin" is a rounding error#

The advice to rename the admin account is close to universal. It appears in nearly every WordPress hardening guide written in the last fifteen years, including ones we have written ourselves.

Against this dataset, here is what it would have prevented:

Renaming admin defends against roughly one attempt in thirty. It is not useless, and it costs nothing, so keep doing it. But it is nowhere near the top of the list, and treating it as a meaningful defence is how a site ends up with a hardened username and no other protection at all.

The usernames were read off the sites#

The more useful question is what the other 96% consisted of. Grouping every attempted username by how many different sites it was tried against:

In other words, 52.25% of the login attempts Hostney recorded targeted a username unique to a single site. A username tried against one site by dozens of separate IP addresses is not a dictionary entry. A dictionary spreads. This one does not, because it only exists in one place, and the only way an attacker knows it is by reading it off that site.

The third column is the part worth sitting with. Site-specific usernames attracted an average of 25 distinct attacking IPs each. Generic ones attracted 7. Attackers put three and a half times more infrastructure behind a name they know is real. That is a rational allocation of effort, and it tells you they can distinguish the two.

The shapes that showed up repeatedly:

• a surname on its own
• a first initial joined to a surname
• a first name and surname with a hyphen between them
• a first name and surname with a space between them, capitalised
• a full email address used as the login
• a person’s name joined to the company name
• the company name with _admin appended
• a job title, such as a variation on “IT manager”
• admin with three or four digits after it

Several of those appeared against the same site in the same window, in different spellings of the same person. That is the signature of the whole thing. An attacker who has one name and does not know which format the site uses will simply try all of them.

To make that concrete without using anyone’s real data, here is an invented example. Suppose a fictional design studio at northfield-design.example has a partner called Sarah Chen whose name appears on three blog posts. The attempts we would expect to see, and the pattern we did see repeatedly, look like this:

schen
sarahchen
sarah.chen
sarah-chen
Sarah Chen
schen@northfield-design.example
northfield_admin

Seven guesses, one piece of public information. None of them require a password list yet. They are simply working out what the login name is, and one of those seven is usually right.

Where the names come from#

None of this requires anything clever. WordPress publishes author identities by design, through several routes at once:

• Author archives. /?author=1 redirects to an author page whose URL contains that user’s slug, which is very often the login name.
• The REST API. /wp-json/wp/v2/users returns a JSON list of users with names and slugs, without authentication, on a default installation.
• Bylines and team pages. The display name under every post, and the staff page most business sites have.
• The public record. Domain registration details, LinkedIn, an email address on a contact page.

We tested whether attackers derive usernames from the domain name instead, since that would be the obvious alternative theory. They do not: only 25 of 7,517 attempts used a username contained in the site’s own hostname. It is people they harvest, not domains.

This is why “choose an unguessable username” is advice that cannot work. The username is not secret and was never designed to be. It is a public identifier that the software publishes on purpose, and the only fix is to stop publishing it or to stop it mattering.

The attacks are not shaped like brute force any more#

The second finding surprised us more than the first. Grouping every attacking IP by how many attempts it made:

In the Hostney login telemetry, 54.6% of attacking IP addresses made exactly one attempt, and 81.6% made three or fewer. Two addresses out of 2,737 exceeded fifty.

Every “limit login attempts” plugin ever written is aimed at those two. A rule that blocks an IP after five failures does nothing to an IP that only ever tries once, and four out of five of them only ever try once.

The dataset contained two completely different attacks, which is easiest to see side by side:

The right-hand column is the attack everyone designs for. It is loud, it is short, and a per-IP limit stops it.

The left-hand column ran for 2,160 hours. That is the entire ninety-day window, without a pause, at about one and a half attempts per address. There is no threshold that catches that without also blocking the site’s own users, because from any single address it is indistinguishable from someone mistyping their password once.

This is the structural problem with defending the login page from inside the site. A plugin sees one site’s traffic, so it can only count per IP, and per IP there is nothing to see. The pattern only becomes visible when you can correlate across many sites at once, which is a property of the platform rather than the plugin. We have written about that division of labour before, in Wordfence and server-level security and in what happens when bots find your login page.

What actually reduced it#

WordPress installations on our platform have optional switches that close the enumeration routes described above: one blocks user listing through the REST API, another blocks the ?author=N redirect.

Grouping the same 90 days by which of those were enabled:

⚠ Read that with the caveat attached, because it matters. The six unprotected sites in the top row belong to a single customer. This is not six independent samples against six others; it is one account that has not enabled any of the available protections, sitting alongside accounts that have. Attack volume also varies for reasons that have nothing to do with configuration, such as how long a domain has existed and how visible it is.

So this is a case study, not a controlled experiment, and we are not going to claim a 93x improvement as though it were a measured effect size.

What it does show is worth having anyway. The same platform, the same attacker population, the same ninety days. In the Hostney login telemetry, the sites publishing their user list absorbed 344 distinct attempted usernames. The sites not publishing it absorbed 25, and the two with both routes closed absorbed nothing at all. The number of distinct usernames tried is the column that is hardest to explain away, because it is not a measure of how much attention a site got. It is a measure of how much the attacker knew.

What to do about it#

In rough order of how much they are worth:

1. Close the enumeration routes. Block user listing on the REST API and the ?author=N redirect. This is the specific thing the table above is about, and on most sites it breaks nothing.
2. Stop the login name and the display name being the same string. WordPress lets you set a display name that differs from the login. Most installations never change it, so every byline publishes a valid username. This costs one minute per user.
3. Make the password the only thing that matters, then make it not matter. Since the username is effectively public, the entire defence rests on the second factor. Two-factor authentication or passkeys turn a correct username and password into an incomplete answer.
4. Do not rely on per-IP login limits. Keep them, they are free, but four out of five attacking addresses in this dataset never reached any threshold worth setting. Read the honest version of what they do and do not cover in brute force attacks on WordPress.
5. Renaming the login URL is worth less than it looks. It helps against traffic that only knows /wp-login.php , which is real but is not where the volume is. Changing the login URL is a speed bump, not a wall.
6. Rename admin anyway. It is 3.4%, it takes five minutes, and 3.4% is not zero. Just do not stop there. The rest of the list is in how to secure your WordPress login and the broader WordPress hardening guide.

The one that changes the most for the least work is number two, and almost nobody does it. If your login name and your public display name are the same word, every post you publish is a credential hint. Fixing that is a user management task that takes a minute and removes you from the harvesting step entirely.

Where the attacks came from#

For completeness, the top sources by attempt volume were the United States (1,626 attempts from 565 IPs), Vietnam (559 from 132), Germany (473 from 182), France (421 from 149) and India (318 from 119).

The United States leading this list does not mean American attackers. It means American datacentre capacity. The same goes for Germany, France and the Netherlands, and it is most obvious with Belgium at 308 attempts, a country with an unremarkable population and a lot of hosting. What you are looking at is rented infrastructure, which is why blocking by country is a blunt instrument that mostly removes customers.

The attempts-per-IP figure separates the two behaviours better than the country does. The US averaged 2.9 attempts per address, consistent with a large rented fleet spread thin. Iran averaged 5.5 across only 32 addresses, which is a different and much smaller operation.

The limits of this data#

We would rather state these than have them pointed out.

• Eleven attacked sites is a small base. The attacker-side numbers are large, the site-side numbers are not.
• The configuration comparison is confounded, as described above.
• This covers attempts that reached WordPress. Traffic blocked earlier, at the edge or by the firewall, is not in this table, so the real volume arriving at these sites was higher.
• Ninety days is one season. We have no view here of whether any of this is seasonal.
• Telemetry is opt-in per installation, so the sample is sites whose owners left it enabled.

How this fits with what we run#

Every WordPress installation on Hostney can enable the enumeration blocks described above, along with disabling XML-RPC and requiring single sign-on through the control panel instead of wp-login.php . In this dataset the installations with single sign-on required and XML-RPC disabled recorded no failed login attempts at all during the ninety days.

The distributed pattern is also the reason our bot protection works at the server and edge rather than inside each site. An IP making one attempt against one site is invisible locally and obvious when you can see it making one attempt against many sites at once. That is the same correlation the cohort analysis in our bot protection work depends on.

None of that removes the need for a second factor. If the username is public and the password is the only secret, the password is doing work it was never good at.

—

Data: 8,007 WordPress login attempts recorded across 14 installations on the Hostney platform between 24 June and 22 September 2026, of which 7,517 failed attempts form the basis of this analysis. No usernames, domains or customer identities are published. The worked example in this article is invented.