Leaked Credentials: How to Check Exposure and Respond

Leaked credentials — usernames, passwords, API keys and session tokens exposed outside your control — are one of the most common ways attackers get into organisations, because logging in is easier than breaking in. They surface in third-party breaches, infostealer logs, paste sites and public code repositories. Here's where they come from, how to find out whether you're exposed, and what to actually do about it.

Where credentials leak from

Third-party breaches

Staff sign up to external services with their work email, reuse a password, and that service later gets breached. The email-and-password combinations end up in dumps that circulate for years and feed credential stuffing attacks — automated attempts to replay those combinations against your VPN, email and SaaS logins.

Infostealer malware

Infostealers infect a device — often a personal one — and harvest everything at once: saved browser passwords, autofill data, session cookies and tokens. The resulting stealer logs are sold and traded in bulk. They're particularly dangerous because the data is fresh, it includes live session cookies that can bypass login entirely, and it captures corporate credentials from personal devices your security tooling has never seen.

Paste sites and forums

Combo lists, samples from larger dumps and targeted leaks get posted to paste sites, forums and messaging channels. Much of it is recycled, but recycled credentials still work when nobody has rotated them.

Public code repositories

Developers commit API keys, database connection strings and .env files to repositories that are — or later become — public. Deleting the file doesn't help: git history preserves it. Secrets also leak through CI logs, container images and package registries.

How to check your exposure

• Breach notification services — register your domains with a reputable breach notification platform to get alerted when your addresses appear in known breaches.
• Stealer log monitoring — specialist threat intelligence services track infostealer output; this is where the freshest and most dangerous exposure shows up.
• Secret scanning — scan your organisation's repositories, including full git history, for hardcoded credentials. Enable your code platform's built-in secret scanning and add pre-commit checks.
• An OSINT assessment — attackers hunt your credentials as part of reconnaissance, so we do the same on OSINT and reconnaissance engagements. Our post on what OSINT is covers the wider picture.

One caution: be wary of services or approaches that involve buying data from criminals directly. Reputable monitoring gives you the same signal without funding the trade.

How to respond when credentials leak

1. Reset first, investigate second. Invalidate the password and all active sessions and tokens. Stealer logs contain session cookies, so a password reset alone can leave the attacker logged in.
2. Check for use. Review authentication logs for the affected accounts: unfamiliar locations, impossible travel, new mailbox rules, bursts of MFA prompts.
3. Scope it. Was the same password used elsewhere? Is it a shared or service account? Assume reuse until shown otherwise.
4. For API keys and secrets: revoke and rotate immediately, audit what the key accessed since exposure, and purge it from git history rather than just deleting the file.
5. Find the source where you can. A stealer log means an infected device that needs remediating — possibly a personal one. A third-party breach tells you which service to distrust.
6. Feed it back. Every leak is evidence about where your controls are thin: password reuse, missing MFA, secrets in code.

Reducing the odds

• Enforce MFA everywhere, preferring phishing-resistant methods
• Roll out a password manager so unique passwords are the path of least resistance
• Block known-breached passwords at the point staff set them
• Use proper secrets management and pre-commit secret scanning in your development workflow
• Set clear policy on accessing corporate accounts from personal devices
• Monitor your domains continuously rather than waiting for an incident

FAQ

The leaked password is years old — does it still matter?

Somewhat, yes. Old dumps feed credential stuffing lists indefinitely, and old passwords reveal patterns — a person who used Winter2019! has a guessable current password. Reset anything plausibly still in use and check for reuse across accounts.

We have MFA — are leaked credentials still a risk?

MFA blocks the straightforward replay, but not stolen session cookies from stealer logs, MFA fatigue attacks, or phishing kits that proxy the MFA step in real time. Treat leaked credentials as an incident to respond to either way, not a non-event.

Should we buy our own leaked data to see what's out there?

We don't recommend dealing with sellers directly — it funds the market and creates legal exposure. Established breach notification and threat intelligence services surface the same information through legitimate channels.

Want to know whose credentials from your organisation are already circulating? We check breach data, stealer logs and public code as part of our OSINT engagements and external network penetration tests, with a fixed quote within one business day of a free scoping call — get in touch.