Credential stuffing is unglamorous and it works. An attacker takes username and password pairs leaked from somewhere unrelated (a forum, a retailer, a decade-old social network) and replays them against your login page on the reasonable assumption that some of your people reuse passwords. They do.
What it looks like from your side
The signature is not volume. A competent operator spreads attempts across hundreds of residential IPs and paces them below whatever lockout threshold you have configured. In the logs it reads as a slightly elevated failure rate from a geographically scattered set of addresses, over days rather than minutes.
- Failures cluster on valid usernames, so the list is targeted, not random.
- Each source address makes a handful of attempts, then never returns.
- User agents are plausible and varied; the requests are shaped like a browser.
- The successful login, when it comes, looks completely ordinary.
The attack you can see in the logs is rarely the one that succeeded. The successful one looks like a normal Tuesday.
The controls that actually change the outcome
Rate limiting helps at the margins and is worth having. But the two controls that meaningfully break this attack are phishing-resistant multi-factor authentication and screening new passwords against known-breached lists at the moment they are set.
- Enforce MFA on every account with administrative reach, without exception for the founder.
- Check new and changed passwords against a breach corpus. Reject matches.
- Alert on a successful login that follows a run of failures for the same account.
- Watch for logins from a new device and country together, because either alone is noise.
For teams without anyone reading logs at 2am, this is exactly the kind of pattern worth automating: the detection is mechanical, and the response (force a reset, invalidate sessions, notify the human) does not need judgement until after the fact.