A Quiet Tuesday Turns Into a SaaS Security Incident
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. It is an account takeover case in SaaS clothing, and the math on credential stuffing changes the moment you know which passwords are already in a dump.
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
Nobody sent a breach notification. The first signal was ugly login telemetry on the product itself.
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
Once OpenBullet was on the table, the SOC needed two answers before they started resetting people: where the list came from, and how many Northfield users were on it.
Revealer.US Flagged 1,240 Matching Exposures
Northfield had started using Revealer.US six months earlier to cover their customer identity surface. Within forty minutes of the velocity spike, the SOC ran a batch email lookup of the one hundred 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 breach 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 traffic. Nobody had targeted Northfield. They were running a generic list against every consumer SaaS login they could find, and Northfield had enough password reuse against that corpus to light up.
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.
None of that stopped the attack. CAPTCHA, rate limits, and geo friction only bought time for the targeted resets.
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
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
If you run a SaaS login that still accepts passwords, steal these before the next Tuesday at 02:14 UTC:
- 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 more useful 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 clever. It is cheap, which is why it still works. Attackers buy combolists on Telegram, load them into OpenBullet, and point the tool at whichever login is cheapest to break. The durable move is knowing which of your users are on those lists before the bot farm does, then forcing resets and MFA while the yield is still bad for them.
Northfield did not stop credential stuffing forever. They stopped one wave, wrote down what worked, and hardened the stack for the next list. That is what a functional SaaS security program looks like when the next combolist drops.
Want to check whether customer emails already sit in breach dumps and stealer logs? Start with a data breach lookup on Revealer.US. Paid plans start at $12.99/mo; see pricing.