How Attackers Use Stolen Credentials: The Complete Account Takeover Lifecycle

From credential dump purchase to account takeover: the complete technical anatomy of infostealers, combo lists, and credential stuffing tools.

A threat actor opens a tab to a dark web marketplace. They search for combolists filtered by a specific corporate email domain. They find a 40,000-line file of verified email-and-password pairs, scraped from five different breach databases and cross-referenced against a recent infostealer log batch. Price: $85. They purchase it with cryptocurrency, download it, and load it into OpenBullet 2.

They configure a config file targeting the corporate SSO portal. They route their traffic through a residential proxy pool of 3 million IPs sourced from a botnet of compromised home routers. They set the thread count to 50 and the delay to 2-8 seconds, randomized. They press start. The tool runs overnight. By morning, it has tested 31,000 credential pairs against the login endpoint. 214 have produced successful logins. Of those, 38 have MFA that was bypassed via session cookie replay from the infostealer component of the original log. The attacker now has 38 confirmed active corporate accounts.

This is not a sophisticated attack. It does not require vulnerability research, zero-day exploitation, or advanced malware development. It requires an $85 purchase, a freely available open-source tool, and a $30/month residential proxy subscription. The entire setup takes less than an hour. The attack runs unattended.

This blog is the complete technical anatomy of that attack: where credentials come from; how combolists are assembled, filtered, and priced; how credential stuffing tools work at the technical level; how attackers evade detection; what happens after successful validation; and what detection signals each phase creates.

Stage 1: Where Stolen Credentials Come From

The credential supply that feeds account takeover campaigns originates from four distinct sources. Each source produces different credential types with different characteristics, different freshness levels, and different exploitation patterns. Understanding the source determines the appropriate detection and response strategy.

Data Breaches: The Legacy Supply When a service is breached and its user database is exfiltrated, that database eventually reaches dark web markets. Major historical breaches (LinkedIn 2012, Adobe 2013, Collection 1-5 aggregation) contributed billions of records to the available credential pool. These are typically email-and-hashed-password pairs. Attackers crack the hashes offline using GPU-accelerated tools (Hashcat, John the Ripper) or purchase pre-cracked pairs, then test the resulting plaintext credentials against other services.

Infostealer Logs: The Fresh Supply As covered in our infostealer analysis, malware deployed on endpoint devices extracts browser-saved credentials as plaintext, along with active session cookies and tokens. Infostealer logs are the highest-quality credential source because they are already in plaintext (no cracking required), they include the exact URLs where the credential was used (so the attacker knows exactly which service to target), and they frequently include valid session cookies that bypass authentication entirely. Infostealer-derived credentials are the fastest path from credential to account access.

Phishing and Adversary-in-the-Middle Credential harvesting phishing campaigns and AiTM (Adversary-in-the-Middle) proxy attacks produce real-time credential collection: credentials are captured at the moment of entry, meaning they are guaranteed valid and have not yet been changed. AiTM attacks additionally capture the post-authentication session token, which remains valid even if the victim immediately changes their password after noticing suspicious activity. Phishing-derived credentials are typically sold within hours of collection.

Credential Guessing: The Manufactured Supply For specific high-value targets, attackers generate credential candidates algorithmically: common passwords, password patterns derived from known personal information, and corporate password convention patterns (CompanyName+Year+Symbol). These are not stolen credentials but generated candidates. They are deployed in password spraying campaigns, which test one password against many accounts rather than many passwords against one account. The goal is to identify accounts using predictable passwords without triggering per-account lockout thresholds.

Stage 2: How Combolists Are Built, Filtered, and Priced

A combolist (or combo list) is a structured file of username-and-password pairs assembled from one or more credential sources. The format is simple: one credential pair per line, separated by a colon or other delimiter. The sophistication is in the assembly, deduplication, filtering, and validation process.

The Combolist Format

# Typical combolist format (email:password pairs, one per line)

user@company.com:Password123!

john.smith@enterprise.org:Summer2024!

admin@targetdomain.com:Welcome1

… [40,000 lines total]

How Combolists Are Assembled

Assembling a high-quality combolist requires several processing steps that specialized operators perform as a commercial service. The raw material is breach databases, which may be in various formats: SQL dumps, CSV exports, JSON structures, or binary databases. Operators parse these into a unified format, deduplicate entries (removing duplicate email-password pairs that appear in multiple source databases), and optionally filter by domain, country, or data quality indicators.

The critical quality indicator for credential stuffing is whether the password is plaintext or hashed. Hashed passwords require an additional cracking step; plaintext passwords are immediately deployable. Infostealer-derived credentials are always plaintext. Breach database credentials are often hashed with varying algorithms: MD5 (fast to crack), bcrypt (slow to crack), SHA-1 (fast), Argon2 (very slow). The cracking difficulty is a primary pricing factor.

Filtering and Premium Pricing

Raw combolists sell for very low prices per record because they include low-quality entries: outdated credentials, duplicate entries, and credentials from low-value services. Filtered combolists command significant price premiums because the filtering work has already been done:

Stage 3: The Technical Anatomy of Credential Stuffing Tools

Credential stuffing at scale requires tooling that automates the login attempt process, manages proxy rotation, parses authentication responses, handles multi-step login flows, and stores results. The open-source ecosystem around credential stuffing tools is mature, well-documented, and freely available.

OpenBullet 2: The Industry Standard

OpenBullet 2 is the most widely deployed credential stuffing framework. It is open-source, actively maintained, and supports a rich configuration ecosystem. The tool uses a config file format (.opk) that defines exactly how to interact with a target login endpoint: the HTTP requests to send, how to parse the response, what constitutes a successful login versus a failed one, and what data to extract and log from successful attempts.

The config file handles the complete HTTP interaction with the target: following redirects, maintaining cookie sessions across requests, handling JavaScript challenges via headless browser integration, and parsing JSON or HTML responses to determine outcome. Advanced configs handle multi-step authentication flows, CAPTCHA solving via third-party solving services, and MFA prompts.

Other Tools in the Ecosystem

Stage 4: How Attackers Evade Detection During Credential Stuffing

The primary detection mechanisms deployed against credential stuffing campaigns are IP-based rate limiting, device fingerprinting, behavioral analytics, and CAPTCHA challenges. Mature credential stuffing operations have developed systematic countermeasures against each of these.

Residential Proxy Networks: Defeating IP-Based Detection

The most impactful evasion technique is residential proxy routing. A residential proxy routes attacker traffic through the IP addresses of legitimate home users, whose devices have been compromised and enrolled in a commercial proxy botnet. From the target’s perspective, login attempts appear to arrive from diverse residential IP addresses in the target country’s major cities, indistinguishable from legitimate user traffic.

Commercial residential proxy services provide access to millions of residential IPs through subscription models starting at $30-$50 per month for several gigabytes of traffic. The service handles IP rotation automatically, ensuring no single IP address makes enough attempts to trigger a per-IP rate limit. The requests are geographically distributed across the target country’s population centers, matching the expected geographic distribution of legitimate users.

Request Timing and Humanization

Automated credential testing at maximum speed generates request patterns that are statistically distinguishable from human login behavior: constant inter-request timing, no time spent reading pages, uniform user-agent strings, and sequential rather than random username ordering. Detection systems trained on behavioral baselines flag these patterns.

OpenBullet 2 and similar tools include configurable timing controls: random delays between requests (typically 2-8 seconds), simulated human interaction patterns including time-on-page delays, and request ordering randomization. Advanced operators randomize user-agent strings, accept-language headers, and connection characteristics to produce request profiles that match real browser diversity.

CAPTCHA Solving Services

Where targets deploy CAPTCHA challenges, attackers use commercial CAPTCHA-solving services that relay challenges to human solvers (typically low-wage workers who solve CAPTCHAs in bulk for payment) or to AI-based automated solvers for common CAPTCHA types. Services like 2Captcha and Anti-Captcha provide API integrations that connect directly to OpenBullet configs, automatically solving challenges and returning solutions within seconds. The cost is fractions of a cent per solved CAPTCHA.

Device Fingerprint Spoofing

Browser fingerprinting systems attempt to identify credential stuffing bots by detecting patterns in the browser environment: canvas fingerprinting, WebGL renderer information, installed fonts and plugins, screen resolution, timezone, and hundreds of other attributes. Sophisticated credential stuffing operations use Puppeteer or Playwright-based automation with stealth plugins that spoof these fingerprint components to produce browser profiles consistent with real user devices.

Stage 5: Credential Validation and Result Sorting

The output of a credential stuffing campaign is a hits file: a list of email-and-password pairs that produced successful logins. This raw output requires post-processing to sort by value and prepare for the next phase of exploitation.

What a Hits File Contains

For each successful login, the OpenBullet config captures the data it was programmed to extract from the authenticated session: account subscription tier, account balance, payment method on file, personal information visible in the account, and any other data accessible from the first authenticated page. The resulting hits file is structured by data category, enabling rapid sorting by account value.

Sorting and Monetization by Account Value

The hits file is sorted into tiers based on account value:

Tier 1 (highest value): Admin accounts, SSO sessions with many connected applications, cloud console access with IAM permissions. Sold to IABs or used directly for lateral movement and ransomware staging.

Tier 2 (medium value): Corporate email accounts, CRM access, project management tools. Used for BEC campaigns, data theft, or sold as lower-tier IAB listings.

Tier 3 (consumer value): E-commerce accounts with stored payment methods, streaming service accounts, gaming accounts. Sold in bulk on carding forums or used for direct fraud.

Tier 4 (bulk resale): Accounts with no immediately obvious value. Repackaged into a new hits file and sold as a bulk lot, since an unknown account may have value that only the buyer can assess.

Stage 6: Account Takeover Execution

A validated account credential is not yet a completed account takeover. The attacker must convert their temporary access into persistent control that survives password resets and MFA changes by the legitimate account owner.

Session Cookie Replay: The MFA Bypass

When an infostealer component provides a valid session cookie alongside the credential, the attacker replays the cookie directly: they inject the stolen cookie into a browser session and access the account without authenticating. This technique bypasses all authentication controls including MFA, because the session was created by the legitimate user during a proper authentication event. The attacker inherits an already-authenticated session.

Persistence Establishment Before Discovery

Immediately upon gaining access, the attacker races to establish persistence mechanisms that will survive the credential rotation that will eventually occur. These include:

OAuth application authorization: authorizing a new third-party application to the account creates a persistent access pathway that survives password resets. Many OAuth tokens remain valid indefinitely unless explicitly revoked.

Email forwarding rules: creating a silent forwarding rule copies all incoming email to an attacker-controlled address. This continues even after the victim changes their password and the attacker loses direct account access.

MFA device enrollment: on accounts that allow adding new MFA devices without re-authentication, adding an attacker-controlled phone number or authenticator app provides a re-entry mechanism after the original credentials are rotated.

Recovery contact modification: changing the account recovery email or phone number to attacker-controlled values enables account recovery even after the victim has locked the attacker out through other means.

The Lateral Movement Trigger

For corporate accounts accessed via credential stuffing, the attacker uses the compromised account’s existing OAuth connections and SSO integrations to enumerate and access connected services. A single compromised Microsoft 365 account with an authenticated session may have pre-authorized connections to Salesforce, SharePoint, Jira, GitHub, and HR platforms. The attacker accesses each through the compromised account’s existing authorizations, without triggering new authentication events.

Detection Signals at Each Stage of the Lifecycle

Each stage of the credential-to-ATO lifecycle creates signals that, if monitored, provide detection opportunities. The earliest signals, those in the dark web credential distribution stage, are available days to weeks before any authentication attempt reaches the target’s systems.

What Effective Defense Looks Like Against This Attack Chain

The credential-to-ATO lifecycle has multiple intervention points. Defending effectively requires operating at the earliest available point, which means external credential intelligence rather than authentication-layer controls alone.

Breached Password Detection at Authentication

Integrating your authentication layer with a breached password database checks every submitted credential against known compromised pairs at the moment of login. Microsoft and Google provide this natively for their identity platforms. For custom authentication systems, the HaveIBeenPwned k-anonymity API provides the same capability without exposing the full password to the checking service. Any credential that matches a known breach entry triggers an immediate forced reset before any session is established.

Platform-Level Authentication Analytics

Per-account failed login rate limiting, the standard control against brute force, provides minimal protection against credential stuffing because stuffing campaigns make exactly one attempt per account. Detection requires platform-level analysis: elevated failure rates across all accounts simultaneously, unusual geographic distribution of attempts, new device fingerprint patterns appearing at scale, and correlated timing signatures that differ from the human login baseline.

FIDO2 and Phishing-Resistant MFA

Standard MFA (SMS OTP, TOTP authenticator apps) is partially effective against credential stuffing: it stops password-only attacks but not session cookie replay from infostealers or AiTM phishing. FIDO2 hardware security keys and device-bound passkeys provide protection against all of these attack types because authentication is cryptographically bound to the legitimate domain and cannot be replayed or proxied. Deploying phishing-resistant MFA for privileged accounts and high-value identities removes them from the hits file’s Tier 1 category.

Continuous Credential Exposure Monitoring

The single highest-impact defensive investment is external intelligence that monitors for your domain’s credentials appearing in combolist distributions and stealer log markets. Detection at the distribution stage, 24-72 hours after credential theft and before the stuffing campaign runs, provides a forced reset window that eliminates the credential from the attack’s working set before any authentication attempt reaches your systems.

How Brandefense Closes the Credential Intelligence Gap

The credential-to-ATO lifecycle operates almost entirely outside your environment until the authentication attempt arrives at your login endpoint. Closing the gap requires intelligence that operates where the credentials are, not where you are.

The attacker in the opening scenario paid $85 and pressed a button. They did not need to exploit any vulnerability. They did not need any technical skill beyond configuring a tool that comes with a community forum and tutorial videos. The sophistication is not in the attack. It is in the supply chain that makes the attack possible: the breach databases, the infostealer ecosystem, the combolist market, the proxy network, the CAPTCHA-solving service.

Defending against this does not require matching the attacker’s technical sophistication at the authentication layer. It requires cutting the supply chain that feeds them. That means detecting credentials in the distribution pipeline before they are deployed, not detecting failed logins after they have been attempted.