Managing ATOs When Online Engagement Is at a Peak [video blog]

In the last couple months as the world has been in quarantine with social distancing and working from home, we have seen big spikes in online user activity. Even with shelter-in-place easing up, we don’t see that increase changing. While some industries have been hit hard, many digital businesses are seeing even greater demand than anticipated and others are now more reliant than ever on digital avenues for revenue. In times of uncertainty, attackers don’t sit back, they lean into the opportunity looking for ways to join the noise and compromise credentials for account takeover or commit fraud once they have successfully gotten past login. How do organizations balance risk and trust to protect users at every stage of their online experience?

The impact for many security teams has gotten more significant just based on the sheer volume of d activity coming from new and existing users. Customers are engaging at a high capacity and businesses definitely don’t want to hurt customer experience at this sensitive time. Whether it's at online registration, at log-in, or during a financial transaction, many organizations now rely on digital avenues as their sole channel for revenue. At the same time, due to budgeting, many security and support teams struggle with staying a step ahead and getting the support needed to help with increased online demand while keeping users secure.

It's easy for attackers to mask themselves as legitimate users. ATOs are the most common ways for user accounts to be compromised. Credential stuffing is one of the top methods for perpetrating these attacks because it is an automated way of using stolen usernames and passwords to gain fraudulent access to online accounts.  Attackers will use the credential stuffing method to gain access into the account and perform a variety of malicious activities like identity theft, financial fraud, data exfiltration, and the list goes on.

Credential stuffing attacks are preferred by attackers because they’re cheap, easy, and very profitable. To execute them, attackers can leverage bots. Today’s malicious bots have gotten much more sophisticated. They simulate basic human interactions, such as simple mouse movements and keystrokes to get past traditional bot detection tools. They can breach a user session by mimicking how a user behaves throughout the entire session, not just at the log in. [Note: If your organization is currently struggling with automated attacks like fake registration, watch our Beating Bad Bots on demand webinar.

So, how do you stop these bots? The main problem with relying on traditional bot detection vendors and Web Application Firewalls (WAFs) is that they are still perimeter solutions. Bots are now mimicking human behavior and proliferating inside the application and perimeter solutions are not enough. To prevent these latest bots, security solutions need to be both identity-aware where they are looking at user behavior all the way from registration through in-app usage and they also need to provide real-time detection, prevention, and workflows to block and remediate. Without these capabilities, you would be blocking legitimate users and pushing the added burden onto support teams to help your customers get back into their accounts, ultimately hurting the customer experience and consequently your revenue.

Ideally, we offer ways to make it easy for organizations to offload much of that support and operational workload by prompting a security challenge when risky user activity is detected. Multi-Factor Authentication (MFA) today is now an industry best practice. It can protect against automated and human powered attacks, however, these tools were designed primarily for a one-time identity verification. They were not designed with total user experience in mind and do not take into context all of the nuances of user events and activities occurring within an account.

Asking a user to resolve an MFA challenge at login every time is a lot of unnecessary friction and a poor user experience. And today, more than ever, users are looking for a safe, secure, and seamless experience with online services.  They want to trust and feel safe with the business that they are doing business with. A more adaptive process that engages the user to participate in their security at the right time will be more accepted and tolerable by users, and thus improving your customer experience and revenue.

How do we balance between trust and risk while protecting against modern security threats like growing ATOs? We want to achieve trust assurance that is proportionate to the level of risk. We want to limit the interruption of user experience while at the same time balancing these modern attacks.  Implementing blanket MFA policies that do not take into the context could backfire. How can you segment the customer journey and map out appropriate remediations based on actions being performed by your users?

Let’s first look at what this could look like with a real-world application. In this video demonstration, Chris Concannon, a security solutions engineer at Castle, will show an elegant solution for how to prevent these modern credential stuffing attacks while still having a balance between trust, risk, and user experience. We’ll demonstrate two different attacks.

For the first attack demonstration, Chris shows an attack on a login form on a basic Web application.  As login events occur, they are sent through a Castle SDK where the Castle Identity Risk Engine then looks at events like login succeeded events for various users, and it's able to give intelligence back to the application about whether or not the events seem risky or not.

Castle maintains a memory of a user's behavior and profiles, knowing which devices they use and what kinds of user behavior are exhibited by that user throughout the entire experience with the application from pre login to post logout. By doing this, Castle is able to tell the application when something looks suspicious or malicious. Users are given risk scores based on things they do like traveling around the world, logging in from different devices, logging in at different times, different browsers, etc.

The attack simulation demonstrated uses a command +control application that launches Google Cloud functions from Google's data centers and cloud data centers. In this scenario, Puppeteer is used to access our sample Web application to fill in the credentials of random users and to try to log in using those credentials.

In this credential stuffing attack simulation, a total of 50 browsers are launched using three tabs for each browser. All 50 browsers attempt to log into the application. While in this example none of the credentials are valid, Castle sees the activity pouring into the application and in looking at the context sees a large amount of junk email addresses for the username.  This attack ran close to 3x the number of logins over the amount of actual users the application has. Not only were there a large amount of emails that did not match but it also saw a lot of different IP addresses belonging to Google Data Center IP ranges. So, this demonstrated a distributed attack orchestrated by a command +control application and utilizing Puppeteer.

But what happens if, during the attack, the attacker tries logging in with a known user’s credentials? When looking into that user’s profile, we see that while there was a valid set of credentials to access the account, but, Castle told the application to deny that user login. Castle recognized that this was a very suspicious login event and recognized that there was an attack happening. Castle detected an abusive device, signature and brute force network signals and told the application to deny that login. The attacker is denied any sort of feedback that tells them the single set of credentials for that user were valid. The attacker is left believing that the entire list was invalid, and they will be discouraged from returning with their list of stolen credentials. Over time, if they do not have success with any credential lists, the application is no longer a target of theirs.

With the attacker prevented from knowing that the user’s credentials could be exploited for an attack, Castle takes it a step further and helps both the security team and the end user by blocking the account in real-time and kicking off a fully automated account recovery with the end-user.

In the second demonstration, the attack is run through the Luminati proxy service in order to show the same behavior, with an added layer of complexity. In this attack, we see the location of all of the events coming through many different cities in the US. Traffic is routed through various locations with tons of different IP addresses. In this attack, Castle still gathers all the data about those failed login events yet we see a different set of IP addresses that are not Google Datacenter IP’s.

Castle sees the attack and even when the legitimate user credentials are used, the login was not allowed to proceed. When looking at context in the Castle dashboard, we see that the event was indeed a “$login.succeeded” event, meaning the application saw valid credentials. However, Castle told the application to block the login from proceeding, therefore preventing the incident from becoming a breach. Looking at the event in the user account activity, we saw the login came from a brute force network and contained an abusive device signature. Using Castle’s webhooks and API, an automated workflow will allow the user to easily recover their account without having to call in for customer support.

So, how do you implement the right remediation workflows to continue to protect your users and continue to provide them a good experience? Here are 7 things to consider:

1. Collaborate with your customer experience teams like your product, marketing, and engineering teams to map out what that customer journey looks like.
2. Determine user risk signals that are associated with a particular account action in your customer journey. For example, signals could be a user's device, past account activity, access origins like IP addresses and so on.
3. Determine what the minimal level of trust that needs to be established to complete that action. If a user has all of the same login, device, and buying signals but is logging in from a new location, it could just be they are on vacation. Do you want to risk blocking that transaction and having a bad user experience?
4. Map out the risk associated with these factors that would result in an overall risk score that would trust the user to complete the action.
5. Understand your key use cases throughout your customer journey – are you trying to prevent fake registration, carding, ATOs, bot detection, etc?  Do you have the tools to identify identity-related threats?
6. Measure the results. What are your customer retention rates, acquisition costs, password reset costs, dropout rates? Metrics will be different for each organization and have different weights.
7. Remember that addressing ATOs is a continuous process throughout a user’s entire experience with your application and not a one-time event.

Protecting users from identity related threats is a continuous process and security needs to be part of the overall customer experience.  We encourage you to frequently revisit the customer journey to see if you need to make adjustments based on risk tolerance. The task ahead is mapping out your account actions to the specific security response and determining what the risk signals are that make sense for your organization. Good security, when done right, can be a profit driver.

Visit our website to learn more about how Castle’s Identity Risk Engine can help you with ATOs and Credential Stuffing attacks.