Infostealer Logs Are Becoming the New Breach Database

For most of the last decade, "the breach database" meant a stolen copy of a company's user table — a single SQL dump from a single victim, leaked once. That model is being quietly replaced. The richest, most current source of usable credentials today is not a hacked server at all. It is the infostealer log: the everyday output of malware running on ordinary endpoints, harvested by the millions and assembled into searchable indexes that increasingly look and function like breach databases — except they are continuously refreshed and span every service a victim touched.

What an infostealer log actually contains

An infostealer is commodity malware — families like Lumma, StealC, Vidar, RedLine, and Raccoon dominate the current landscape — that runs once on a compromised machine and exfiltrates a structured bundle of identity material. According to threat-intelligence vendors tracking the ecosystem, a typical log goes far beyond passwords. It commonly includes:

• Browser-saved passwords decrypted from Chrome, Firefox, Edge, and Brave using keys pulled from the host OS.
• Active session cookies — the authenticated tokens that grant access to a service without re-entering a password or a second factor.
• Autofill data: addresses, payment-card details, and personally identifying information.
• Cryptocurrency wallet files and seed phrases.
• System metadata: hardware fingerprints, installed software, screen resolution, timezone — enough to help an attacker impersonate the victim's device.
• The exact URLs where each credential was used.

That last item is the structural shift. A classic breach dump tells you a password for one site. An infostealer log tells you every site a person logged into from that machine, paired with the working credential and often a live session for each. Constella's 2026 reporting found that roughly 98.6% of the infostealer packages it processed contained active passwords and over 99% included the specific URLs where those credentials were used — a direct map to each compromised account.

Why stolen logs behave like a breach database now

Three properties push infostealer logs past the old breach-dump model.

Scale. This is no longer a niche feed. Industry analyses put the number of devices infected by infostealers in the last year in the tens of millions, contributing billions of stolen credentials, cookies, and tokens to the pool. Constella reported processing roughly 51.7 million infostealer packages in 2025 — a 72% year-over-year increase. Aggregations like the recently exposed 24-billion-record Elasticsearch cluster found by Cybernews were, by the researchers' own account, mostly infostealer logs stitched together with Telegram dumps. The aggregate has become large enough to query like a database.

Freshness. A leaked 2019 user table is stale — passwords get rotated, accounts get closed. Infostealer logs are produced daily from live infections. Security researchers describe a window of roughly 48 hours or less between an infection and the verified log appearing for sale on marketplaces. The data buyers get is current by construction.

Coverage. Because the malware scrapes the whole browser profile, a single log can expose a personal email, a corporate SSO login, a SaaS admin panel, and a cloud console at once — crossing the boundary between an employee's personal and professional life that traditional breach dumps never bridged.

The session-cookie problem

The detail that most changes defensive thinking is the session cookie. A stolen, still-valid cookie lets an attacker resume an already-authenticated session — which means multi-factor authentication may be bypassed entirely, because the second factor was satisfied when the session was first created. This is why "we have MFA everywhere" is a necessary but incomplete answer to the infostealer threat. The log carries the keys to a door that is already unlocked.

The mitigations are specific: short session lifetimes, the ability to revoke sessions centrally, token binding to a device or IP where the platform supports it, and monitoring for impossible-travel or anomalous session reuse. None of these touch the password at all — they target the cookie.

What this means for defenders and for threat intel

For defenders, the practical reframe is to stop treating "are we in a breach?" as a discrete, occasional event and start treating infostealer exposure as a continuous condition. The useful questions become: are any of our domains appearing in fresh infostealer feeds, are managed endpoints showing infection indicators, and can we revoke sessions fast enough to outrun a 48-hour resale window?

For the threat-intelligence industry, infostealer logs have become a primary collection source — which is exactly why the platforms aggregating them are now high-value targets themselves, as the recent Elasticsearch exposure demonstrated. The data that protects clients is the same data that, if mishandled, becomes the next leak.

Build a basic cybersecurity checklist

Bottom line

The "new breach database" is not a database anyone built on purpose. It is the emergent product of millions of infected endpoints, refreshed daily, indexed by URL, and increasingly including the session cookies that make MFA optional for an attacker. Treating it as a one-off event misses the point. The organizations that fare best will be the ones that monitor infostealer feeds continuously, harden endpoints against the initial infection, and can kill a stolen session before it is resold.

Sources and further reading