Credential Stuffing: What It Is, How It Works, and How to Protect Yourself

Credential Stuffing: How It Works, How to Detect It, and How to Protect Yourself #

Credential stuffing is an automated attack that tests already valid username/password pairs, stolen from third-party breaches or infostealers, against logins to a service other than the original one—it exploits password reuse, not a technical vulnerability.

Credential stuffing exploits an extremely common weakness: the reuse of the same email/password combination across different services. As of June 2025, approximately 16 billion authentication records were identified, spread across numerous datasets, some of which overlapped and fueled by previous leaks and infostealers—not a single new breach, nor necessarily 16 billion unique credentials.

The Verizon 2025 analysis of SSO provider logs found that credential stuffing accounted for a median of 19% of daily authentication attempts, with peaks of up to 25% in enterprise organizations. Password reuse is widespread and is the fundamental condition that makes this attack possible, as documented by OWASP and MITRE.

Key Takeaway: Credential stuffing must not directly compromise the system it attacks. It uses existing credentials and searches for accounts where the same password has been reused—it bypasses firewalls, EDR, and antivirus software because there's nothing "anomalous" about the single request.

Classified by MITRE ATT&CK as T1110.004.

How it works #

The attacker takes username/password pairs already associated from a breach, automates them against a different service, distributing the attempts across many IPs to circumvent rate limiting.

Breach database / dark web / infostealer
    ↓
Combo list: coppie username:password già associate
    ↓
Automazione + proxy pool distribuito (residenziali, botnet)
    ↓
Test su target (login aziendale, VPN, webmail, portali SaaS, API mobile)
    ↓
Account takeover sulle credenziali riusate
    ↓
Lateral movement, data theft, BEC fraud

Attackers distribute attempts across thousands of IPs via residential proxies, mimic the behavior of real users (user-agent, randomized timing), and tailor the configuration to the target's specific login flow.

Tooling Actually Used by Attackers #

Answer capsule: In real-world campaigns, attackers don’t write custom scripts from scratch — they use dedicated tools like OpenBullet, SentryMBA, and Snipr, with pre-built “configs” for hundreds of target sites shared across underground communities.

• OpenBullet / OpenBullet2 — the most popular, open source, configuration file-based tool (.loli/.opk) that define request, response parsing, and success criteria for a specific target
• SentryMBA — one of the first tools dedicated to credential stuffing, with a similar architecture: per-site config + combo list + proxy list
• Sniper — tool with a simplified interface, popular for consumer targets (gaming, streaming, e-commerce)

The typical workflow with these tools:

1. Acquisizione combo list (breach, infostealer, dark web market)
2. Ricerca o creazione di una "config" per il sito target
   (definisce endpoint di login, parametri, pattern di successo/fallimento)
3. Caricamento di una lista di proxy (spesso residenziali, per distribuire i tentativi)
4. Avvio del bot: tenta ogni coppia della combo list attraverso i proxy
5. Output: lista di "hits" (coppie valide) da monetizzare o rivendere

“Configs” for popular tools are shared, sold, or traded in dedicated forums and Telegram channels—knowing about their existence helps understand why even niche platforms, not just large providers, can be the target of targeted campaigns.

The success rate per single attempt is typically estimated between 0,1% and 2% on good quality lists — a low percentage, but on combo lists of millions of pairs it still produces thousands of valid accounts per single campaign.

Credential Sources #

• Third-party breach — databases of compromised services, often aggregated into larger collections
• info stealer — malware that extracts credentials from browsers and uploads them to attacker-controlled C2s
• Phishing — credentials collected from AiTM campaigns or fake login pages (see credential harvesting)
• Dark web market — combo lists sold as commodities

# Verifica se un'email aziendale compare in breach noti
curl "https://haveibeenpwned.com/api/v3/breachedaccount/user@company.com" \
  -H "hibp-api-key: <API_KEY>"

Difference between Password Spraying and Brute Force #

Answer capsule: Credential stuffing uses existing password pairs from a breach, password spraying tries a few common passwords across many accounts, and brute force systematically generates combinations—these are three distinct attacks with different detection logics.

In a pentest, the distinction is substantial: credential stuffing verifies whether employee credentials have already been compromised and reused; password spraying verifies the effectiveness of password policies.

Testing Defenses: Correct Methodology #

Answer capsule: An authorized credential stuffing test uses synthetic, pre-associated username/password pairs, never generic wordlists like rockyou.txt — otherwise you're simulating brute force, not credential stuffing.

A loop that tries many different passwords on a single username, or a dictionary like rockyou.txt with Hydra, simulates brute-forcing a single account , not credential stuffing. Credential stuffing tries already-matched pairs, typically obtained (in an authorized test) from a specially created synthetic set.

Correct methodology for an assessment:

1. Create synthetic accounts dedicated to testing
2. Generate synthetic and controlled username/password pairs, approved by the customer
3. Use a staging environment when available
4. Agree on a maximum number of attempts
5. Define a stop condition to avoid lockouts and service interruptions
6. Measure rate limiting, challenges presented, alert time, detection latency
7. Never use real credentials found in public leaks, not even in an authorized test.

# Esempio concettuale — coppie sintetiche pre-accoppiate, non wordlist generica
# username:password già associati, creati per il test, numero limitato e concordato
cat synthetic_pairs.txt
# testuser01:Sy1nth#Pair!
# testuser02:Sy2nth#Pair!

# Test con numero di tentativi limitato e stop condition esplicita
while read -r pair; do
  user=$(echo "$pair" | cut -d: -f1)
  pass=$(echo "$pair" | cut -d: -f2)
  curl -s -o /dev/null -w "%{http_code} $user\n" \
    -X POST https://staging.target.com/login \
    -d "username=$user&password=$pass"
  sleep 1
done < synthetic_pairs.txt

Check for rate limiting: Observe whether HTTP 429 appears, whether an adaptive challenge is presented, and after how many attempts—without exceeding the threshold agreed upon with the client.

Pwned Passwords and Preventive Control #

The section on Pwned Passwords remains valid: the service uses k-anonymity, receiving only the first 5 characters of the SHA-1 (or NTLM) hash, never the cleartext password.

hash=$(echo -n "Password123" | sha1sum | cut -d' ' -f1 | tr '[:lower:]' '[:upper:]')
prefix=${hash:0:5}
suffix=${hash:5}
curl "https://api.pwnedpasswords.com/range/$prefix" | grep "^$suffix"

Three important clarifications:

• a password found in the corpus should be rejected, but the absence from the corpus does not guarantee that it is strong
• the check must be performed both when creating and changing the password
• Monitoring a business domain requires domain verification and a suitable business plan

NIST explicitly requires that new passwords be checked against a blocklist of common, predictable, or previously compromised values.

Defender Side Detection #

Answer capsule: Detection should never rely on comparing cleartext passwords in logs — it relies on attempt-to-account ratios, distributed fingerprints, and behavioral patterns, with adaptive, non-fixed thresholds.

A secure application does not record passwords entered, even incorrect ones — so detection cannot and should not correlate “the same password tested across multiple accounts.”

Helpful signals:

• many distinct usernames proven by the same source or fingerprint
• few attempts per single account, but very high overall volume
• spikes in the failed/successful login ratio
• requests from different IPs but with similar fingerprints, headers, or behavior (indicating distributed automation)
• Successful login from new device after a series of errors on the same account
• accesses from geolocation or ASN incompatible with the history
• Automated logins against mobile APIs, SSO, VPN, RDP, or SaaS
• sequences of “low and slow” errors distributed over time

MITRE has published a dedicated detection strategy, DET0460 , which covers identity providers, SaaS, Windows, Linux, macOS, network, and containers.

Thresholds should be adaptive, not fixed: an "abnormal" number of attempts for a small corporate VPN may be completely normal for a platform with millions of users. They should be calibrated based on the baseline of the specific endpoint, unique users involved, failure/success ratio, IP/ASN, account history, and time zone. Residential IPs, VPNs, and Tor are risk signals to be weighed , not automatic reasons for blocking.

Rate Limiting and Lockout: Beyond Simple “N per IP” #

Answer capsule: A rate limit based solely on IP is easily circumvented by a distributed botnet; combined scoring across multiple dimensions is required, and the hard lockout can itself become a denial-of-service vector.

Dimensions to combine in scoring:

• account
• IP address
• subnet/ASN
• device or browser fingerprint
• Session
• endpoint-level
• number of distinct usernames attempted
• time interval

A strict lockout allows an attacker to deliberately lock out thousands of accounts (targeted denial of service) — OWASP recommends careful design. Recommended progressive approach:

1. increasing delay
2. adaptive challenge
3. step-up authentication (requires additional second factor)
4. temporary, not permanent limitation
5. block only for high related risk
6. user notification

Note: HTTP 423 should not be used as a universal indicator — the client-visible response should remain generic to avoid user enumeration.

CAPTCHA and Bot Detection: They Are Not Synonyms #

CAPTCHA increases the cost of automation but doesn't block advanced automated browsers or commissioned human resolution services. It should be used adaptively (only on suspicious patterns, not on every login) and isn't a substitute for a layered defense: by itself, it doesn't prevent account takeover when the attacker already has valid credentials.

Distributed and Low-and-Slow Attacks #

Answer capsule: Residential proxies and botnets allow for only a few attempts per IP, making a block based solely on volume per address ineffective.

Blocking a single IP isn't enough when the attacker has thousands of addresses at his disposal: each IP generates a seemingly normal volume of requests, but the aggregate reveals the pattern. Effective detection must correlate at the campaign level—same TLS/JA3 fingerprint, same timing behavior, same set of target usernames—not at the individual address level.

Attack Surfaces #

Credential stuffing doesn't just affect the web login form:

• Direct Authentication APIs
• mobile applications
• SSO portals
• webmail
• VPN
• RDP and Remote Access Services
• SaaS platforms
• consumer accounts linked to business services
• Password recovery and reset endpoints (often less protected than the main login)

Account Takeover after Successful Login #

Answer capsule: The attack doesn't end with a successful login — the attacker consolidates access by modifying recovery emails, MFA, and credentials, before monetizing or moving laterally.

After a successful login, typical attacker steps include:

• edit recovery email
• change password
• registration of new MFA methods
• data theft
• financial fraud
• unauthorized purchases
• Business Email Commitment (BEC)
• persistence via tokens/valid sessions
• Resale of the validated account on the black market

Incident Response after an Account Takeover #

Defensive Checklist:

1. Revoking active sessions
2. Password reset
3. Invalidation of refresh tokens
4. Removing unknown MFA methods registered by the attacker
5. Checking email forwarding/filtering rules
6. Checking for new registered devices
7. Analysis of subsequent accesses for lateral movement
8. Notification to the affected user
9. Finding the same credential pattern on other accounts in your organization

Pentest Report Metrics #

For a credible assessment, include in your report:

• number of synthetic pairs tested
• percentage blocked by rate limiting/lockout
• time elapsed until the first alert was generated
• percentage of attempts subjected to MFA step-up
• false positives observed
• endpoints without rate limiting (web vs API vs mobile)
• ability to enumerate users from system responses
• effectiveness of the agreed stop conditions

Mitigation #

Layer 1 — Credentials

• Automatic password checking against database breach (API Pwned Passwords) upon creation/change
• Password manager and unique passwords per service
• Dark web monitoring for corporate credential leaks (verified domain)

Layer 2 — Authentication

• Passkey/FIDO2 — radically reduce credential stuffing by not using a shared, reusable password on the normal login path. Protection remains incomplete if the system maintains password fallback, weak recovery via email/SMS, or an easily manipulated help desk.
• MFA on all accounts — reduces impact even with compromised credentials
• Conditional Access — blocks access from anomalous IPs, unknown devices, and unusual geolocation

Layer 3 — Bot Detection

• Rate limiting with combined scoring (not just for IP)
• Adaptive CAPTCHA only on suspicious patterns
• Browser fingerprinting and JavaScript challenge
• Bot management (Akamai, Cloudflare) to identify traffic from known residential proxies

Layer 4 — Monitoring

• Alerts on anomalous ratio of failed attempts/involved accounts, not on a fixed threshold
• Campaign-level correlation (fingerprint, timing, target set)
• Continuous monitoring of breaches for exposed corporate credentials

Real-World Cases of Credential Stuffing and Stolen Credential Abuse #

Answer capsule: Not all known incidents involving stolen credentials are credential stuffing in the strict sense—the distinction between automated reuse and simple abuse of compromised credentials is important to avoid generalizing.

Roku (2024) Credential stuffing confermatoRoku attributed the access to approximately 576.000 accounts to credential stuffing, saying it found no evidence that the credentials originated from its systems.

Snowflake (2024) Credenziali da infostealerMandiant traced the UNC5537 campaign to Snowflake customer credentials stolen via infostealers on employees' personal machines, not to a compromise of Snowflake infrastructure or necessarily to automated reuse in the strict sense.

Change Healthcare (2024) Valid accounts / origine non completamente documentataThe use of compromised credentials against a Citrix portal without MFA has been confirmed; there is no public evidence that those credentials were validated through an automated credential stuffing campaign.

The common denominator, however, remains the same: non-mandatory MFA and no preventive verification of credentials for known database breaches.

Other known cases of confirmed credential stuffing:

• The North Face / VF Corporation (April 2025) Credential stuffing confermatoFourth such incident involving VF Corp brands since 2020; customer data and order history exposed, but no payment data (managed by third-party processors).
• Reddit — Users locked out en masse after a wave of credential stuffing attempts; affected accounts forced password resets
• TurboTax (2019) — access to tax returns and sensitive data (including SSN) via reused credentials
• HSBC — unauthorized access to approximately 14.000 customer accounts via stolen credentials, resulting in temporary suspension of online logins
• Australian Superannuation Funds (March 2026) — coordinated credential stuffing attempts detected across multiple funds (AustralianSuper, Rest Super, Hostplus, Australian Retirement Trust, Insignia Financial) within the same timeframe, indicating a centralized campaign targeting an entire industry

FAQ #

What distinguishes credential stuffing from brute force? Brute force generates candidate passwords for an account. Credential stuffing uses already valid and associated username/password pairs, obtained from breaches—the success rate is very different: brute force on strong passwords can take years, whereas credential stuffing has a measurable hit rate on good-quality lists.

Does 2FA protect against credential stuffing? Most MFA factors (TOTP, SMS, push) drastically reduce the impact, because even with valid credentials, the attacker must overcome the second factor. Only passkey/FIDO2, on a truly passwordless path, eliminates the vector at its root.

How do I verify if my company credentials are involved in a public breach? HaveIBeenPwned with Domain Search (domain verification required), or continuous monitoring services like SpyCloud or Recorded Future.

Conclusion #

Credential stuffing is one of the attacks with the highest ROI for an attacker: no exploits, no vulnerabilities to search for, just automation on existing credential pairs. In a pentest, testing it correctly means using pre-matched synthetic pairs—never generic wordlists, which would simulate brute force—and measuring rate limiting, step-up MFA, and detection latency. An effective defense is layered: technically brute-forced unique passwords, robust MFA (ideally passkey/FIDO2 with equally robust recovery), multidimensional behavioral scoring, and active breach monitoring.

Resources:

• MITRE ATT&CK – T1110.004
• MITER – DET0460 Detection Strategy
• OWASP – Credential Stuffing Prevention Cheat Sheet
• OWASP – Authentication Cheat Sheet
• Have I Been Pwned – Pwned Passwords