It is a popular idea that a brute force attack should be easy to detect because several unsuccessful passwords will show under one IP address. That is not a full assumption. During further examination, I detected an unsuccessful login attempt to my WordPress site via XML-RPC. So this is what occurred. That got me wondering: does a brute-force attack truly come from one IP? No. Modern assaults can distribute requests over proxies, VPNs, cloud hosts, or hacked devices.
What Is A Brute-Force Attack?
A brute-force attack is an automated process of gaining access by entering passwords or credentials repeatedly. One source makes several predictions against one account (basic instance). In the scattered case, each IP may send just few attempts.
OWASP distinguishes between brute force, credential stuffing and password spraying. Its Web Security Testing Guide said the distributed brute force might be used with numerous IP addresses to get around measures that score failures on a per-IP basis.
An IP address is a label for a network source, not necessarily a single attacker or device. If a botnet, proxy, VPN, cloud server or hijacked workstation is used, one campaign can appear to emanate from several places .
Does A Brute-Force Attack Really Come From One IP?
Sometimes. Not every time. A simple brute-force attack may be from a single IP for minutes or hours, therefore it’s rather easy to rate-limit.
But a brute-force attack might potentially involve hundreds or dozens of IP addresses. OWASP adds that an attacker can spread requests across botnets or rotating proxies to get around per-IP controls.
Now the detecting problem is different. Don’t ask “Which IP is attacking me?” Ask “What authentication pattern is attacking me?”
Some useful signals are the same username failing from many addresses, repetitive requests to one login endpoint, unexpected locations, identical request behaviour, and a successful login after many failures.
My Test: One IP Versus Many
I compared 2 simple examples.
Scenario A: A single IP launches 100 failed login attempts against a single account. A server can see the repeating source and block it for some time.
Scenario B: 100 IPs, one login attempt per IP, all on identical account, all fail. Still 100 failures in total, but a simple per-IP threshold might not trigger.
That’s the weakness of using an IP as the attacker identity. You can keep the volume per address low with a brute force attack, but the overall activity high.
That is why correlation of events at account level is important . For example, Google Cloud security guideline suggests to search for excessive failed logins against a single user from foreign IPs .
Real Example
WordPress XML-RPC
Another good example from the actual world is WordPress, which has predictable authentication endpoints. The WordPress manual mentions that XML-RPC might be a common target, and highlights the system .multicall call. It recommends disabling XML-RPC when you don’t need it, and restricting and rate limiting it when you do.
Just because my XML-RPC event failed doesn’t mean the site was compromised. One failed login just implies an authentication attempt failed.
The pattern is what is significant. One bad request from one ip may be background internet noise. It’s more of an issue if a brute-force attack comes from several different addresses hitting XML-RPC or wp-login.php over and over again.
Distributed password attacks
OWASP says that distributed brute force and password spraying may employ several IP addresses, enabling attackers to circumvent lockout systems based solely on IP issues.
Microsoft recommends that investigators additionally look for odd sign-ins from one or several IPs and correlate similar malicious IPs during password-spray investigations.
This is why a brute force attack should be viewed as a campaign, not as a single IP occurrence. Infrastructure can change while the target account, endpoint, time or credential approach stays the same.
How To Detect A Brute-Force Attack From Multiple IPs?
Begin with account-based monitoring. Count unsuccessful authentication attempts on a username from all source IP addresses.
Then watch the login endpoint. Even if individual IPs generate very little traffic, a sudden spike in requests to wp-login.php, an API login route or XML-RPC is worth taking a look at.
Then correlate time. Ten failed attempts from ten IPs in two minutes is more suspicious than ten failed attempts over several months.
Another indication can be the user-agent and the connection fingerprint. According to OWASP, connection fingerprinting can offer more details than just an IP address.
Finally, look for successful authentication after numerous failures. That combination could mean appropriate credentials were eventually found or secured.
Why blocking only IP Addresses Is Not Enough?
Blocking an IP address can help if you have noisy sources, but it shouldn’t be your entire defence. A brute force attack can rotate addresses using proxies, VPN’s, botnets, and/or cloud infrastructure.
According to OWASP, defence in depth is recommended, incorporating controls based on account and authentication behaviour. In particular , MFA is important since it makes password-only guessing less useful .
NIST’s current SP 800-63B-4 provides authentication guidelines . NIST advise states that online password guessing should be reduced by slowing authentication attempts.
How To Protect Your Website?
Practical defence should have these controls:
- Turn on MFA for administrator and high-value accounts.
- Use long, unique passwords and deny known hacked passwords.
- Implement rate limiting depending on IP and account behaviour.
- Add gradual backoff on retry.
- Monitor login activities from any originating IP.
- Use a WAF or reverse proxy for public login endpoints.
- Always keep WordPress, plugins, themes, and server software up-to-date.
- If you don’t require XML-RPC, turn it off. If you do need it, limit and rate-limit it.
- Alert on atypical failure patterns followed by successful logins.
- Check authentication logs routinely.
Here the purpose is not only to find one problematic IP. What it means to understand the attack pattern even with changes to infrastructure.
Conclusion
You can brute force from one IP or you can split the brute forcing across numerous IPs. Some loud sources and many low volume sources may be present in a mixed campaign. A modern detection would correlate the account, endpoint, timing, authentication result, connection characteristics and source infrastructure. So in that sense a brute-force attack is more of a behaviour pattern than an IP address.
My WordPress XML-RPC event was a good reminder that one failed login doesn’t make an incident. The pattern around is more significant. If you just look at failures per IP, a distributed brute-force attack can stay below your threshold.
Frequently Asked Questions
1. Can a brute force assault employ many IP addresses?
Yes. Attackers can spread authentication attempts over proxies, botnets, VPNs and cloud infrastructure. This can keep each IP below a blocking threshold, while yet having a large number of total attempts.
2. Does a failed login suggest my website is under attack?
No. Automated requests for internet-facing sites are coming in all the time. One failed login attempt is not proof of a compromise. Look for several tries, strange timing, multiple source IPs, accounts that are targeted, and successful logins after failures.
3. Should I block all IPs that fail to login?
Not really. Temporary block of an IP might prevent evident abuse, while permanent block creates false positives. Combine IP controls with account-based rate limiting, MFA, monitoring and other authentication signals.
4. Is XML-RPC a security threat to WordPress?
XML-RPC is valid, however it can be a target for authentication misuse. WordPress suggests turning it off if your site doesn’t need it. If you need it, throttle and rate-limit it.
5. What’s the greatest defence against distributed login attacks?
There is no single control for all the cases. IP blocking is just the first step. MFA, strong passwords, rate restriction, account based detection, WAF protection, logging, alerts and updates give a more robust defence in depth.
Try Our Tools
Explore our resources for practical tech and cybersecurity utilities for security testing, networking and troubleshooting. For valuable resources for everyday technical tasks, see the ExplainMeTech tools page.
References
- OWASP – Credential Stuffing Prevention Cheat Sheet OWASP Credential Stuffing Prevention Cheat Sheet
- OWASP – Web Security Testing Guide OWASP Web Security Testing Guide
- NIST – SP 800-63B-4, Digital Identity Guidelines NIST SP 800-63B-4
- Microsoft Learn – Password Spray Investigation Playbook Microsoft Password Spray Investigation
- WordPress Developer Resources – Brute Force Attacks and XML-RPC Considerations WordPress Brute Force Guidance
For more helpful technology, cybersecurity, and digital-security tips, visit ExplainMeTech.com and explore our latest guides, tools, and insights.