At Sqreen, our mission is to make security transparent and accessible to everyone. Part of that mission includes sharing what we learn about security and what happens if we get attacked. In this post, we want to share the details of an Account Takeover (ATO) attack against our own internal Sqreen deployment, how we mitigated it, and what we learned.
As a company building and selling an Application Security Management platform, we of course use Sqreen to protect ourselves. On the night of June 28th, 2019, we started getting Sqreen alerts about an in-progress distributed ATO attack happening against ourselves!
Here are the high-level facts: The attack lasted for 15 minutes, and resulted in a total of two inactive accounts getting compromised, which we locked 34 minutes after the initial compromise. The attacker(s) were unable to do anything with the two inactive accounts.
A quick primer on ATO attacks: ATO attacks are attempts by attackers to login to your users’ accounts. They generally come down to attackers repeatedly using common or leaked passwords to try and access some of your users’ accounts. Usually, only users that have weak passwords or that are reusing them across websites can be taken over this way. The purpose of these attacks is to get more access to the application, since logged-in users generally have a greater level of access than non-logged-in users.
The value of logged-in accounts holds true in the case of Sqreen, as Sqreen accounts have access to sensitive data, from traffic volumetry to the internal architecture of our users’ applications.
If a bad actor gets access to an active user account, they could also use the account to pinpoint an application’s vulnerabilities (thanks to alerts raised and not acted upon) and disable Sqreen’s protection before an attacker exploited the vulnerabilities they found.
This is why we take ATO attacks extremely seriously.
What happened during the ATO attack?
During the night of June 28th, at 2:40am CET, Sqreen started generating ATO alerts on our Slack instance. The cause of the alerts was one of our Sqreen Playbooks blocking IPs that were attempting (unsuccessfully) to login to many user accounts.
This specific Playbook had a fairly permissive failed login cap, in order to ensure that we didn’t block legitimate users that had forgotten their password. So before triggering the blocking threshold of this Playbook, the attacker(s) had time to try many login attempts.
Once we started getting alerts about the attack, we immediately lowered this threshold to a very aggressive value for the duration of the attack, preferring to block a potential poorly timed forgetful user rather than allowing the attack to continue.
The attacker was sophisticated, and adapted quickly. They began attempting to circumvent the new protection limits by leveraging a large amount of IPs with a low number of login attempts per IP, likely via a botnet. Essentially, rather than attack a small number of accounts many times each, the attack turned into one login attempt per account, spread across many accounts, by many different IP addresses. By the end of the attack, we had blocked 700 different IPs!
So let’s take a look at the results of the attack. We mentioned earlier that throughout the attack, a total of only two inactive accounts were compromised. The first account was compromised at 2:44am, four minutes after the attack began, while the other was compromised at 2:49am. Both of the compromised accounts were very old, inactive accounts that no longer had any data of interest to attackers.
The attacker connected into both accounts using an IP from a hosting company based in the Netherlands. They explored the accounts, but both were empty of any PII or interesting data, and therefore of no use to the attackers.
The attack abruptly stopped at 2:55am, likely when their botnet credit expired. In total, the attack ran in force for 15 minutes, compromised two old, inactive accounts with no PII exposure, and was otherwise fully foiled.
A look at our mitigation of the ATO attack
Sqreen is a company building an application security solution. It’s always interesting to see Sqreen in action, so this sophisticated ATO attack was a good opportunity to dogfood our own protection.
The attack targeted our business logic (trying to exploit logins), without attempting any kind of injection. The protection element of our ASM platform that covers injections and similar attacks was therefore not triggered.
As we mentioned, this was a sophisticated attack. The attacker was rotating IPs very quickly, and was only attempting one login per account. That means the login activity would have appeared mostly normal without Sqreen integrated into our login process! This is one of the reasons that we’ve integrated our login process with Sqreen, which let our backend know that many users were under an ATO attack, despite the attacker only attempting a single login per user account.
The key element here is the abstracted pattern that Sqreen was able to provide to us. On an account level, one failed login attempt is meaningless. However, Sqreen was able to see the failed logins across thousands of accounts from a set of IP addresses, and therefore was able to determine what was an attack and what wasn’t. Without Sqreen, nothing would have seemed particularly amiss.
One of the powerful features of Sqreen is our Playbooks. Playbooks are flexible automated security responses that users can create and define for many scenarios. They follow an “if this, then that” style so users can protect against a wide range of situations that correspond to malicious activity for their particular business. At Sqreen, we have a Playbook set up to deal with ATO attacks, and as such, it started mitigating the attack without any action on our end. The protection looked at unusual patterns of login for users or from IPs and detected the ATO by itself.
The real world impact of this Playbook was that it started mitigating the attack before we even became aware of it! Each IP was only able to attempt a limited number of failed logins across any account before they got blocked automatically. Once we became aware of the attack, we were able to act immediately act to mitigate the ongoing attempts.
The login activity [by the attacker] would have appeared mostly normal without Sqreen integrated into our login process!
It was gratifying to see how reactive Sqreen’s protection was, but on top of that, the data we collected was incredibly useful for piecing together more information about the attack after the fact. We were able to get an extensive list of the 43,387 email addresses that were targeted (each email address had one login attempt by the attacker).
We quickly discovered that the database didn’t come from us (the vast majority of the email addresses were not associated with users of our product), but also that it was not from known public dumps. This suggests that the attackers bought the list from a black market or gathered it themselves through other means. We also looked at the IP addresses that conducted the attack and were able to confirm that this likely wasn’t some kind of spoofing. The geographical distribution and representation of the IPs made sense.
During the attack, Sqreen triggered an alert each time the attackers logged into the two inactive accounts that they compromised. As such, we were able to isolate the IP that the attacker used. After the attack ended, we did some basic recon to study what this IP did before and during the attack. We were able to determine that they weren’t able to do much with the inactive accounts they gained access to.
As a precaution against future attacks or aftershocks, we blocked the entire IP range from the hosting provider that this IP came from as a way to get a warning if the attacker ever reused this provider, which didn’t end up happening.
The key takeaways
The speed at which Sqreen let us know that we were being attacked and the data it collected during the attack was incredibly useful in limiting and negating the potential impact of the ATO attack. It was a nice validation of the Playbook we had set up and of Sqreen’s capabilities.
Not everything was perfect, of course. We gathered some great learnings from the ATO attack that we are applying towards improving in the future. For example, during the attack, we realized our dashboard could become overwhelmed with information that isn’t very actionable. The flood of alerts did an excellent job at getting our attention and helping us spring into action, but after we were engaged, the volume of alerts wasn’t helpful.
The main thing we would have liked during the ATO attack was more automation, and specifically a means to let Sqreen’s business logic know that an attack was in progress. With this information for example, we could have been able to (automatically?) inject a CAPTCHA field in the login page, slowing down the attack even further.
Conclusion
The ATO attack against Sqreen was a great reminder of the importance of application security. It was fairly sophisticated (it used an unknown database, and a distributed botnet), but also not that unusual either.
The main risk of such an ATO attack is that they go undetected and give a beachhead to attackers (two compromised accounts diluted in 43,387 login attempts is easy to miss without a good solution in place). Had the attackers been able to compromise more sensitive accounts, they could have disabled their protection or dug into specific vulnerabilities.
ATO attacks are almost impossible to completely eliminate (your users must be able to login themselves after all), but we can make them harder and more expensive for attackers with good processes and protections.
As it stands today, Sqreen already does a good job of that by quickly blocking the IPs performing the attack. The next step on hardening this is to influence the business logic to dynamically make the attack harder without impacting the UX of users the rest of the time.
Sqreen gave us a lot of visibility and traceability into the attack that wouldn’t have been available from our business logic alone. We were notified immediately about the attack, and were able to rapidly respond and protect our users against the attackers. Of course, Sqreen isn’t perfect, and we’re happy to have a few ideas for improvement in this specific area.
We’ve taken notes during the attack and in the aftermath of the pain points we ran into, and how we could have made our ATO protection more helpful — from alerting to automation to UX. This will impact the evolution of our ATO protection in the coming months, and we’re excited about what we’ll be rolling out soon. Stay tuned, and feel free to take Sqreen for a spin to see for yourself what we’ve been talking about in this post.
