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:
- 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.
- 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.
- 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.
- 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.
- 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.