Stealer Logs: Inside The Credential Market HIBP Doesn't See

In October 2024, Dutch police, the UK National Crime Agency, the FBI, and Europol jointly announced Operation Magnus — a coordinated takedown of the infrastructure behind Redline Stealer and META Stealer. The infostealer economy did not contract. New stealer families replaced them within weeks, Telegram channels continued distributing logs daily, and for most organisations, stealer logs remain the largest credential exposure vector they have no visibility into.

This article explains what stealer logs are, how infostealer malware evolved into the commodity ecosystem it is today, who sits at each tier of the supply chain, and why the session cookies inside those logs are more dangerous than the passwords they accompany. The broader context of the credential marketplace sits in our Credential Leaks hub.

1. What a stealer log actually is

A stealer log is not a breach dump. A breach dump is a server-side leak — one company, one database, millions of users. A stealer log is the opposite: one device, one infection, one snapshot of everything the user had access to at the moment the malware ran.

A typical log is a compressed archive — often named by country code, date, and infection ID — with a predictable folder structure:

• /Passwords/ — credentials extracted from Chrome, Edge, Firefox, Brave, Opera, and any Chromium fork on the machine
• /Cookies/ — session cookies from every logged-in browser profile, often tens of thousands per device
• /Autofill/ — stored form data including names, addresses, phone numbers, and partial card details
• /Wallets/ — crypto wallet files and browser extension data (MetaMask, Phantom, Exodus)
• /System Info/ — hostname, OS version, installed software, running processes, hardware ID, IP address, geolocation
• /Screenshot/ — a desktop capture taken at the moment of infection
• /Telegram/, /Discord/, /FileZilla/, /VPN/ — application-specific credential and config exfiltration

This is a per-device capture. A single log tells the buyer who the victim is, what they do, where they work, what services they use, and — critically — whether they are actively logged into any of those services at the time of sale.

2. Four eras of infostealer development

Infostealer malware did not emerge as a commodity. It evolved through four reasonably distinct phases, each defined by a shift in distribution model or capability.

2012–2016: Banking trojans with credential side-features

Zeus, Citadel, and Pony/Fareit dominated this period. Credential theft existed, but it was a secondary capability attached to banking fraud operations. These families were operator-run, targeted at banking customers in specific geographies, and rarely sold as turnkey subscriptions. The volume of logs produced was modest, and there was no mature secondary market for them.

2016–2019: First Malware-as-a-Service generation

AZORult, which emerged around 2016, is a useful marker. It was cheap, semi-automated, and sold on Russian-language forums. Telegram began to emerge as a distribution and command-and-control channel. The emphasis shifted from banking precision to volume. Logs became a tradable commodity, though the ecosystem was still fragmented.

2019–2022: The commodity era

Redline Stealer, which surfaced in 2020, is the watershed. Redline was cheap, modular, delivered through a Telegram-based panel, and priced low enough that the barrier to entry collapsed. Raccoon Stealer followed a subscription model — flat weekly or monthly fees for access to the panel and the logs it produced. Vidar and META Stealer expanded the category. By 2021, session cookie exfiltration was a standard feature rather than an optional module. This is the period where the stealer log economy became a scaled market rather than a cottage industry.

2023–present: Current generation

Lumma Stealer became dominant across 2024 and into 2025, with heavier evasion — anti-VM checks, encrypted command-and-control, and an increasing focus on corporate credentials and SaaS session cookies. Meduza, Stealc, and Mystic Stealer round out the current generation on Windows. macOS is no longer excluded: Atomic Stealer (AMOS) and its variants actively target macOS users, extracting Keychain data and browser credentials. MaaS panels now include buyer analytics — log filtering by domain, geography, and software footprint.

3. The supply chain — four distinct actor tiers

Treating "stealer operators" as a single group misses how the economy actually works. There are four tiers, and the skill, risk, and profit profile at each tier differs.

Tier 1 — Malware authors. The developers who write and maintain the stealer itself. This is a small population. Law enforcement action has concentrated here because disruption at the author level has the largest downstream effect. Mark Sokolovsky, identified as the developer of Raccoon Stealer, was arrested in the Netherlands in March 2022 and later extradited to the United States. Operation Magnus, announced in October 2024 by the Dutch National Police, the UK National Crime Agency, the FBI, and Europol, disrupted the infrastructure behind Redline Stealer and META Stealer and named Maxim Rudometov as a Redline developer. Lumma Stealer's operator, documented in public threat research under a known forum handle, remains at large at the time of writing.

Tier 2 — MaaS operators. These actors license or resell the stealer, run the subscription panels, handle customer support on Telegram, and take a cut of the revenue. They rarely write the malware themselves. They are resellers and platform operators, closer in function to SaaS distributors than to developers.

Tier 3 — Log buyers and traffickers. Bulk buyers purchase logs directly from MaaS panels, filter them by high-value domains (banking, corporate SSO providers, crypto exchanges, enterprise SaaS), and resell the filtered subsets. This tier is where the real commercial action happens. A single well-filtered log — one containing a fresh Okta or Microsoft 365 session cookie from a corporate victim — is worth significantly more than the raw log it came from.

Tier 4 — End users. The fraud operators, account takeover crews, and crypto drainers who actually use the credentials. Low technical skill is typical. They buy filtered logs from traffickers, monetise quickly, and move on. Genesis Market, seized in April 2023 by the FBI and Dutch police in Operation Cookie Monster, served this tier directly — a retail interface for log buyers who wanted session cookies packaged with browser fingerprints to evade fraud detection.

Disruption at Tier 1 slows the ecosystem. Disruption at Tier 4 does almost nothing — the end users are fungible.

4. Session cookies — the primary value

Passwords are the headline item in a stealer log. Session cookies are the reason the log sells for a premium.

A valid session cookie is a pre-authenticated ticket. The buyer does not need the password. They do not need to answer security questions. They do not need to pass MFA — because from the server's perspective, the session has already passed MFA at login. Importing the cookie into a browser of the same fingerprint, or replaying it through a tool that handles the fingerprint for them, returns an authenticated session.

This matters in three specific ways. First, MFA is bypassed entirely. Hardware keys, TOTP apps, push notifications — none of them trigger on a replayed session cookie. Second, the victim is not alerted. No login notification fires because no login event occurs. Third, in corporate SSO environments, a single valid session cookie for an identity provider — Okta, Microsoft Entra, Ping — yields authenticated access to every federated application downstream. One cookie, dozens of SaaS tenants.

Session cookies expire, but many corporate SSO configurations set session lifetimes in days or weeks. Fresh logs — infections from the last 24 to 72 hours — command the highest prices precisely because the cookies inside are still valid.

5. The log marketplace economy

Stealer logs are distributed through several overlapping channels. Public Telegram channels — often using "freelogs" branding or similar — release daily drops of low-value logs as loss leaders, with premium logs sold through private channels and direct deals. Russian Market and 2easy Market operate as web-based storefronts with category filters and searchable inventories. Genesis Market's successors have attempted to reconstitute its specific niche — session cookies bundled with browser fingerprints — with varying degrees of success since the April 2023 takedown.

MaaS panel subscriptions are priced in tiers. Exact pricing shifts and is rarely worth quoting with precision — forum posts are routinely outdated and marketing — but the pattern is consistent: flat monthly subscription for panel access, higher tiers for more configuration options, separate pricing for the logs themselves if buyers purchase from the operator rather than deploying the stealer themselves.

Log freshness is the dominant pricing variable. A log less than 24 hours old, containing live session cookies, sells at a multiple of a log more than a week old. Buyers filter aggressively by domain: a standing request for logs containing cookies from specific corporate SSO providers, specific banks, or specific crypto exchanges. Hudson Rock's Cavalier database, which indexes publicly circulating stealer log data, has repeatedly cited circulation volumes in the millions of active infections — a useful public reference point for the scale of the ecosystem, even accounting for overlap and stale data.

6. Corporate exposure vectors

The most common corporate stealer log exposure does not originate on a corporate device. It originates on a personal one.

An employee uses a personal laptop to sign into a work service — webmail, a SaaS tool, a VPN portal — either directly or via a synced browser profile. Chrome profile sync carries passwords and cookies from the personal machine into the work context and back again. A cracked game installer, a fake browser update, or a malicious PDF on the personal device runs the stealer. The log that results contains corporate credentials and corporate session cookies, harvested from a device the corporate security team has no visibility into.

Other recurring vectors include contractor and third-party laptops, BYOD devices outside MDM coverage, VPN configuration files stored in user directories, and SSO session cookies that persist long after the last intentional login. Remote workers running corporate software on personal machines are a standing exposure class.

The operational problem is that traditional breach monitoring does not surface any of this. The credentials were not leaked by the corporate identity provider. The session cookies were not leaked by the SaaS vendor. Both were exfiltrated from an endpoint the corporate team cannot audit. The consequences once a log lands in the wrong hands are covered in detail in our analysis of what happens after corporate credentials leak.

7. The detection gap

Have I Been Pwned is an excellent service for what it does: it aggregates breach database releases and lets users check whether their email appears in known corpora. It is not a stealer log service. HIBP does not monitor Telegram channels, does not ingest Russian Market inventory, and does not resolve session cookies to the domains they authenticate against. A person whose credentials are actively circulating in a stealer log can check HIBP and receive a clean result.

Commercial stealer log intelligence services exist specifically to fill this gap. Flare, Hudson Rock (Cavalier), SpyCloud, and Constella Intelligence each maintain collections of stealer log data sourced from underground channels, with varying ingestion pipelines, coverage, and freshness. What they actually check is not "has this email been breached" but "does this email, domain, or session cookie appear in the logs we have processed." The answer comes with context — which stealer family, which date, which device fingerprint — that a breach database lookup cannot provide.

The practical gap for most organisations is that they are not running any of these services. There is no visibility into whether employee credentials are currently for sale. There is no alerting when a corporate domain appears in a new log drop. The first indication of exposure is often a fraud event or a successful account takeover — months after the credentials were sold.

8. Response triage

If credentials or session tokens for an identity appear in a stealer log, a password reset is not sufficient and is not the first step. The sequence that actually closes the exposure looks like this:

• Force session revocation across every affected service. Revoking active sessions invalidates any cookies already in a buyer's hands. This is the single most time-sensitive action. Password resets alone do not revoke existing sessions in many SaaS platforms — the cookie continues to work until server-side expiry.
• Reset and re-enrol MFA. If the stealer was on the device long enough, the MFA seed or backup codes may also be compromised. Re-enrolment forces a new factor.
• Purge the browser credential store on the affected device. Passwords and cookies stored in the browser should be cleared, and the browser profile should be considered compromised until verified clean.
• Investigate the device. The malware is the root cause. If the infection is not remediated, the next login re-exposes everything. Forensic imaging, EDR review, or full device rebuild depending on context.
• Prioritise by access graph. SSO, VPN, email, and admin panels come before the specific account named in the log. A stealer log rarely contains only one useful credential.
• Check for lateral movement. If the victim is a corporate user, assume the session cookies were used. Review authentication logs for the affected accounts across the last 30 to 90 days, focused on anomalous IPs, unfamiliar user agents, and OAuth grants the user did not initiate.

This is the sequence our account compromise investigation workflow follows when a client credential surfaces in stealer log infrastructure. The order matters — reset the password first and the active session remains valid while the new password is still propagating.