Credential-Stuffing Attacks on Broadband Networks and How AAA Stops Them

Overview

• Credential stuffing replays leaked username/password pairs across thousands of subscriber accounts, one or two tries each. Per-account lockout never trips, so the attack looks like background noise until the takeovers start.
• On a broadband network the login surfaces are RADIUS-backed PPPoE and hotspot authentication, carrier Wi-Fi portals, and self-care accounts. All of them terminate at the AAA server, which is the one place that sees every attempt.
• Three AAA-layer controls stop it: rate limits keyed on source, NAS, and network-wide failure rate; anomaly detection that spots failures spread across many accounts; and lockout tuned by risk, with progressive delays, so a customer who mistypes a password is not the collateral damage.
• Set every threshold from your own measured traffic baseline. A re-authentication storm after a gateway restart looks a lot like an attack.

For instance suppose at 2:40 a.m. the authentication dashboard shows something odd. Failed logins are up, but not on one account: they are spread thinly across thousands of subscriber usernames, a handful of attempts each, from a small cluster of source addresses. Nobody’s password is being guessed. Somebody is checking a list.

That is credential stuffing, and most of what is written about it assumes the target is a web application login form. Broadband operators have a different exposure: RADIUS (Remote Authentication Dial-In User Service) authentication for PPPoE (Point-to-Point Protocol over Ethernet) and hotspot access, carrier Wi-Fi portals, and self-care accounts that sit in front of billing. This article covers how the attack shows up against those surfaces and how the AAA (authentication, authorization, and accounting) layer stops it. If you want the broader picture of what centralized authentication protects against, start with how the telecom AAA server ensures security in networks.

Credential stuffing is an automated attack that tests large lists of leaked username/password pairs against broadband subscriber logins at scale. Unlike brute force, which guesses passwords for one account, it is stopped at the AAA layer by rate limiting, anomaly-based detection, and account lockout tuned so real customers are not punished for a mistyped password.

What credential stuffing is (and isn’t)

The most common mistake in a security review is to file credential stuffing under “brute force” and assume the existing lockout policy covers it. It does not, because the two attacks have opposite shapes.

A brute-force attack works vertically: one username, many password guesses, until something sticks. Account lockout after N failures was designed for this attack, and it works. Credential stuffing works horizontally: many usernames, one or two passwords each, where each pair was already real somewhere else. The attacker is not guessing. They are replaying credentials from a breach at an unrelated service and betting that some fraction of your subscribers reused them. The OWASP (Open Worldwide Application Security Project) Credential Stuffing Prevention Cheat Sheet describes the attack in the web context; the mechanics against a RADIUS server are the same, only the login surface changes.

Because each account sees only one or two failures, a per-account lockout threshold never trips. The signal lives across accounts, not within one, and that is why the defense has to be built at the layer that sees every authentication on the network: AAA.

How credential stuffing targets broadband subscriber accounts

A broadband network exposes more username/password surfaces than operators usually count. Each of them terminates, directly or indirectly, at the AAA server.

The first is RADIUS authentication itself. Where PPPoE or IPoE (IP over Ethernet) with username credentials is still in use, or where hotspot and roaming access uses a username and password instead of SIM-based Extensible Authentication Protocol (EAP) methods, the network access server (NAS) forwards every attempt as an Access-Request defined in RFC 2865. The protocol has no built-in notion of “too many tries”; it answers each request on its merits. An attacker who can reach a login surface that feeds RADIUS can test a list at whatever rate the NAS will forward.

The second is carrier Wi-Fi. Captive portals that accept broadband account credentials to grant hotspot access are, from the attacker’s point of view, a public-facing login form backed by the operator’s subscriber base. Hardening the portal side is its own discipline, covered under carrier Wi-Fi monetization and access; this article covers what the AAA server behind the portal should be doing.

The third is the subscriber self-care portal and app. These typically authenticate against the same subscriber identity the network uses, and a successful login there yields more than connectivity: it exposes billing details, lets the attacker change contact information, order services, or request equipment. Account takeover at this layer is where the fraud and billing-dispute cost is concentrated.

Why are broadband subscribers a worthwhile target? Large subscriber bases, usernames that are often predictable (an account number or an email), and passwords that are set once at installation and rarely changed. A leaked list from any large consumer breach will overlap with that population, and the attacker only needs a small hit rate.

Rate limiting as a first line of defense

Rate limiting is the simplest control and the one most often left at default. The goal is not to block the attack outright; it is to make list-testing slow enough to be uneconomic and visible enough to be caught.

Effective rate limiting at the AAA layer works on more than one key at once. Per-source-address limits catch the naive attacker who runs everything from one host. Per-NAS limits catch a compromised or misconfigured access point pushing far more Access-Requests than its subscriber count justifies. Per-realm and global failure-rate limits catch the distributed attack that stays under every individual threshold but lifts the network-wide failure rate above its baseline. When a limit is exceeded, the server can delay responses, return Access-Reject without consulting the subscriber store, or signal the NAS and upstream firewall to drop the source.

Two cautions. First, the limits must be derived from your own measured traffic, not copied from a guide. A re-authentication storm after a broadband network gateway (BNG) restart looks a lot like an attack, and a limit set without that baseline will reject legitimate subscribers on the worst possible morning. The same baseline work that tells you how your AAA behaves under a peak-traffic surge tells you what a normal failure rate looks like. Second, rate limiting alone is a speed bump, not a wall. Attackers who know the limits distribute the load, slow down, and stay under every threshold, which is the case the next layer handles.

Anomaly-based detection

A rate threshold answers one question: “Is this source sending too much?” A distributed credential-stuffing run is designed to answer “no” to that question at every point while still working through the list. Detecting it means looking at the pattern of failures, not just the count.

The distinguishing signature is spread. A normal night produces failures clustered on a small number of accounts (the customer who changed a router and forgot the password). A stuffing run produces failures spread across a large number of distinct usernames, each with one or two attempts, often in alphabetical or numeric order because that is how the list was sorted. Other markers include a failure-to-success ratio far outside the daily baseline and first-attempt successes on accounts that have been dormant for months. Watch also for a subscriber logging in from a geography or NAS they have never used, and for sessions that start and end in seconds because the attacker was only validating the credential.

This is the kind of pattern that is impractical to encode as a static rule and well suited to anomaly detection that learns what the operator’s own authentication traffic normally looks like. Alepo AAA Server includes the Alepo AI Agent for AAA. It reads RADIUS, Diameter, and TACACS+ (Terminal Access Controller Access-Control System Plus) logs in real time and flags brute-force and credential-stuffing patterns as they develop. It can also trigger security information and event management (SIEM) alerts or firewall rules directly, so the response begins before a human has opened the dashboard. The same telemetry answers the operational question that follows any spike in failures, which is whether the team is looking at an attack or a misconfiguration.

Detection only matters if it is fast. The window between the first validated credential and its use for account takeover can be short, which is why detection belongs at the authentication layer itself and not in a nightly log review.

Tuning account lockout without punishing real customers

Lockout is where security teams and customer-care teams usually disagree, and both are right. A lockout policy strict enough to stop an attacker after three failures also locks out the customer who mistyped a password three times on a new phone, generates a support call, and costs more than the attack it prevented. The NIST (National Institute of Standards and Technology) Digital Identity Guidelines, SP 800-63B, make the same point: verifiers must throttle failed attempts, but a lockout that is easy to trigger can itself become a denial-of-service vector that an attacker turns against your own subscribers.

The way out is to stop treating lockout as one number. Progressive delay, where each consecutive failure on an account adds a growing wait before the next attempt is accepted, defeats automation while staying almost invisible to a human retyping a password. Risk-weighted lockout applies a stricter threshold when the attempt is already suspicious (new source, new NAS, part of a detected spread pattern) and a lenient one when it comes from the subscriber’s usual customer premises equipment (CPE). Short automatic unlock windows replace the permanent lock that guarantees a support ticket. And when a lockout does fire, the subscriber should be told through a channel the attacker does not control, so they learn their password is circulating and change it.

The combination matters more than any single setting. Rate limiting slows the run, anomaly detection identifies it and can push its sources into a stricter posture, and the lockout policy is then only ever aggressive toward traffic that has already been flagged.

AAA-layer defenses against credential stuffing

Defending your broadband network against credential stuffing

If your current defense is a per-account lockout counter, you are defended against brute force and exposed to credential stuffing. Closing the gap means three things: rate limits on more than one key, derived from your own traffic baseline; detection that looks at the pattern of failures across the whole subscriber base rather than one account at a time; and a lockout policy tuned by risk instead of a single threshold.

Put the same three questions to any AAA vendor: rate limits on which keys, anomaly detection across which protocols, and lockout tuned by which risk signals? How much of the answer is engineering effort and how much is configuration depends on the platform underneath. Alepo AAA Server is built to hold the line under attack as well as under load. It runs N+1 and N+N redundancy with real-time database replication and is engineered for 99.999% availability, so a spike in authentication volume during an attack does not also become an availability incident. Custom authorization logic can be applied through its scripting engine and updated in real time without a service restart, and the Alepo AI Agent for AAA is part of the same stack, not a separate product to integrate. Whether you are hardening the AAA server you run today or replacing an end-of-life platform, credential-stuffing defense belongs on the requirements list. If a migration is on the horizon, our AAA migration checklist covers where security policy tuning fits in the cutover plan.

Want to see what a credential-stuffing run looks like on a live authentication graph? Book a demo and ask to see a stuffing run replayed against a test realm: how the Alepo AI Agent for AAA separates the spread pattern from normal traffic and raises the SIEM alert while legitimate subscribers keep authenticating on the same graph. Bring your current lockout policy and we will walk through where a horizontal attack would get past it.

Not ready for a call? Start with the AAA Server solution page and put the security layer in front of your team first.

Frequently asked questions

Q1. What are credential-stuffing attacks and how do they target broadband networks?

Credential stuffing is an automated attack that tests large lists of leaked username/password pairs against subscriber logins. On broadband networks the targets are RADIUS-backed PPPoE and hotspot authentication, carrier Wi-Fi portals, and self-care accounts, all of which terminate at the AAA server.

Q2. How does an AAA server stop credential-stuffing attacks?

Through layered defenses at the authentication layer: rate limiting on Access-Requests per source and per NAS, anomaly-based detection that recognizes failures spread across many accounts, and account lockout tuned by risk rather than a single threshold.

Q3. How does rate limiting help prevent credential stuffing?

It throttles suspiciously high-frequency authentication attempts before they can succeed at scale, slowing list-testing to the point where it is uneconomic and visible. Limits should be set from the operator’s own measured traffic baseline.

Q4. How should account lockout be tuned to stop credential stuffing without hurting real customers? Strict enough to stop automated retries, lenient enough not to lock out a customer over a few mistyped passwords. Progressive delays, risk-weighted thresholds, and short automatic unlock windows achieve both.

Q5. What’s the difference between credential stuffing and brute-force attacks?

Brute force tries many passwords against one account; credential stuffing tries previously leaked, real credential pairs against many accounts, one or two attempts each. Per-account lockout stops the first and misses the second.

Q6. How do I detect a credential-stuffing attack in progress?

Watch for failed authentications spread across a large number of distinct usernames with few attempts each, a failure ratio far above baseline, and successful logins from unfamiliar sources or NAS devices. Anomaly detection on AAA logs surfaces this pattern in real time.

Q7. Why are broadband subscriber accounts targeted by credential stuffing?

Large subscriber bases, predictable usernames, and passwords set once at installation and rarely changed make them likely to overlap with leaked credential lists. A small hit rate is enough to be profitable.

Q8. What happens if credential stuffing isn’t stopped at the AAA layer?

Validated credentials are used for account takeover: service fraud, unauthorized orders and equipment requests, billing disputes, and a loss of subscriber trust that costs more than the attack itself.