Credential stuffing: The most common attack against SaaS identities

Introduction

When it comes to protecting your data and third-party risk management, we often hear about supply chain attacks, which are all those attacks that target a trusted supplier used by many organizations. 

We hear about these attacks in the press because supply chain attacks have such a wide blast radius. They might start with a platform that many organizations use for business (Salesforce, for example). If that SaaS platform is compromised, every company’s data is compromised, including your own. 

You have some control over this risk, but there are limitations

You can’t prevent supply chain attacks against your sub-processors or vendors, instead you’re stuck simply auditing the third parties you work with in order to verify they can be trusted enough that you’re comfortable using them and giving them access to your data and systems. 

Not the best, but great…this is the reality of doing security in the cloud. The good news is that supply chain attacks are pretty rare (at least today). What you do have control over (and in fact are responsible for) is the security of your organization’s identities in cloud applications. By doing this well you can prevent the most common attack against online applications.

What is credential stuffing?

Credential stuffing attacks occur when attackers use tools that automate the process of taking a list of breached passwords / stolen credentials (from public password dumps) and retargeting those compromised credentials against different apps and user accounts. 

If you’re familiar with password spraying, credential stuffing is the more effective version. With credential stuffing, the attacker already has a list of stolen credentials and identities to target instead of having to resort to blindly spraying guessed usernames and passwords against multiple sites and user accounts and praying for the attack to hit a target and gain unauthorized access or attempt account takeover.

How credential stuffing attacks work

In the example for acme.com in the graphic above, we see how this credential stuffing attack plays out to get access to acme.com’s Mailchimp account because the user re-used their Mailchimp password on another (previously breached) app. At this point, attackers are able to start sending scam emails to acme.com’s customers from their domain, it looks completely legit because it is. 

Prevalence of credential stuffing attacks

Microsoft’s Director of Identity Standards, Pamela Dingle said in a recent article: 

“...as of October 2022, Microsoft blocks 1,287 password attacks every second across our platform…aka credential stuffing: Passwords are hard to remember, so passengers reuse them. Once attackers crack a password on a low-security site, they replay the same password on your high-security login page.” Dingle cited Microsoft Azure AD authentication log data for her stat.

Auth0 reported that credential stuffing accounts for 34% of overall traffic/authentication events on their platform. 

Credential stuffing attacks are rarely reported

These attacks are incredibly common, but it’s difficult to detect credential stuffing attacks. If you ask anyone working in incident response, they’ll confirm that credential stuffing attacks are often the entry point for attack. 

However, these credential stuffing attacks are often not reported as such because no organization who’s been victimized and experienced a data breach wants to admit the attack was as “basic” as a credential stuffing attack. Instead, they’d prefer to say they were a victim of an advanced nation-state level threat actor. 

The attacks that actually have a big impact on business are often the ones that target the low-hanging fruit as a starting point. And if you can automate those attacks, even better from the attacker’s point of view.

So, credential stuffing attacks are effective and incredibly common, but why is it more relevant now than ever?

Employees creating identities means more opportunities for attackers

There’s been a massive shift in how organizations’ attack surfaces are growing and adapting, and that’s because employees are signing up for software to get their work done, and creating new identities as they go.

Don’t think it’s happening in your company? Just because you don’t see it, doesn’t mean it isn’t happening and you can have the most stringent policies possible, but employees will often find a way to work around them just to get access to the tools that make their jobs easier.

The increase in employee-adopted apps has led to employees creating more accounts and identities, on more apps and without the guiding hand of security to make sure strong identity and access controls are in place. 

Opportunistic attackers now have a huge, unmonitored attack surface to target using low effort/cost techniques that generate reliable results for them 

Won’t SSO solve this? 

It helps, but it’s not available for most apps.

Many security teams are leaning on single sign-on (SSO) to address this issue. They’ll require that apps used in their company use SSO, specifically SAML (Security Assertion Markup Language) before they can be approved or used. This works really well for the apps that provide this functionality and it’s the gold standard for authentication. 

With SAML SSO, there’s just one account, just one password, and you can centrally deprovision accounts when employees leave the organization. You’re probably already paying for a SAML IdP (Identity Provider) like Google Directory or Azure AD. Many others are using tools like Okta.

SSO limitations

There are a couple blockers to using SSO to solve all your identities and SaaS sprawl problems though:

• Employees can’t integrate their apps with SSO themselves

  • SSO isn’t like multi factor authentication (MFA), employees can’t just turn it on. 

  • Employees aren’t incentivized to get IT approval and work with them on getting their work apps integrated with SSO

• SAML SSO won’t help you get visibility into which apps employees are using

  • SSO is not going to help you discover which apps employees are using - and that haven’t been integrated with SAML. 

  • But, once you discover them and determine they support SAML, you should absolutely integrate them with your solution (if it makes sense to pay for the top-end license fees). 

• SSO isn’t available for most of the apps employees are using

  • When we reviewed 500 of the most popular apps that Push supports, we found that: 

New apps less likely to support SAML SSO than enterprise apps

We also noticed that the more modern, newer apps were less likely to offer SAML support than the larger, more established business apps. So if your strategy is to block access to any app that doesn’t offer SSO integrations, you’re going to have to block the majority of self-adopted apps your employees are using. This means employees will soon start trying to hide these newer apps from your security team.

Prevent credential stuffing attacks

While most of us agree that going SAML and/or passwordless is the goal, we will still need to find out about these identities being created so we can get them protected behind modern authentication mechanisms. 

In the meantime, it’s not even going to be practical to do that as these methods lack broad support, whether you can discover them or not. So, we’re going to need a solution that covers all the not-(or not yet-) SSO identities as well. 

This isn’t the end of the world, since using strong, unique passwords, coupled with multi factor authentication (MFA), are very effective identity and access controls that ensure only legitimate users gain access to an identity.

Implement sensible controls to prevent credential stuffing attacks

To stop these  attacks (and a whole host of other attacks like brute force attacks to boot) you will need to implement the following controls on all accounts (not just the ones in your IdP or managed identity platform):

You need to know not just what apps employees are using, but also how they’re accessing them

It’s useful to note from the requirements that you must have visibility of cloud identities being created, the protocols they use and which app or IdP they exist on - not just which employee is accessing a SaaS website.

There’s only one place where we can get data about who is using which SaaS apps, as well as the ability to inspect passwords and check MFA status for each user…

…The employee’s browsers.

Benefits of using the browser as a shadow identity and shadow IT discovery method

This is the reason we have chosen to build our solution using a browser extension. It allows us to:

• Directly observe each identity’s authentication mechanism (SAML, OICD, or local password),

• Enforce strong user credentials. When passwords are used, assess their strength and whether they are being shared or reused across multiple accounts, and 

• Check if each password has already shown up in breached credential dumps, and

• Allow security teams to fix any accounts that don’t meet their policies or expectations.

Conclusion

We’ve written in much more detail about why discovering employee identities and SaaS use through the browser makes the most sense in this very biased (but reasonable!) blog post. Give it a read and have a think about it. Hell, come tell us why we’re wrong on LinkedIn, we’d love to discuss the pros and cons of our approach in more detail.

Even if you choose not to try Push (we have a forever free tier), we hope this guide helps you get a handle on shadow identities so you can prevent credential stuffing attacks against the SaaS apps employees are using.