Many of us are fond of collecting things, but not everyone is excited about Collections #1-5. In 2019, these Collections, composed of ca. 932 GB of data containing billions of email addresses and their passwords, made their way around the Internet. These collections weren't breaches but compilations of emails and passwords that had been gathered. Even after repeat entries were whittled down, the collection still contained billions of distinct address and password combinations.
While it's impossible to tell exactly where they all came from, some of the larger known data sets in these enormous files came from the Dropbox (2016), LinkedIn (2012), Yahoo! (2013/2014), and Adobe (2013) breaches.
Why should we pay attention to these and other breaches, especially when the passwords are hashed? Can’t one just reset the password and be done with it? Resetting passwords is not the issue. The problem is when the same password is associated with more than one account. Password reuse makes credential stuffing different from brute force – the criminal has a set of already-breached credentials and doesn’t have to guess at the password. Using rainbow or hash tables, criminals can determine the hash of the password. Attackers also know that many people reuse their passwords. The danger is not just accessing someone’s account; it's being able to access other valuable personal accounts that use the same credentials.
5 Stages of an Attack
Michael Isbitski with Salt Security presents a great overview of credential stuffing including its stages. Here’s a summary of my own version of the five stages.
In this stage, the criminals gather credentials. These might have been gained from breaches they conducted themselves, from collections bought online, or just downloaded from one or more sets of publicly available repositories. Additional items gathered during this stage are APIs, URLs, domain names, and other Internet-facing resources (e.g., web servers). An important aspect of security and IT is knowing that the tools that make our job easier can also make life easier for criminals. Maltego, Shodan, Kali, et al. are used by all.
The attackers collate the inputs and prepare the tools for their invasion. “Automate all the things” is a common phrase not lost on the attackers. Bad guys calculate budgets and ROI, too. Whether scripting their own tools or using commercial tools, the utilities automate account and vulnerability discovery, helping the attackers search for sites, domains, and any other endpoints that could be vulnerable.
Tool selection and configuration could include the ability to evade various defenses (e.g., CAPTCHA), hide or spoof the origin address, or otherwise craft the method of attack based on the target’s defenses (e.g., control the timing based on rate limiting). This is the stage when the attacker designs something similar to a botnet – valid proxy services, multiple locations of the tool, and bots that will spread the attack load. This achieves two goals. First, it fools defenses that are monitoring for lots of traffic originating from a single IP or a narrow range of addresses. Second, it accelerates the attack.
Interwoven with the previous stage is the actual creation of scripts, setting up the instrumentation with the credential input, configuring the tools with the actual APIs or other targets, and setting the proper timing of each attack and attacking device. Proper architecture here can also include outsourcing the task as microwork where numerous people enact smaller tasks as part of a larger project. Some common tools are Sentry MBA, OpenBullet (works for CAPTCHA bypass), SNIPR, and even widely used cURL and Wget.
Attackers are looking for all successful login requests. Since the tools are automated, it’s sort of a scenario of pushing the “Go” button, going to sleep, and seeing the next day what was discovered while they slept. The results are assembled into a list of valid credentials. While I’ve entitled this the Attacking stage, it’s only the initial attack in an iterative project. The main purpose of the attack is the next stage.
5. Achievement (or “All Your Accounts Belong To Us”)
The objective is not to make a list to attack things; the goal is takeover. Oftentimes, this is ATO (Account Takeover, a type of identity fraud), but it can include further infiltrating a network, stealing intellectual property, deploying a phishing campaign from the compromised organization, or selling the known-good credentials. Throughout Stage 4, the criminals aggregate the working credentials and launch a branched attack using working userid:password combinations, perhaps while the current attack is still going on. The multi-pronged attacks continue until the goal is achieved.
Protecting Against Credential Stuffing and ATO
What can be done to protect these attacks? Salt Security’s article has excellent tips on corporate-level and individual defenses that present a solid multi-layered approach.
Here are some additional ways that individuals can play their part in protecting their accounts and identities:
1. Use 2FA wherever possible (worth repeating)
2. Use a different password for each account
3. Use a password manager
3a. Many password managers provide a function to notify you if you have reused passwords in your password manager database.
4. Use a strong password for each account. This will make it harder for compromised passwords to be reverse hashed.
4a. Whether one uses the traditional models of passphrase and/or password with upper/lower/#/etc. or the more recent NIST recommendations (long password, reduced complexity, check against allowlist, etc.), a strong password will go a long way toward thwarting reverse hashing or cracking.
While there’s nothing to be done about taking back all the past breaches nor to reclaim the stolen credentials, we have many tools and strategies available to protect ourselves – both as individuals and organizations – from credential stuffing and other types of criminal cyberattacks.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.