The Infostealer Epidemic: 642 Million Stolen Credentials Are Already Inside Your Enterprise

There's one number that should change how every security team thinks about credential risk: 642.4 million. That's the count of exposed credentials SpyCloud recaptured from infostealer malware infections in 2025 alone — harvested from just 13.2 million infected machines, averaging 50 compromised accounts per device. These credentials didn't vanish into the void. They were packaged, sold, and handed to threat actors who are systematically testing them against your enterprise right now.

The SpyCloud 2026 Annual Identity Exposure Report, released March 19, 2026, is the most comprehensive snapshot of the modern credential theft ecosystem ever published. What it reveals should alarm every CISO: the infostealer supply chain has matured into an industrial operation, MFA is being bypassed at scale through session cookie theft, and the vast majority of security programs have no way to detect when stolen credentials are actually being used inside their environments.

I track infostealer markets for a living, and I'll say it plainly — this is not a hypothetical future threat. It's the operational reality facing enterprise security teams today, and it demands a fundamentally different approach to identity defence.

The Industrial Scale of Modern Credential Theft

Infostealers aren't sophisticated, novel malware. They're commodity tools — sold as malware-as-a-service kits that let low-skill actors harvest credentials across millions of endpoints at once. What changed in 2025 and 2026 is the sheer industrial efficiency of the ecosystem built around them.

SpyCloud's data tells the full story. In 2025 the company recaptured over 642.4 million exposed credentials from infostealer infections — a figure that represents only what one threat intelligence firm intercepted and analysed. The actual volume of stolen credentials circulating in criminal markets is substantially larger. Equally alarming: 80% of exposed corporate credentials contained plaintext passwords, so attackers don't need to crack or brute-force anything. The credentials are ready to use the moment they're purchased.

Beyond the username-and-password pairs, infostealers are now harvesting at the identity layer. SpyCloud recaptured 8.6 billion stolen cookies and session artifacts from the same dataset. These session tokens require no password at all. They let an attacker authenticate as the victim by replaying the session, skipping the login flow entirely — and, critically, skipping multi-factor authentication.

The scale of non-human identity (NHI) exposure makes it worse. SpyCloud identified 18.1 million exposed API keys and tokens in 2025, spanning cloud infrastructure providers, payment platforms, developer ecosystems, and AI services. As enterprises deploy more service accounts, automation pipelines, and AI agents, the NHI attack surface is expanding faster than most security programmes can track — a problem we dig into in our piece on honeytokens for API keys and non-human identities.

Why MFA Is Failing — and Why It Matters Now

For years, multi-factor authentication was positioned as the definitive control against credential theft. The logic was sound: even if an attacker had a password, they couldn't authenticate without the second factor. That calculus has broken down.

Infosecurity Magazine reported in March 2026 that MFA failures enabled infostealer-driven breaches at 50 enterprises. The mechanism is straightforward: infostealers harvest not just passwords but authenticated session tokens generated after MFA has already been satisfied. When an attacker replays that session token, the target application treats the request as a legitimate, already-authenticated session. No login prompt. No MFA challenge. The attacker simply inherits an active, authenticated identity.

This isn't a theoretical edge case. SpyCloud's data shows that 51% of its recaptured identity records overlapped with previously observed infostealer logs, meaning stolen credential packages are recycled, repackaged, and resold across criminal markets for months and years after initial theft. A session token harvested in late 2025 may still be valid in mid-2026. A password never rotated after an employee's device was compromised remains a live credential today.

The Security Boulevard analysis published this month frames this as an "identity persistence" problem. Credentials are persistent attack assets: once harvested, they don't degrade unless explicitly revoked. Most organisations have no systematic programme to identify and invalidate credentials that may have been exposed through infostealer infections on employee devices — devices that may sit outside the corporate security perimeter entirely. This is the same malware-free, login-with-valid-credentials pattern we traced in our look at the rise of the digital parasite.

The result is a hidden, growing population of valid credentials that are simultaneously known to your identity provider and to criminal markets. Your Active Directory trusts them. Your cloud applications accept them. Your MFA platforms don't flag them. The attacker who bought them at a dark web market is indistinguishable, to your authentication stack, from a legitimate user.

Why Traditional Controls Can't Catch This

The fundamental problem with infostealer-enabled credential attacks is that they don't look like attacks at authentication time.

Endpoint Detection and Response (EDR) tools catch infostealers on infected devices — but only on devices inside the corporate security perimeter, running managed software. The infected device may be a personal laptop, a contractor's workstation, or a home machine used for remote work. EDR coverage doesn't extend there.

Security Information and Event Management (SIEM) platforms analyse authentication logs for anomalous patterns — unexpected geolocation, unusual access times, atypical resource access. Sophisticated attackers who buy infostealer logs understand this, and they operate during business hours, from VPN infrastructure that mimics the victim's expected location, accessing only the systems the stolen credentials are associated with. The signal is engineered to look like noise.

Breach and attack simulation tools test your defences against known techniques. They can't test for credentials your security team doesn't know have been compromised — credentials sitting in a criminal market log that no threat intelligence feed ever intercepted.

Identity threat detection and response (ITDR) solutions monitor for suspicious patterns in authentication behaviour. They're effective against attackers who make mistakes — who access resources at odd hours, escalate privileges too quickly, or trip behavioural baselines. They're far less effective against patient attackers who use stolen credentials to move slowly and deliberately, accessing only what the credential's owner would legitimately access.

None of these controls fire an alert at the moment a stolen credential is first tested against your environment. None produce a zero-false-positive signal that tells you, definitively, that an attacker is using credentials they should not have.

How Credential Mines Build a Zero-False-Positive Detection Layer

Mine2's Credential Mines work on a different principle. Rather than trying to spot attacker behaviour through statistical anomalies in legitimate traffic, they create a detection surface that produces an unambiguous signal: an alert fires only when something that should never be touched is touched.

Credential Mines are synthetic, fake credentials — usernames, passwords, API tokens, service account entries — planted across the enterprise where an attacker enumerating credentials would find them. They live in configuration files, code repositories, endpoint memory, browser credential stores, and Active Directory. They look identical to real credentials. They're configured to authenticate against real-looking systems. But no legitimate process or user ever uses them.

When an attacker buys an infostealer log containing enterprise credentials, they typically run automated tooling to test which credentials are valid and what systems they unlock. That enumeration — credential stuffing against internal or external systems — is the moment Credential Mines trigger. The instant a mine credential is tested or used, Mine2 generates an alert with full context: the mine that fired, the source IP, the authentication attempt details, and the timestamp.

This is not probabilistic detection. It's not a behavioural threshold. It's binary: either a mine was triggered or it wasn't. Zero false positives, because legitimate users and systems never interact with mine credentials by design.

Against the infostealer chain specifically, Credential Mines provide detection at several points. If an infostealer harvests credentials from an endpoint and those credentials include mine entries, the mine fires when the attacker's tooling tests them. If an attacker uses purchased credentials to authenticate internally and finds mine credentials in configuration files or Active Directory, attempting to use those mines produces an immediate alert. If automated enumeration tooling touches a MineField decoy service — a fake TCP service that exists only to detect port scanning and lateral movement — the alert fires before the attacker reaches any real system.

AD Mines extend this into Active Directory specifically, where infostealer-sourced credentials are frequently tested. Fake AD accounts, planted with realistic names and attributes, fire alerts the moment they receive authentication attempts — catching credential spraying and enumeration before any real account falls.

Cloud Mines address the NHI exposure directly. Fake AWS access keys, service account tokens, and cloud API credentials planted in code repositories, CI/CD pipelines, and configuration management systems create a tripwire for the 18.1 million API keys circulating in criminal markets. When an attacker tries to use a Cloud Mine credential against AWS, the attempt is logged, the mine fires, and the alert is immediate. The same approach covers the OAuth and device-code angle we cover in our analysis of device code phishing and cloud token theft.

Breach Notification, Audit Trails, and Regulatory Deadlines

The infostealer epidemic has direct implications for organisations operating under breach notification regulations. When credentials are harvested from an employee's personal device and later used to access corporate systems, the regulatory question isn't whether a breach occurred — it's when the organisation first had the capability to detect it.

Under GDPR Articles 33 and 34, data controllers must notify supervisory authorities within 72 hours of becoming aware of a personal data breach. If stolen credentials give an attacker access to personal data, the 72-hour clock starts when the organisation has — or should have — detected the access. An organisation that deployed Credential Mines and received an alert at the moment of first use has a documented, timestamped detection record that satisfies the "awareness" standard. An organisation relying solely on SIEM anomaly detection may not detect the access until days or weeks later, long after the 72-hour window has closed.

The India Digital Personal Data Protection (DPDP) Act similarly requires prompt notification of data breaches to the Data Protection Board. As India's enterprise sector increasingly becomes a target for infostealer campaigns — with credentials harvested from employees' home devices and tested against corporate VPNs and cloud applications — the ability to detect and timestamp the moment of first access is critical to compliance.

PCI-DSS Requirement 11 mandates regular testing of security controls, including detection capabilities. Credential Mines provide a continuous, passive test of whether an attacker using stolen credentials would be detected — and the alert log provides evidence for PCI-DSS audit trails. This matters especially for financial services organisations, where infostealer campaigns frequently target payment platform credentials.

CERT-In's 6-hour reporting mandate for cybersecurity incidents — applicable to Indian enterprises across critical sectors — requires organisations to report incidents to India's Computer Emergency Response Team within six hours of detection. Mine2's real-time alert generation, delivered the moment a mine credential is used, provides the detection timestamp needed to meet this deadline. Without early-warning detection like Credential Mines, organisations may not identify an infostealer-enabled breach within six hours at all.

RBI and SEBI directives for Indian banking and financial market participants require demonstrable security controls around customer data access and privileged credential usage. Credential Mines provide audit trail evidence that proactive detection controls are in place — a posture that directly supports regulatory examination.

For HIPAA-covered entities in the United States, the combination of infostealer credential theft and session cookie replay presents a specific risk to Protected Health Information (PHI). Healthcare worker credentials harvested from personal devices and used to access EHR systems create HIPAA breach notification obligations. Credential Mines planted within healthcare credential stores provide the detection layer that lets organisations identify and bound the scope of such incidents within the 60-day HIPAA notification window.

A Practical Playbook for Deploying Credential Mines

Addressing the infostealer credential persistence problem starts with accepting a foundational reality: you can't prevent your employees' personal devices from being infected. You can't prevent credential theft from happening. What you can control is whether you detect the moment stolen credentials are used inside your environment.

Step 1: Map your credential exposure surface. Identify where credentials live beyond the obvious identity provider: configuration files, code repositories, CI/CD pipelines, endpoint credential stores, browser-saved passwords, Active Directory service accounts, cloud IAM, and API key stores. This is the surface area infostealers target and that Credential Mines should cover.

Step 2: Plant Credential Mines at every credential discovery point. Mine2's single-click deployment places mines across the identified surface in minutes. For endpoints, mine credentials go in the locations infostealers are known to harvest: browser credential stores, Windows Credential Manager, and common application configuration paths. For Active Directory, AD Mines create fake accounts indistinguishable from legitimate service accounts.

Step 3: Deploy MineField on internal network services. Attackers who use stolen credentials to establish a foothold inevitably do internal reconnaissance — port scanning, service enumeration, lateral movement. MineField decoy TCP services, deployed across internal segments, detect this activity before the attacker reaches a real system. Credential Mines (detecting credential use) plus MineField (detecting post-access movement) give you layered detection across the full attack chain.

Step 4: Add Cloud Mines for NHI credential protection. For each cloud platform in use, plant fake API keys and service account credentials where real credentials exist. AWS fake access keys committed to private repositories, planted in CI/CD configuration, and embedded in infrastructure-as-code templates ensure any attacker testing keys from infostealer logs trips an alert.

Step 5: Establish a credential rotation programme triggered by mine alerts. When a mine fires, it signals an attacker has access to credentials from that segment of the environment. Use the alert to rotate all real credentials in the same locations as the triggered mine — invalidating any other stolen credentials harvested alongside it.

Step 6: Connect mine alerts to your incident response playbook. Mine2 alerts integrate with existing SIEM and SOAR platforms. An automated playbook triggered by a mine alert can immediately isolate the source IP, force re-authentication for the affected session, and open an incident ticket — cutting mean time to response from days to minutes.

Detection at the Moment of Use

The infostealer epidemic represents a category shift in credential risk. The question is no longer whether your users' credentials will be harvested. At 642.4 million exposed credentials from a single year's worth of infostealer infections, the statistical probability that your organisation has affected credentials circulating in criminal markets approaches certainty for any enterprise of meaningful scale.

The question security teams must now answer is simpler and more urgent: how will you know when those stolen credentials are used?

Traditional controls — MFA, EDR, SIEM anomaly detection — are failing to answer it reliably. Session cookie theft bypasses MFA. Infostealers run on unmanaged devices outside EDR coverage. Patient attackers operating within behavioural baselines evade SIEM. The identity persistence problem — valid credentials unknown to the organisation but known to attackers — grows with every infostealer campaign.

Credential Mines answer the question with a binary, zero-false-positive signal: the moment a stolen credential is tested or used inside your environment, Mine2 detects it. No behavioural baseline required. No statistical threshold to tune. No attacker patience that outlasts your detection window. Just an immediate alert at the moment of first contact.

The infostealer supply chain is industrial. The defence against it has to be just as systematic.

---

See how Mine2's Credential Mines, AD Mines, and Cloud Mines detect infostealer-sourced credential attacks in your environment. Visit mine2.io/product to learn more.