Breached Credentials and Why They Still Matter

What it is

A breached credential is any username and password pair that leaked from a service that got compromised. This includes:

• Plaintext passwords stored without hashing (still surprisingly common in older breaches)
• Cracked password hashes, where the original passwords were recovered from leaked hash databases
• Salted hashes that have not yet been cracked, which still represent risk because cracking continues
• Email and password combinations stripped from larger breaches and sold as combolists

The historical scale is hard to overstate. The 2012 LinkedIn breach exposed 167 million accounts. Yahoo's 2013 breach exposed all three billion of its accounts. Adobe lost 153 million in 2013. Dropbox, Tumblr, MySpace, Twitter, and dozens of others contributed hundreds of millions more. The Collection #1 aggregation that surfaced in 2019 contained 773 million unique email and password combinations across hundreds of source breaches. Every year since has added to the pile.

By 2026, the publicly accessible breach data exceeds 30 billion records. Most active email addresses appear in at least one breach. Many appear in twenty or more.

Why it matters

If breached credentials were just historical curiosities, none of this would be a problem. They are not.

Password reuse is the reason. Surveys consistently show 60 to 80 percent of users reuse passwords across multiple sites. The 2016 password leaked from a forum signup is often still the password for that user's email, banking, and corporate SSO. Attackers know this and act on it.

The mechanics that make old data dangerous:

Credential stuffing. Attackers take a leaked email and password pair from any breach and try it against every major service. Tools like SentryMBA, OpenBullet, and Storm automate this at industrial scale, hitting tens of millions of login attempts per day. Even a one-percent success rate produces hundreds of thousands of compromised accounts.

Targeted credential reuse. A specific employee at a specific company gets singled out. The attacker searches every breach database for that person's email, finds three or four leaked passwords, and tries each one against corporate systems. Often one works, especially if the user has not rotated.

Personal-to-corporate spillover. A leaked password from someone's personal Yahoo account shows up as the same password used for their work VPN. The corporate password policy looked fine. The personal password reuse defeated it.

MFA fatigue and bypass. Even with MFA enabled, a valid password is the first half of the attack. Push fatigue, SIM swapping, OTP phishing, and adversary-in-the-middle kits all turn a known password into a successful login when the second factor is weak.

The financial impact shows up in real incidents. The 2022 Uber breach started with a contractor's leaked credential combined with MFA fatigue. The 2024 Snowflake-related breaches affecting Ticketmaster, AT&T, and dozens of others traced back to credentials in stealer logs and old breach data, used against Snowflake accounts that had no MFA enforcement. The Colonial Pipeline ransomware attack in 2021 began with a single leaked VPN password.

How attackers exploit it

The credential abuse pipeline is well-developed and largely automated.

1. Aggregation. Attackers maintain massive databases of breach data, indexed for fast lookup by email, domain, or password pattern. The Collection #1 through #5 aggregations, COMB ("Compilation of Many Breaches"), and various private collections form the core.
2. Enrichment. Email addresses get matched with names, company affiliations, social media profiles, and physical addresses. This turns a credential into a targeted attack input.
3. Stuffing. Automated tools attempt logins against high-value targets: banks, email providers, cloud services, e-commerce platforms, corporate SSO portals. Successful logins get flagged for further exploitation.
4. Triage. A successful login on a Gmail account gets used differently from a successful login on a corporate Office 365 account. Attackers route findings to specialists who maximise value from each access type.
5. Monetisation. Account drains, fraud, BEC, ransomware deployment, or simple resale of validated credentials at higher prices than unvalidated ones.

The tools are commodity. The infrastructure (residential proxies, CAPTCHA solvers, validated combolists) is sold openly on Telegram and underground forums. Running a credential stuffing campaign is genuinely cheaper than buying ads.

How to detect exposure

Effective detection covers a few angles:

• Domain monitoring. Continuously check breach databases for any address ending in your corporate domain. New appearances should generate alerts.
• Executive and high-value account monitoring. Personal email addresses of executives, finance staff, and IT admins matter as much as corporate ones, because reuse spans both worlds.
• Customer monitoring (where applicable). If you operate a consumer platform, knowing when your customers' addresses appear in fresh breaches helps you proactively force resets.
• Credential validity checking. Not every leaked credential is still active. Hashing the leaked password and comparing it (carefully, without ever storing plaintext) against your authentication system tells you which leaks represent real exposure today.
• Velocity monitoring. Sudden spikes in login attempts from new IP ranges, unusual user agents, or impossible travel patterns are the operational signal of a stuffing campaign in progress.

The trick is correlating the threat intelligence (this credential is leaked) with the operational signal (and someone is trying to use it right now). One without the other is half a picture.

How to remediate

When you confirm a credential exposure that matters:

1. Force a password reset for the affected account. Do not rely on user discretion.
2. Invalidate active sessions. A reset that does not also kill existing sessions leaves an attacker logged in.
3. Check for prior abuse. Was the credential used by anyone before you noticed? Authentication logs, IP history, and unusual activity patterns reveal whether the account was already compromised.
4. Block the password from being reused. Add the leaked password to a deny list so the user cannot just re-set the same one.
5. Strengthen MFA. If the account had weak or no MFA, this is the moment to require phishing-resistant factors.
6. Communicate appropriately. Internal users need clear guidance. Customers may need notification depending on data exposure and jurisdiction.

For credentials that surface in stealer logs (a different category, covered in its own article), the response is more aggressive: assume the user's whole device is compromised, not just one password.

Best practices

• Continuous breach monitoring across your domain. A point-in-time check from a year ago is worthless if the data leaked yesterday.
• Block known-breached passwords at the password-set step. Have I Been Pwned offers a free API for this. So do various commercial services. A user trying to set "Welcome2024!" should be told it is in a breach database and rejected.
• Move toward passwordless or phishing-resistant MFA. Passkeys, FIDO2 security keys, and device-bound credentials remove the leaked-password problem entirely for protected accounts.
• Disable password reuse explicitly. Some directories enforce reuse only against the last few passwords. Aim for permanent rejection of any password that has appeared in a breach.
• Audit MFA coverage relentlessly. A single SaaS application without MFA can become the entry point that defeats every other control. The Snowflake incidents made this point in expensive detail.
• Educate on personal hygiene. A password manager that generates unique passwords across every site is the single most valuable habit you can build in your workforce. Subsidise one if you can.
• Plan for the next big breach. Treat large credential dumps as inevitable. Run tabletop exercises that assume a major SaaS provider just disclosed a 100-million-record leak. Who acts? What do they do first?

Why old data still matters

A common dismissal is "that breach is from 2016, who cares?" The honest answer is: a lot of attackers care, because a lot of users never changed those passwords.

A 2024 academic study traced credential reuse across breaches from 2010 onwards and found that more than 30 percent of users still had at least one of their old credentials valid on a current major service. The pattern is consistent across years.

This is why security advice that says "monitor for credentials leaked in the last 12 months" misses the point. The right framing is: any credential that ever leaked, ever, is potentially still in use somewhere. The defender's job is to find the ones that actually grant access today, before someone else does.