24 billion credentials exposed in record infostealer leak

Share

Cybernews researchers have uncovered an exposed Elasticsearch cluster holding roughly 24 billion records and more than 8.3 terabytes of data, drawn from infostealer malware logs, breach compilations and Telegram dumps. Even allowing for heavy duplication, it is one of the largest credential troves ever publicly catalogued.

According to Deputy Editor Vilius Petkauskas, the team had to triple-check the find before publishing. The cluster pulled records from 36 separate sources, including breach "collections" and Telegram channels where stealer logs are routinely traded. The database is no longer publicly exposed, but the underlying credentials are already in circulation.

What was found

The bulk of the records appear to be infostealer logs: structured captures lifted from infected endpoints by malware families such as RedLine, Raccoon and Lumma. A typical line contains a username, an email address, a plaintext password and the exact login URL the credential belongs to, sometimes with session cookies attached.

That format matters. Unlike a leaked password hash, an infostealer log is a working set of keys with the lock address printed on the front. Researchers cannot yet confirm how many records are duplicates, or how many unique people are affected, but the practical attack surface is enormous.

Why infostealer logs matter

Infostealers do not guess passwords. They sit on a real device, wait for the user to log in, and copy what the browser already knows: saved credentials, autofill data, session cookies, crypto wallet files and, increasingly, multi-factor tokens. Strong password policies, rotation rules and SMS-based MFA do very little against that.

When those logs are aggregated into a single 24-billion-row index, two things happen at once. First, criminals can pivot from a low-value personal account to a corporate single sign-on entry point in minutes. Second, defenders lose any meaningful concept of "this credential is safe because it has not been in a public breach". The default assumption now has to be that it has.

Scale and the reuse problem

Password reuse turns a personal credential leak into a corporate one. A laptop infected at home leaks the same password the user types into the company VPN. Pension, payroll and customer portals routinely show up in stealer logs alongside Netflix and Steam. With 24 billion records to draw on, credential-stuffing operators can saturate every public login endpoint at very low cost.

The financial services, e-commerce and SaaS sectors will absorb most of the visible damage. The harder problem is what happens to long-life secrets, the ones that protect recovery, succession and audit material. Those rarely rotate, and they are often stored in the same browser, password manager or cloud vault as everything else.

The Firevault view

This is the failure mode Firevault was built to remove. A networked password manager, however well engineered, is reachable by anything that can run code on the endpoint. An infostealer that captures the master password, the session token or the cloud backup defeats the entire model in one step.

An offline secure storage module is not a replacement for a password manager. It is a physically separate place to hold the material that must survive an endpoint compromise: recovery keys, seed phrases, root credentials, succession instructions and the audit secrets you would need to rebuild trust afterwards. A Firebreak deployment keeps that material in a tamper-evident enclosure with no network path that a stealer log can ever reach.

The question we keep putting to security leaders is simple: if every credential your team has typed in the last five years showed up in a 24-billion-row index tomorrow, which of your secrets would you wish had never touched a browser?

What to do now

• Rotate any password that has been reused across personal and work accounts, starting with email, VPN, single sign-on and finance systems.
• Move from SMS and app-based one-time codes to phishing-resistant multi-factor authentication: passkeys, FIDO2 security keys or platform authenticators.
• Hunt for infostealer indicators on endpoints: unexpected browser profiles, recent password manager exports, anomalous traffic to Telegram or paste sites.
• Move long-life secrets, recovery keys and succession material into an offline, physically air-gapped store. Talk to us about gold-copy backups and Firebreak deployments.

Sources

• Vilius Petkauskas, Cybernews, "24 billion records, including usernames and passwords, exposed in colossal data leak".

Analysis by Mark Fermor, Firevault.

How Firevault helps

• Offline Secure Storage keeps gold-copy data physically disconnected from the network, so a ransomware or exfiltration event cannot reach it.
• Control gives boards and operators a single view of what is online, what is isolated, and what is recoverable across the estate.
• Firebreak delivers hardware-enforced disconnection at Layer 1, so exposed credentials or compromised network paths cannot become a route into the vault.

Talk to Firevault about Disconnect to Protect® for your organisation.

How Firevault would handle this

Physical disconnection removes the path an attacker needs

Offline Secure Storage® holds a clean copy of your data on hardware that is physically disconnected, so an intrusion cannot reach it, encrypt it or delete it.