Credential stuffing isn't glamorous. No zero-day, no sophisticated APT tradecraft. Just billions of previously leaked username and password pairs, run against your login pages until something works. When it does, it looks exactly like a legitimate user.
What is credential stuffing and why does it keep working?
Credential stuffing exploits password reuse. Attackers take credentials from historical breaches, LinkedIn, Adobe, Dropbox and hundreds of others, and automate login attempts across different services. The success rate is low, typically 0.1 to 2 per cent. Against millions of attempts, that is thousands of valid sessions.
It keeps working because people reuse passwords. That is a human behaviour problem, not a technology one. Blocking IPs helps, but attackers rotate through residential proxies faster than WAF rules can keep up. The authentication layer was built assuming the person entering the credentials is the person they claim to be. Credential stuffing removes that assumption entirely.
What does a credential stuffing incident actually look like from the inside?
The first sign is usually a spike in failed authentication. By the time monitoring flags it, the successful logins have already happened. LimitedView's incident analysis across our dataset shows that in confirmed account takeover cases, the window between first successful login and detection ran to hours, not minutes.
What you see in the logs: geographical anomalies, unusual access times, sequential login attempts across multiple accounts from the same IP range. What you don't see immediately is that the attacker has already exfiltrated session tokens and is sitting in a secondary system.
The damage rarely stops at the first account. Lateral movement happens fast when privileged accounts are involved. One compromised service desk account can give an attacker the access needed to reset passwords across the environment. The breach becomes self-extending.
How does employee behaviour contribute to account takeover risk?
Password reuse is the obvious vector, but the training failure runs deeper than that. Employees who don't understand the significance of a "suspicious login" notification will dismiss it. Service desk staff who receive password reset requests without verification protocols will comply.
In one pattern LimitedView's analysis identified repeatedly: the attacker didn't use the compromised credentials directly. They used them to social engineer the service desk. "I've forgotten my MFA device. Can you reset it?" That is a training failure at the service desk level, not a technical control failure. The credentials were the entry point; the service desk interaction was what mattered.
Why does annual compliance training fail to change this behaviour?
Because credential stuffing happens to someone else until it happens to you. Annual training tells employees that password reuse is bad. It does not create the visceral understanding of what an account takeover investigation actually feels like, or what the organisation spent recovering from it.
LimitedView's data across 847 organisations shows 73 per cent knowledge retention when training is delivered immediately after a relevant incident, compared to 12 per cent from scheduled awareness programmes. The incident is the context. Without it, the message doesn't stick.
Organisations using incident-triggered training report a 64 per cent reduction in repeat incidents of the same class. For credential-based attacks, that means fewer repeat account takeovers following the first one. The pattern changes because the people involved understand, at a detailed level, what just happened to them.
What should happen in the 48 hours after an account takeover?
The technical response is clear: invalidate sessions, force password resets, review audit logs, notify affected parties if required under regulation. What gets skipped in most organisations is the human piece.
Who was targeted? What did the attacker try to do after gaining access? Who on the service desk interacted with the attacker? Those people need training now, while the incident is live in their memory. Not next quarter.
Service desk staff who nearly completed an MFA bypass for what turned out to be an attacker will remember that call for a long time. That memory is an asset. A structured debrief with targeted training content, delivered within 48 hours, converts a near-miss into a durable behaviour change. Wait three months and it becomes an abstract anecdote.
What technical controls actually reduce credential stuffing exposure?
Passkeys and hardware MFA eliminate the credential reuse vector entirely. FIDO2 authentication means there are no passwords to stuff. If your organisation is still on SMS-based two-factor authentication, credential stuffing combined with SIM-swapping is a realistic attack path you should be actively mitigating.
Rate limiting, CAPTCHA challenges, and anomalous geography alerts all add friction. They don't prevent the attack. They slow it down and create more signal in the logs for your detection to work with.
The honest answer is that technical controls reduce the blast radius. Behavioural controls, delivered at the right moment with the right context, reduce the frequency. You need both, but only one of them gets better the more incidents you have. Incident-triggered training compounds. A WAF rule doesn't.
