How credential leaks become account takeovers

The gap between exposure and exploitation

Credentials do not expire the moment they leak. They sit in paste sites, dark web marketplaces, and private Telegram channels for weeks, months, sometimes years, being indexed, aggregated, and sold. The average time between a credential appearing in a dark web forum and its first use in an account takeover attempt is 17 hours for high-value targets. For low-priority accounts, it can stretch to days.

That window is not a grace period. It is the only time you have to act before the attacker does.

The organizations that contain credential exposure before it escalates share one characteristic: they know about the leak before the attacker uses it. The ones that discover it post-incident do not.

Where leaked credentials come from

Understanding the source changes how you respond. Not all credential leaks have the same risk profile, and treating them uniformly wastes response capacity on low-risk exposures while missing the ones that matter.

The main sources, in order of operational risk:

1. Infostealer malware. A device infected with a stealer (RedLine, Raccoon, LummaC2, and their successors) exfiltrates saved browser credentials, session cookies, and autofill data silently. The output is a log file sold in bulk on underground markets within hours of collection. These are the highest-risk leaks: credentials are current, come with session tokens that bypass MFA, and are often paired with device fingerprints that enable fraud without triggering login alerts.
2. Third-party breaches. When a SaaS vendor, supplier, or partner suffers a breach, your employees' credentials, registered with a work email and a reused password, are in the dataset. These are the credential leaks most organizations are slowest to detect because they require monitoring outside your own perimeter.
3. Credential stuffing datasets. Aggregations of multiple past breaches (COMB, RockYou2024, and similar) circulate continuously. Older credentials have higher overlap with password reuse than most organizations expect. A password from a 2019 breach is still valid for any account where it was never rotated.
4. Paste sites and public dumps. Opportunistic actors post credential batches publicly as proof-of-access or to build reputation on forums. These are often lower-quality (older, partial, or fabricated) but indexed by threat intelligence platforms and used in bulk stuffing campaigns.

The account takeover chain

An attacker with a fresh credential set does not log in manually. The process is automated, layered, and calibrated to avoid detection. Here is the sequence:

Stage 1: Validation

Before attempting anything, attackers validate credentials at scale using credential stuffing tools (Sentry MBA, STORM, OpenBullet with custom configs) against targets with weak rate limiting. They are looking for a hit rate above 0.5%. Most large leaked datasets deliver between 1% and 3% valid credentials against common consumer services.

For corporate accounts, validation is more careful. Tools that mimic legitimate browser behavior, rotate residential proxies, and space requests to avoid SIEM triggers are the norm in targeted campaigns.

Stage 2: Triage

Valid credentials are sorted by target value. Accounts with access to financial systems, admin panels, email (which can be used to reset other accounts), or cloud infrastructure are extracted from the batch immediately. Everything else is sold or used in bulk fraud.

An email account is worth more than its contents. It is the recovery mechanism for every other account tied to that address: banking, HR systems, and identity providers.

Stage 3: MFA bypass or session hijack

Multi-factor authentication stops credential stuffing when it is implemented correctly. It does not stop infostealer-sourced credentials, because infostealers exfiltrate session cookies alongside passwords. A valid session cookie lets an attacker authenticate as the user without triggering an MFA prompt. The session was already authenticated.

For accounts without session cookie access, attackers route through MFA bypass techniques: real-time phishing proxies (Evilginx, Modlishka) that intercept the MFA token mid-session, SIM swapping for SMS-based MFA, or social engineering IT helpdesks for account recovery. None of these are novel. All of them are active.

MFA stops password reuse. It does not stop session hijacking. If your employees run infostealer-susceptible devices, MFA provides less protection than most security teams assume.

Stage 4: Persistence and lateral movement

Once inside, an attacker's first move is persistence: adding a recovery email, creating API tokens, or enrolling a new MFA device. Detection at this stage is difficult because the actions look like legitimate account management.

From a compromised email account, the path to lateral movement is short. Password reset requests, forwarding rules that silently copy outbound mail, and OAuth app approvals that grant persistent third-party access all happen inside the email interface, leaving minimal logs in systems that are not specifically monitoring for them.

Where the chain breaks

There are four intervention points. Each one is cheaper than the one after it.

Break it at detection

The earliest intervention is monitoring for the credential leak before it reaches the validation stage. Paste site surveillance, dark web forum monitoring, and infostealer log feeds provide exposure alerts hours to days before credentials are used.

What this requires: coverage of the sources where leaks appear first, not just the breach databases that index them months later. Detection in breach notification services is a lagging indicator. Detection in the primary leak channels is the only one that gives you lead time.

Break it at validation

Credential stuffing tools are detectable. Distributed login attempts from residential proxies at irregular intervals still produce signals: unusual geolocation sequences, device fingerprint mismatches, failed attempt patterns on accounts that do not exist. A well-tuned authentication monitoring system catches the validation sweep before a successful login occurs.

Most organizations do not have this monitoring in place. They see failed login attempts but do not correlate them across accounts to identify stuffing campaigns.

Break it at authentication

Phishing-resistant MFA (FIDO2 hardware keys, passkeys) stops real-time proxy attacks that circumvent TOTP-based MFA. It does not stop infostealer-sourced session cookies. For the infostealer vector, session lifetime limits and device binding are the controls, not MFA method.

The practical implication: if your MFA is SMS or TOTP, you are protected against credential stuffing, not against the higher-sophistication attacks that follow a targeted infostealer infection.

Break it at post-login behavior

If the attacker clears stages 1 through 3, detection shifts to behavioral anomaly: login from an unrecognized device or location, immediate account setting changes, bulk mail forwarding rule creation, API token generation outside business hours. These signals exist in your logs. The question is whether anyone is watching for them and whether the alert threshold is calibrated to catch real attacks without producing noise that gets ignored.

What a credential exposure response actually looks like

When ClairSec surfaces a credential leak (a corporate email and password combination found in a paste site dump or infostealer log), the response is not "tell the user to change their password." The response is a structured triage:

1. Classify the source. Infostealer log vs. third-party breach vs. paste dump. The source determines the risk level and the additional exposures to investigate (session cookies, co-located credentials, device compromise indicators).
2. Check for active use. Cross-reference the credential against authentication logs for recent successful logins from anomalous sources. If the credential was already used, the incident is active, not potential.
3. Scope the exposure. How many accounts are affected? Are any privileged? What services does the email address recover? The blast radius is often larger than a single credential suggests.
4. Force credential rotation with context. A password reset without context produces a user who resets to a variation of the leaked password. The communication needs to explain what was leaked and why rotation alone is insufficient if session hijacking is a risk.
5. Harden the authentication chain. If the source was an infostealer, the device is compromised. Credential rotation on a compromised device re-leaks the new credential within hours. The device needs to be assessed before the rotation is considered complete.

The monitoring gap most organizations have

Internal security teams monitor their own perimeter well. They monitor third-party breach databases acceptably. They almost never monitor infostealer log markets, closed Telegram channels, or the private forums where fresh credential dumps circulate before they reach aggregated databases.

That gap is where credential exposure goes undetected for the longest. A credential that surfaces in a public breach notification service is already in the hands of thousands of actors who found it earlier in its distribution chain.

The 17-hour average exploitation window cited earlier assumes the credential reaches a motivated attacker quickly. For credentials that surface only in aggregated datasets, the window is longer, but so is the exposure duration. They are not safer credentials. They are credentials that were missed for longer.

Monitoring breach notification services tells you what happened. Monitoring the primary leak channels tells you what is about to happen.

What ClairSec covers

Dark web monitoring at ClairSec covers paste sites, Tor-accessible forums, closed marketplaces, and infostealer log aggregators, continuously, not on a periodic scan schedule. When a credential associated with your domain appears, you receive a structured alert within hours that includes the source, the risk classification, and the recommended response actions.

The goal is not a data feed. It is lead time: the gap between when a credential leaks and when an attacker uses it, used to contain the exposure rather than manage the incident.