Credential Stuffing - What is a Credential Stuffing Attack and How to Defend Against it

Jul 12, 2021

Credential stuffing is a type of attack in which hackers use automation and lists of compromised usernames and passwords to defeat authentication and authorization mechanisms, with the end goal of account takeover (ATO) and/or data exfiltration. Authentication and authorization mechanisms are almost always powered by APIs, putting credential stuffing and ATO high on the list of concerns for organizations and their API security strategy. The credential stuffing attack technique exploits the tendency of users to reuse their credentials across multiple services and applications. Credential stuffing can yield low rates of success for attackers, but the use of automation allows attackers to drive high volumes of login attempts originating from different IP addresses, decreasing the likelihood of most traditional security controls recognizing the attack as nefarious activity. Attackers will also throttle their credential stuffing attacks to avoid detection and therefore avoid triggering rate limits on API endpoints that an organization might set. Services with normally massive traffic flow may not recognize credential stuffing attack at all, because they can’t distinguish the activities of a single attacker within the mass of traffic.

Credential Stuffing versus Brute Force Attack – What’s the Difference?

Credential stuffing attacks are similar to brute force attacks in that the attacker is attempting to obtain working user credentials to achieve ATO and gain access to sensitive data or functionality. The difference is that brute force attacks consist of the attacker enumerating through alphanumeric sequences to find working username and password combinations that provide authenticated context. Brute force attacks often combine each username in a one (username)-to-many (password) attack. Attackers may also attempt to brute force usernames as well, depending on how much information they have at the start of their attack campaign. Brute force attacks are more successful when users choose simple or easy-to-guess passwords.

Credential stuffing, on the other hand, relies on lists of compromised username/password combinations, and the common bad habit of users implementing the same credentials across multiple services. The success of credential stuffing attacks increases when the username is an email address since this information is easily obtained or guessed by attackers. Both credential stuffing and brute force attacks can be mitigated by implementing policies that lock an account after multiple login attempts. Setting an aggressive account lockout policy will create a bad user experience, however. Organizations, looking to balance these demands, will sometimes implement a more lax policy, such as locking the account only after 10 bad attempts in an hour. Attackers can take advantage of these relaxed settings – in this instance, attackers could set their tooling to try nine attempts then back off and not resume the attack campaign until 60 minutes have passed.

Credential Stuffing Attacks are on the Rise

Credential stuffing attacks are not only a more efficient and effective way for attackers to gain unauthorized access than traditional brute force password attacks, they’re also becoming easier to perpetuate. A few years ago, if a hacker gained access to a trove of credential information, they often kept it for themselves or offered it up for sale on the dark web. But in 2019 the so-called Collections #1–5 list showed up in hacker forums and torrents, being freely distributed. These collections include a staggering 3.2 billion unique usernames and associated passwords. Scripting and automation tools have also become more plentiful. Organizations rely on automation for many legitimate business cases, but attackers often use much of the same automation tooling to carry out credential stuffing attacks.

How Do Credential Stuffing Attacks Work?

The following is a typical process an attacker uses when performing a credential stuffing attack:

1. Perform recon of a target and its APIs – attackers stealthily scan and collect information about their targets, often selecting their victims based on data or functionality that is of high value or brand recognition. Information gathering includes IP address ranges, registered domain names, hosting application servers and exposed API endpoints. Attackers will also reverse engineer the web and mobile application client code to better understand how to interact with back-end APIs.

2. Compile a dataset of pilfered credentials – an attacker pulls together large sets of credentials that were once known to be working and typically harvested from prior data breaches, credential stuffing campaigns, and ATO successes. These credentials become the inputs into automation tooling and serve as the authentication material for a target API endpoint.

3. Configure automation tool with throttling – an attacker sets up an automation tool of choice or creates scripts. The configuration depends on a number of factors including how unique the target API endpoints are, the level of integration an attacker needs for other attack tooling, or simply the attacker’s own preference. Attackers additionally configure the automation tooling to evade detection and lockout thresholds. Steps include mimicking legitimate user agent metadata, avoiding use of multi-threading, and attempting logins once per minute. Note that automation tooling – when configured properly – looks and behaves much like that of typical and sanctioned business activity.

4. Launch attack against the login API – once attackers have configured their automation tools with all the appropriate pre-requisites, they launch their attacks against the login mechanism. It may take some time to uncover a working credential for the login, depending on the age and validity of the dataset of pilfered credentials the attacker is using. Attackers will likely launch multiple instances of the automation tool from different network locations (such as in a cloud provider) and often geographically distributed to speed up the process and further evade detection.

5. Track login credential successes and failures – an attacker must track the successes and failures across all instances of the attack automation tooling. This correlation may be as basic as checking logs for success codes after the fact, but most attackers will configure or code these results into their automation tooling so as not to waste time attempting further logins. Once the attacker has obtained a working login, this outcome is technically the point of ATO. An attacker will then likely pivot in the attack campaign, obtain an authenticated session via the login API, and then continue to exfiltrate data, escalate privileges, or further abuse functionality.

Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.

‍

How to Defend Against Credential Stuffing

Credential stuffing can be thwarted when the right practices and tools are in place:

Implement Behavioral Analytics

Credential stuffing can be more easily and quickly detected if an organization is able to establish baselines of typical user behavior and traffic patterns. API security offerings like the Salt Security API Protection Platform can automatically create and maintain baselines of typical behavior and identify any activity that deviates from the baseline, including the abnormal movement of data and the attempted manipulation of tokens, user IDs, or API parameters.

Avoid Using Email Addresses as User IDs

Credential stuffing relies on users leveraging the same usernames or account IDs across services. The risk runs higher when the ID is an email address since it is easily obtained or guessed by attackers. Requiring unique usernames can mitigate some of the risk of credential stuffing attacks and potentially exposing users to ATO.

Use Multi-Factor Authentication (MFA)

Credential stuffing relies on automation scripts and tools that cannot easily provide additional factors of authentication, particularly mobile phone authenticator tokens or 2FA tokens sent through alternate channels such as email or SMS. Requiring users to authenticate with additional authentication factors helps mitigate against credential stuffing attacks. Note that attackers can and will also target MFA mechanisms, and organizations must also protect any MFA mechanisms from brute force attacks.

Additional industry guidance suggests the following less-effective defenses against credential stuffing. We mention them here to give the reader a full picture of protection options and to point out potential downsides of these practices.

Use CAPTCHA

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) can reduce the effectiveness of credential stuffing attacks by challenging users to prove that they are human with tasks that are easy for humans but more difficult for computers, such as identifying specific objects in a set of images or recognizing distorted letters. CAPTCHA is easily added to an app or site, but it is just as easily bypassed by hackers using headless browsers or CAPTCHA solving services. The negative interruptive user experience is not commensurate with the amount of security CAPTCHA delivers.

Deploy Device Fingerprinting and User Profiling

Device fingerprinting combines certain attributes of a device to identify it as unique, including operating system, type and version of web browser, language settings, and IP address. Additional user profiling techniques will track how individuals use the devices and the applications on that device, such as where they touch the screen or how fast they move a mouse cursor. When using device fingerprinting as a defense against credential stuffing, one assumes that a device recognized as having certain attributes on one day is the same device seen with those same attributes on another day. If the same combination of parameters logs in several times in sequence, it may point to a credential stuffing attack. The downsides of fingerprinting and profiling include that they require client-side code, which can be reverse engineered and bypassed, and these protections simply don’t work in machine-to-machine or direct API communications.

Implement IP Address Deny lists

Attackers may be working from a limited pool of IP addresses, so recognizing and blocking IPs that attempt to log into multiple accounts can provide some defense against credential stuffing. But recognizing a malicious IP address is not that simple. A hidden link analysis report from Recorded Future suggests that 92% of suspicious IPs are not blacklisted, often because rate limits can be difficult to operationalize across infrastructure. These lists are often not well maintained, and attackers will cycle through IP addresses. Cheap and plentiful cloud computing resources also worsens matters. Attackers will spin up new instances of machines or use serverless compute to perpetuate their credential stuffing attacks, raising the difficulty bar substantially for security teams trying to maintain deny lists.

Rate-Limit Non-Residential Traffic Sources

Attackers may originate attacks from other countries where your organization doesn’t typically do business. Countries such as China, North Korea, or Russia can rank high on the list of concerns for security teams since they are sometimes home to malicious threat actors. You may opt to implement more restrictive rate limits for the IP address ranges of those regions to help mitigate some of the risk of credential stuffing, but most attackers will likely shift to other less restricted IP address space by leveraging other data centers and cloud providers. If you are a global business, applying regional rate limits may also impact legitimate users and have negative impact to the business.

Block Headless Browsers

A headless browser is a web browser without a GUI. The label is also sometimes used to describe scripts or automation tools. Headless browsers can be a great tool for test automation and process automation, frequently used by development, QA, and business teams. They are not typically used for legitimate web browsing and may sometimes lack a proper JavaScript engine to execute client-side code. Blocking headless browsers can sometimes be a useful mitigation option depending on an organization’s use of automated IT processes, but don’t rely on it as a defense against credential stuffing. Determined attackers will circumvent such basic controls by using more advanced headless browser technology or tuning scripts to more closely mimic traditional browser behavior.

Stop Credential Stuffing Attacks in their Tracks

Stopping credential stuffing attacks without negatively impacting user experience or deploying client-side code controls that are able to be bypassed means you need to start with the ability to analyze as much data as possible to understand normal behavior, identify the outliers, and put together the pieces to form a bigger picture.

Credential stuffing attacks can “hide in plain sight,” evading existing security measures, especially with services that regularly get massive traffic flows. You need to baseline and analyze traffic to identify anomalies. Beyond that, you also need a solution that can differentiate between user mistakes or behavior that changes in response to a changed API and. malicious activity, such as an attacker probing an API and manipulating API logic.

Salt Security’s API Protection Platform correlates disparate data to analyze behaviors of users and machines as they interact with APIs. After collecting a copy of all an organization’s APIs and pulling it into its big data engine, the Salt platform then uses ML and AI to create a baseline of normal behavior so it can identify anomalies. With this context, Salt accurately distinguishes malicious attacker activity and stops attackers before they’re able to compromise accounts.

Alerts from the Salt Security API Protection Platform contain the crucial context that incident response teams need to understand and respond quickly and effectively to credential stuffing attacks. Our platform provides full timelines of attacker activity, so teams gain insight into what the attacker did and how the application responded. Teams have no need to correlate relevant attack information manually – the platform provides this correlation automatically.

The context that the Salt Security API Protection Platform provides is also essential to helping development teams eliminate vulnerabilities quickly and continuously improve API security posture. A form of feedback loop often promoted as part of DevOps practices, remediation insights within the Salt platform contain details on the location of a vulnerability and what normal activity looks like for that API. The insights also include recommendations on how developers can tackle misconfigurations, close security gaps, and otherwise improve security posture. And Salt delivers these insights in the platforms developer teams are already using, such as Jira and Slack.

Would you like to see how to defend against credential stuffing in your network? Request a personalized demo to see how Salt can help you defend against credential stuffing attacks and how to improve your API security posture.

Credential Stuffing - What is a Credential Stuffing Attack and How to Defend Against it

Credential Stuffing versus Brute Force Attack – What’s the Difference?

Credential Stuffing Attacks are on the Rise

How Do Credential Stuffing Attacks Work?

Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.

How to Defend Against Credential Stuffing

Stop Credential Stuffing Attacks in their Tracks

Tags

API Security is Not a Problem You Can Solve at the Edge

Beyond Traditional Security: Addressing the API Security Gap

API (In)security: The Hidden Risk of Black Friday

Credential Stuffing - What is a Credential Stuffing Attack and How to Defend Against it

Credential Stuffing versus Brute Force Attack – What’s the Difference?

Credential Stuffing Attacks are on the Rise

How Do Credential Stuffing Attacks Work?

Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.

How to Defend Against Credential Stuffing

Stop Credential Stuffing Attacks in their Tracks

Tags

Salt Security Blog

API Security is Not a Problem You Can Solve at the Edge

Beyond Traditional Security: Addressing the API Security Gap

API (In)security: The Hidden Risk of Black Friday

Download this guide for advice on evaluating key capabilities in API Security