A SaaS Provider’s Journey to Account Takeover Protection

A global productivity SaaS platform provider thought they were facing a DDoS attack due to an intense spike in requests to their login page. An investigation, conducted with the help of Red Button consultants, revealed that it was an account takeover (ATO) attack. Hackers had been using a database of leaked credentials in an attempt to access the cloud platform for over a month.

The company’s login process for customers included three different authentication paths – standard password submission, multi-factor (MFA), and single-sign-on (SSO). In practice, however, only 2% of users took advantage of the MFA or SSO options. Bot detection provided an additional advanced verification layer as an integral part of the flow.

Despite these general precautions, the ATO exposed a gap in security and response planning. Such an attack, if successful, could have exposed the company to a serious data breach, financial loss and reputational damage.

The Solution

After black-box reconnaissance on the login flow to identify vulnerabilities, we simulated four ATO attacks over the course of three days. Focusing specifically on password-cracking scenarios, we attempted email enumeration, credential stuffing, password spraying, and a dictionary attack on the authentication host.

Using a set of 300,000 user-password credentials from a known data breach, we calibrated the scenarios to challenge the company’s ATO defenses against both stealthy and high-velocity attacks. To simulate a distributed attack and evaluate the impact of IP diversity on detection thresholds, we ran each session across an average of 10 machines provisioned from multiple cloud providers.

The Results

The results were clear – and worrisome. Email enumeration – a rapid series of requests intended to discover whether specific email addresses exist within a system – was not prevented. A request rate below the preconfigured Cloudflare threshold was not detected, while higher request rates were detected but not mitigated. Our bots were able to bypass the enforced Java challenge and the company’s data security team had no active protocol in place. Notably, we were able to identify valid accounts based on system reactions to the various login attempts, which can be used for other ATO attacks.

The credential stuffing and password spraying attacks were not detected or mitigated, except when targeting accounts with the optional MFA or SSO settings in place. The dictionary attack scenario, in contrast, was detected and mitigated by the system using Google’s reCAPTCHA mechanism, which triggered a human challenge response requirement.

Recommendations

The ATO simulations successfully demonstrated the ability to execute multiple, automated login requests to breach the company’s defenses. As a result, we recommended the following measures:

• Implement more discreet login responses – Stop attackers from discovering which email addresses are linked to accounts and which have weaker security configurations.
• Strengthen rate-limiting rules – Apply more stringent rate limits for failed login attempts to prevent attackers from repeatedly testing passwords.
• Expand Cloudflare ATO detection feature – Configure existing security features to block attacks using leaked email addresses, not just leaked or guessed passwords.
• Develop formal response plans – We helped the company create a playbook to respond to common ATO scenarios, but it needs to be regularly updated to ensure consistent, effective action.
• Create ATO alerts – An alert should be configured to notify data security teams of suspected successful ATO logins, indicating a potentially compromised account.
• Enhance access management policies – This includes encouraging wider adoption of MFA and SSO, which dramatically reduce the risk of unauthorized access, as well as increasing password strength and updating requirements.