Back
Stop credential-stuffing bots before they test leaked passwords
Attackers feed leaked email-and-password pairs into automated tools and point them at login pages, customer portals and authentication APIs. The attack works when a customer reused a password exposed somewhere else.
ADPAL filters automated login traffic at the managed perimeter before high-risk requests reach the full authentication workflow. Genuine customers keep the normal sign-in journey, while MFA, passkeys, identity-provider controls and password checks stay in place.
.SCALE OF THE PROBLEM
A breach somewhere else can become your login problem
Credential stuffing does not require a weakness in your password database. The credentials usually come from
breaches on unrelated services. Bots test whether the same pair also works on your website, app or customer portal.
There is no universal attack rate for every SMB. Your own authentication logs, failed-login distribution,
successful high-risk logins, resets and support tickets are the useful baseline.
.SNIPPET DEFINITION
What is credential stuffing?
Credential stuffing is the entry method. Account takeover is the possible result when one of those known pairs works and the attacker gains control of the account. Brute force and password spraying are related login attacks, but their request patterns differ.
Credential stuffing is an automated login attack in which bots test username-and-password pairs exposed in breaches on other services. The attack succeeds when a person reused the same credentials. Unlike brute force, credential stuffing checks known pairs rather than guessing many passwords.
.What it looks like
How credential stuffing plays out on an
SMB login
The example below is illustrative and shows a realistic credential-stuffing pattern for an SMB login
Friday night. A retailer’s login endpoint starts receiving a steady stream of attempts. Each request tests a different customer email and comes from a different residential or mobile network.
The attack stays below simple limits. Most accounts receive only one or two attempts. No single source sends enough volume to trigger a basic per-IP threshold or account lockout.
A few credentials work. Most leaked pairs fail. A small number succeed because those customers reused passwords exposed in older breaches. Those matches can become account takeover attempts.
The pattern appears across the journey. The individual requests look fragmented. Across behaviour, browser characteristics, network context, request sequence and login endpoints, the repeated automated journey becomes easier to distinguish from genuine sign-ins.
The visible problem may be a rise in failed logins, but the commercial risk is the occasional successful match plus the
support, infrastructure and customer-friction costs created around the attack.
. Symptoms
Signs of a credential stuffing attack
Start with authentication and business signals, then confirm the pattern across login, identity-provider, edge and application logs.
Failed logins rise across many accounts rather than clustering around one username.
Each account receives only one or two attempts, keeping activity below ordinary lockout thresholds.
Attempts arrive from many IP addresses, networks, countries or residential proxy ranges.
A low-and-slow stream continues for days or weeks instead of appearing as one obvious spike.
The login endpoint or authentication API becomes unusually busy while the rest of the site remains normal.
Successful logins appear during or immediately after a broad failed-login wave.
Password-reset requests, lockouts or ‘I cannot log in’ support tickets rise after defensive changes.
The same login pattern reaches the website, mobile endpoint, SSO route or legacy authentication API.
Attempts arrive with highly similar timing, navigation or request sequences despite changing source networks.
Many usernames are tested once, then never touched again when the pair fails.
Authentication traffic increases without a matching rise in normal browsing, purchases or account activity.
A small number of successful logins are followed by unusual account changes, saved-value use or recovery actions.
Recognise several signs? It is worth checking
The key pattern
Many accounts, few attempts per account, distributed sources and occasional success. One failed login is normal. The repeated cross-account pattern is what deserves investigation.
.Business impact
What credential stuffing really costs your business
The successful account compromise is only one part of the cost. Even a campaign in which most attempts fail can
consume authentication resources, support time and customer trust.
Account takeover exposure
A valid match can expose saved details, loyalty value, order history or account functions. Credential stuffing is the entry route; account takeover is the downstream risk.
Support workload
Lockouts, suspicious-login warnings and resets create tickets for genuine customers who may never know why the login suddenly became harder.
Infrastructure and provider cost
Authentication, databases, email, SMS and identity-provider services process requests that did not come from genuine customers.
False-positive friction
Overly aggressive country, IP or lockout rules can stop legitimate users while distributed automation stays below the same thresholds.
Fraud investigation
Teams must review successful matches, account changes and unfamiliar access before they know which events were malicious.
Trust damage
Customers usually blame the business where their account was finally abused, not the older breach that exposed the reused password.
Measure the attack against downstream outcomes: failed-login distribution, successful high-risk access, reset and
lockout tickets, fraud review and genuine sign-in completion. Raw failed-login volume alone does not show business impact.
.How the attack works
How credential stuffing turns leaked passwords
into account access
The mechanics are simple enough to automate and difficult enough to hide from one-dimensional controls. A typical
campaign follows the same business logic even when the infrastructure changes.
01
What happens
Obtain credentials
The attacker acquires leaked username-and-password pairs from previous breaches, dumps or criminal marketplaces.
What you may see
Your website may have no connection to the original breach.
02
What happens
Map login surfaces
Automation finds the main login, mobile/API authentication, SSO, partner or legacy routes.
What you may see
Attempts appear across web, mobile, SSO or legacy authentication routes.
03
What happens
Distribute attempts
The list is spread across many networks and paced so each account or source sends very little traffic.
What you may see
Per-IP and simple lockout rules see fragments rather than the whole campaign.
04
What happens
Identify valid matches
The bot reads success, failure, reset or step-up responses and separates credentials that still work.
What you may see
A small number of credentials return success, reset or step-up responses during the wider failed-login wave.
05
What happens
Abuse successful access
Valid accounts may be used for fraud, saved-value theft, order changes, scraping or resale.
What you may see
Successful access may be followed by account changes, saved-value use, order edits or recovery activity.
Common ways attackers make the campaign harder to see
Distributed sources
One address sends only a few requests before the next attempt moves elsewhere.
Low-and-slow pacing
Small request volumes can run for days or weeks below obvious spike thresholds.
Valid-looking requests
The bot submits a normal login form with a real email-and-password pair.
Residential networks
Consumer and mobile addresses can carry both genuine customers and abusive automation.
Multiple login surfaces
Attackers test web, mobile, SSO and older API routes for the easiest path.
Changing automation
Browser emulation, timing variation and request changes reduce the value of one fixed signature.
Credential stuffing vs brute force vs password spraying
Credential stuffing tests known username-and-password pairs across many accounts. Brute force guesses many passwords against one or a few accounts. Password spraying tries one common password across many usernames. The attacks overlap in purpose, but the request pattern and best supporting controls are different.
.How ADPAL prevents it
How ADPAL filters automated login abuse
ADPAL evaluates covered authentication traffic at the managed perimeter before high-risk automation reaches the full login workflow. Advanced detection combines behaviour, browser characteristics, network context, request sequence and endpoint activity instead of trusting one IP address or user-agent string.
That wider context matters because credential-stuffing campaigns can rotate networks, distribute attempts across many accounts and slow their pace. Individual requests may look unrelated while the repeated login journey still shows coordinated automation.
Keep MFA or passkeys, leaked-password checks, identity-provider risk controls, account recovery and post-login monitoring. ADPAL reduces automated traffic reaching those layers; it does not replace authentication security.
No detection system should promise perfect separation. Monitoring, allowlists, endpoint-specific policy and review of genuine login outcomes remain part of a responsible rollout.
01
Review how requests reach and use the protected authentication flow.
02
Evaluate behaviour, browser characteristics, network context, request sequence and endpoint activity together.
03
Connect repeated login behaviour across covered routes without relying on one source address.
04
Block or limit high-confidence malicious automation before the full authentication workflow performs unnecessary work.
05
Most genuine users continue normally. Adaptive CAPTCHA appears only in rare, uncertain cases.
. DIY vs. perimeter
What you can do yourself – and
where each control fits
Measure
Helps?
The practical limit
Unique passwords and password managers
Essential
Reduce reuse at the user level. You cannot force customers to follow this everywhere, so exposed credentials will still reach your login.
Passkeys or phishing-resistant MFA
Strong account barrier
Can prevent a stolen password from becoming a successful compromise. Keep this wherever practical.
Leaked-password detection
Strong
Identifies known exposed passwords and supports forced reset or step-up authentication. Coverage depends on the datasets checked.
Rate limiting
Useful layer
Controls bursts and protects endpoints. Per-IP-only thresholds miss campaigns spread across many sources.
Account lockouts
Use carefully
Slow repeated attacks against one account. Low-and-slow stuffing may avoid them, while attackers can deliberately lock out genuine users.
CAPTCHA or step-up challenge
Partly
Can slow simple automation. Blanket challenges add accessibility and conversion friction, so use them selectively.
Login-surface inventory
Essential hygiene
Find web, mobile, SSO and legacy authentication routes. An unprotected old endpoint can become the easiest path.
Identity-provider risk controls
Useful layer
Keep native anomaly detection, conditional access and sign-in risk policies where available. They add identity context after traffic reaches the login stack.
Monitoring and alerting
Essential
Track failed-login distribution, successful high-risk access, resets, lockouts and false positives so you know whether controls work.
Perimeter bot filtering
Traffic-control layer
Evaluates distributed automation before the full authentication workflow. It still needs monitoring and account-security controls.
Actionable first step today
Export 24-72 hours of login or identity-provider logs. Group attempts by account, IP or network, endpoint and time. Look for many usernames with only one or two attempts each, then check whether the same pattern reaches web, mobile and API login routes.
Built for small teams
Built for small teams that need safer logins,
not a fraud operations centre
Advanced detection evaluates behaviour, browser characteristics, network context, request sequence and endpoint activity rather than trusting one IP decision.
Protect covered website and authentication endpoints used by browser, mobile and API clients. Confirm exact routing during onboarding.
High-confidence automation can be blocked or limited. Adaptive CAPTCHA appears only in rare, uncertain cases.
Apply stronger controls to customer login, admin authentication, SSO or other high-value routes without adding the same friction everywhere.
Keep approved integrations, internal tools and trusted automation available through defined policy.
Keep MFA, passkeys, leaked-password checks, recovery controls and identity-provider protections as defence in depth.
Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency.
Point your DNS at the managed reverse proxy – live in hours, then a short monitoring period before enforcing. CMS-integrated deployment is available through hosting partners.
ADPAL Bot Protection adds one managed control layer in front of covered authentication routes. The goal is practical: reduce automated credential testing while the account-security controls you already trust remain in place. Explore Bot Protection →
.Proof
Evidence that belongs
on this page
.Learn more
Learn more about login bot protection
Guide
How to block credential stuffing: step by step
Guide
How to protect your login page from bots
Guide
What is CAPTCHA – and when is it useful?
.FAQ
Questions about credential stuffing protection
What is a credential stuffing attack in simple terms?
A bot takes usernames and passwords leaked from other services and tries them on your login. It is looking for people who reused the same credentials. The attacker does not need to breach your password database or guess every possible password.
Credential stuffing vs brute force: what is the difference?
Credential stuffing tests known username-and-password pairs across many accounts. Brute force guesses many passwords against one or a few accounts. Password spraying is different again: it tries one common password across many usernames.
Is credential stuffing the same as account takeover?
No. Credential stuffing is the automated login method. Account takeover is the result when a valid pair works and the attacker gains control of the account. A stuffing campaign can fail completely or produce a small number of successful matches.
Does MFA stop credential stuffing?
MFA or passkeys are strong barriers against a stolen password becoming a successful compromise and should be kept. They do not necessarily stop bots from sending the login requests, triggering checks or creating operational noise upstream.
Can rate limiting prevent credential stuffing?
Rate limiting helps, but a simple per-IP threshold is not enough. Attackers can distribute attempts across many networks and send only one or two requests per account. Use rate limits as one layer and review the wider cross-account pattern.
Do account lockouts solve the problem?
They can slow repeated guessing against one account, but low-and-slow credential stuffing may avoid the threshold. Aggressive lockouts can also become a denial-of-service tool against genuine customers. Use them carefully with monitoring and recovery.
Should every customer solve a CAPTCHA?
Usually not. CAPTCHA can raise attacker cost, but blanket use adds friction and accessibility problems for genuine users. A risk-based approach keeps the normal login journey for most users and uses additional verification only when uncertainty remains.
Where do leaked passwords come from?
They can come from breaches, phishing, malware logs and credential dumps collected from unrelated services. Lists are combined and reused for years. Your site may never have been breached and still receive attempts using a customer’s old exposed password.
Can mobile apps and APIs be targeted too?
Yes. Attackers test the easiest authentication route they can reach, including mobile APIs, SSO flows, partner portals and legacy endpoints. Protect the complete login surface rather than assuming the visible web form is the only path.
How do I know whether my site is being targeted?
Look for failed attempts spread across many usernames and networks, with very few tries per account. Check for low-and-slow activity, unusual authentication API load, successful logins during the same wave and reset or lockout tickets.
Will genuine customers be blocked?
Any automated policy can make mistakes. Reduce the risk with monitoring, conservative enforcement, endpoint-specific policy, allowlists and review of genuine login outcomes. Avoid claims of zero false positives unless independently demonstrated.
What should a small business do first?
Export a recent authentication window, find the many-accounts/few-attempts pattern, confirm every login route, keep MFA or passkeys enabled and reset known exposed passwords. Then add traffic filtering if distributed automation is still reaching the authentication workflow.
Can a WAF stop credential stuffing?
A WAF can enforce rate, reputation and application-security rules, and some platforms include bot-management features. Credential stuffing often uses valid login requests spread across many accounts and networks, so dedicated bot protection adds behavioural and request-sequence context that a basic rule set may not have.
Make leaked passwords harder to exploit at scale
Credential lists already exist, and customers cannot undo every old breach or password reuse decision overnight.
What you can control is whether automated tools can test those credentials against your login at scale.
Reduce the automated load at the perimeter, keep MFA and password-security controls in place, and measure successful access rather than failed-login volume alone.
No credit card
Cookieless · no cross-site tracking profiles · EU (Frankfurt) data residency