Use Case: Identity
Credential stuffing detection
A breach list from 2022 is being tested against your SSO login. 1.8% success rate. 340 valid accounts identified in 40 minutes. ManySignal spotted the campaign pattern at attempt number 12.
When the password database is someone else's problem
Credential stuffing works because password reuse is epidemic. When a user creates an account on a third-party site that later suffers a breach, their email and password combination enters the credential marketplace. If they use the same password for their corporate SSO — and statistically, 65% do — the breach becomes your breach.
Professional stuffing operations use tools like Openbullet 2 with custom config files for each target application, residential proxy networks to distribute traffic, and CAPTCHA-solving services. The resulting traffic can be indistinguishable from normal user traffic at the per-request level. Only aggregate analysis reveals the campaign.
rule: credential_stuffing_campaign
type: statistical + threat_intel
trigger:
- condition: |
auth_success_rate(window=15m) > 0.3%
AND source_ip_count > 50
AND avg_attempts_per_ip < 3
- OR:
- condition: |
hibp_match_rate(attempted_credentials) > 60%
AND residential_proxy_score > 0.7
enrichments:
- breach_correlation: hibp, spycloud
- ip_type: residential_proxy_classifier
- success_post_activity: first_action_after_login
- threat_sharing: isac, manysignal_intel
mitre: T1110.004 (Credential Stuffing)Are the attempted credentials present in known breach datasets (HIBP, SpyCloud)?
Breach intelIs the traffic volume and geographic distribution consistent with a stuffing tool (Snipr, Openbullet)?
Traffic analysisWhich accounts succeeded, and what was the first action post-login?
IdP + activity logAre the successful logins from residential proxies or datacenter IPs?
IP classificationHas success rate stabilized, indicating a valid credential list rather than random guessing?
Statistical analysisAre there concurrent stuffing campaigns against related organizations?
Threat intel sharingEnable CAPTCHA or challenge-response for the targeted auth endpoint
AutonomousForce password reset for any account that succeeded during the stuffing window
AutonomousAdd the residential proxy ASN ranges to the IdP conditional access block list
Approve-gatedSubmit valid credential pairs to SpyCloud for campaign attribution
RecommendMITRE ATT&CK mapping
Credential stuffing FAQ
How is credential stuffing different from brute force?
Brute force tries systematically generated passwords. Credential stuffing uses real email/password pairs from breach datasets — pairs that worked on another site. Success rates are much higher (0.5-2% vs <0.001% for brute force) because many users reuse passwords.
Can ManySignal detect stuffing that uses residential proxies to avoid rate limiting?
Yes. Residential proxy traffic has a distinctive distribution pattern: high geographic diversity, specific ASN fingerprints (IPRoyal, Smartproxy, Luminati/Bright Data), and atypical user agent distributions. ManySignal's IP classification model identifies residential proxy traffic with 94% precision.
What's the impact if stuffing succeeds against our SSO?
A successful SSO credential stuffing attack gives the attacker access to all apps federated to that IdP. ManySignal automatically checks the post-authentication activity of any account that succeeded during a known stuffing window, treating each as a potentially compromised account.
Does ManySignal help with credential stuffing against our customer-facing applications?
Yes, via the ManySignal API ingestion connector. Customer-facing apps can emit authentication events to ManySignal's pipeline, where they receive the same cross-IP correlation, breach-list enrichment, and behavioral analysis as internal IdP events.
Stop credential stuffing before valid accounts are compromised
Breach-list correlation, residential proxy detection, and campaign-pattern analysis — all in one alert.