A Quiet Tuesday Turns Into a SaaS Security Incident
Every credential stuffing prevention story starts the same way. A security team is deep in a sprint, Jira is on fire, and nobody is watching the login telemetry dashboard. Then a threshold trips, a Slack alert fires, and the next forty-eight hours decide whether the company ends up in a breach notification or a post-incident retro.
This case study follows a mid-sized SaaS startup, anonymized here as Northfield, through exactly that scenario. Northfield has roughly four hundred employees, eighty thousand paying end users, and a product that handles sensitive business data. Their story is a textbook account takeover case study in SaaS security, and it illustrates why early breached password alerts change the math on credential stuffing.
The Company and the Attack Surface
Northfield runs a fairly standard modern stack:
- Single-tenant product with email-and-password login plus optional TOTP MFA
- Okta for workforce identity, with SSO pushed to all internal tools
- Cloudflare in front of the public product, with basic rate limiting enabled
- A small SOC of four analysts covering both corporate and product security
Their customer base skews toward mid-market operations teams. Roughly sixty percent of end users had MFA enabled. The other forty percent relied solely on passwords, and that gap defined the attack surface the adversary eventually exploited.
Early Warning Signs
The incident did not start with a breach notification. It started with anomalies in the product login telemetry.
Login Velocity Spike
At 02:14 UTC on a Tuesday, Northfield's login velocity jumped from a baseline of roughly eighteen requests per second to a sustained one hundred and forty. The traffic was geographically distributed across residential IP space, which is the signature of a modern credential stuffing toolkit routing through proxy networks.
Failed Authentication Anomaly
The failed auth rate climbed from a healthy four percent baseline to twenty-two percent within the first ten minutes. Distribution across user accounts was unusually flat. Instead of a few accounts getting hammered, the attacker was cycling through a large list and trying one or two passwords per account, the classic low-and-slow pattern designed to evade per-account lockout thresholds.
The Tooling Fingerprint
Northfield's on-call engineer pulled a sample of user-agent strings and TLS fingerprints. The pattern matched known configurations from OpenBullet and Silverbullet, two of the most widely circulated credential stuffing frameworks on underground forums. The request bodies used the exact field ordering that OpenBullet default configs emit, and the JA3 hashes clustered around two values that had been flagged in community threat feeds earlier that month.
The Investigation
With a credible credential stuffing hypothesis, the SOC moved to answer the critical question: where did the credential list come from, and how many Northfield users were on it?
Revealer.US Flagged 1,240 Matching Exposures
Northfield had onboarded Revealer.US six months earlier specifically to cover their customer identity surface. Within forty minutes of the velocity spike, the SOC ran a batch lookup of the one hundred email addresses that had received the most login attempts. Ninety-three of them showed up in recent stealer log drops and combolist reshares.
A broader sweep across all active customer accounts returned 1,240 matches against recent exposures. Many of the hits traced back to two sources:
- A third-party SaaS vendor breach from the prior quarter that had leaked email and password pairs for several million users.
- A combolist distributed on a Telegram channel two weeks before the Northfield attack, which itself was a repackaging of older breach data joined with fresh stealer logs.
The overlap explained the attacker pattern perfectly. They were not targeting Northfield specifically. They were running a generic list against every consumer SaaS login they could find, and Northfield happened to have meaningful overlap with the source corpus.
The Response
Northfield's incident response playbook for credential stuffing had three phases, and the team executed all three inside a four-hour window.
Phase 1: Immediate Containment
Within the first hour:
- CAPTCHA challenge enabled on all login attempts from IP ranges matching the attack fingerprint.
- Tightened rate limiting at the Cloudflare edge, dropping the per-IP login budget from sixty per minute to six.
- Geo-based friction added for any login attempt originating from ASNs with more than three failed auths in the prior hour.
These steps did not stop the attack. They were designed to slow it down enough to buy time for the real remediation.
Phase 2: Targeted Password Resets
With the 1,240 matched accounts identified, Northfield triggered a forced password reset across the entire set. The reset email was templated to avoid panic, explained that the user's credentials had been seen in a third-party data exposure, and required both a new password and MFA enrollment before the account could be used again.
By hour three, roughly forty percent of the affected users had completed the reset flow. The remaining sixty percent were flagged for step-up MFA on their next login attempt.
Phase 3: Bot Mitigation and Monitoring
In parallel, Northfield pushed a change to their product that:
- Required MFA enrollment for any account showing up in Revealer.US exposure data going forward
- Added login anomaly detection based on IP, device, and velocity features
- Piped all authentication events into their SIEM with a dedicated credential stuffing dashboard
The Outcome
The numbers tell the story better than any narrative.
Projected vs Actual ATO Count
Based on Northfield's historical baseline of credential stuffing success rates (roughly four percent of matched accounts get taken over in a typical attack), the expected account takeover count for this wave was between forty-nine and sixty. The actual number at the end of the incident was zero. No confirmed account takeovers, no downstream fraud, no customer complaints tied to unauthorized access.
Incident Timeline
A compressed incident timeline from the Northfield retro:
- T+0 minutes: Login velocity anomaly detected, on-call paged.
- T+12 minutes: OpenBullet fingerprint confirmed, credential stuffing hypothesis logged.
- T+40 minutes: Revealer.US batch lookup returns first exposure matches.
- T+58 minutes: CAPTCHA and rate limiting deployed at the edge.
- T+2 hours: Full 1,240 account list identified and password reset emails sent.
- T+4 hours: Attacker traffic drops below baseline as the cost of continuing exceeds the yield.
- T+24 hours: Post-incident review complete, permanent controls in place.
What Made the Difference
Northfield's SOC lead later summarized the incident in one sentence at the retro: the breached password alerts told us who to protect before the attacker told us which accounts they wanted. Every other control, from rate limiting to CAPTCHA, only bought time. The list of matched exposures turned that time into action.
Lessons for Other SaaS Teams
For other SaaS startups sitting in a similar risk profile, Northfield's experience suggests a short list of takeaways:
- Monitor customer identities, not just employees: Your product login is part of your attack surface, and credential stuffing attackers do not care about the distinction.
- Pair breach data with auth telemetry: Exposure alerts are exponentially more valuable when correlated with real-time login anomalies.
- Automate the boring parts: Forced resets and MFA enforcement should be one API call away, not a ticket in a queue.
- Rehearse the playbook: Northfield had run a tabletop exercise on this exact scenario the quarter before. It showed.
- Invest in early warning: A feed that surfaces exposures in hours rather than weeks is the single biggest lever in credential stuffing prevention.
Conclusion
Credential stuffing is not a sophisticated attack. It is a commoditized one, and that is exactly why it keeps working. Attackers buy combolists on Telegram, load them into OpenBullet, and point the tool at whatever login surface is cheapest to break. The only durable defense is to know which of your users are on those lists before the attacker does, and to act faster than the bot farm can adapt.
Northfield did not stop credential stuffing forever. They stopped one wave, learned from it, and hardened their stack for the next one. That is what a functional SaaS security program looks like in 2025.
Want to catch credential stuffing attacks before they land? Start a free trial of Revealer.US and turn breach exposure data into a real-time early warning system.