When an organisation tells us an account was "hacked", the overwhelmingly likely explanation is not that somebody cracked the password. It is that the same password was used somewhere that got breached, and an attacker simply tried it here.
How the attack actually runs
Credential dumps from past breaches circulate freely and are aggregated into very large combination lists. An attacker takes that list, points automated tooling at your login page, and tries each pair. They are not guessing — they are checking which of several million known-valid credentials also works on your system.
Success rates per attempt are low. Across a large enough list they are reliably non-zero, which is all the attack needs.
Why it so often goes unnoticed
- Each attempt comes from a different address, so per-IP rate limiting does nothing.
- The volume is spread over days or weeks rather than minutes.
- A successful login looks exactly like a successful login, because that is what it is.
- Failed-login alerting is usually tuned for brute force against one account, not one attempt against thousands.
What actually stops it
Multi-factor authentication
The single most effective control, by a wide margin. A valid password alone stops being sufficient. Prefer app-based or hardware factors over SMS, which is exposed to SIM swap — a technique very much in use in this region.
Check passwords against known breaches
At the point a password is set or changed, check it against a breach corpus and refuse the ones already circulating. This is a small engineering effort that removes the entire attack class for that account.
Stop forcing rotation
Mandatory 90-day changes produce Password1!, then Password2!. Current guidance from every serious standards body is to drop scheduled rotation and change on evidence of compromise instead. Length matters far more than complexity theatre.
Watch for the pattern, not the attempt
Alert on distributed low-volume failures across many accounts, on logins from unusual locations, and on impossible travel. Those signals are what distinguishes credential stuffing from normal failed logins.
For your people
Telling staff not to reuse passwords without giving them a password manager is asking them to do something genuinely impossible. Deploy one, pay for it, and make it the default. The behaviour change follows the tooling, not the training slide.
