Infostealers: Why Credential Theft Keeps Opening Enterprise Attack Paths

Key judgments

ASSESSMENT

1. Infostealer-derived credentials and session tokens remain a reliable route into enterprise environments. Confidence: moderate. Mandiant’s investigation of a large cloud data-theft campaign and Verizon’s breach data both support this, but neither measures infostealer use across all intrusions.

2. The decline in credential abuse as a headline initial-access vector should not be read as a decline in the threat. Confidence: moderate. Verizon’s own report attributes part of the drop to a classification change, and credential abuse still appears in 39% of breaches when counted at any stage.

3. Law-enforcement disruption has not removed the capability. Confidence: moderate. Current Wiz analysis still places Lumma among the three most-detected families after a major coordinated takedown.

4. The enterprise risk sits less in the malware than in what the stolen material can still do. Confidence: high. Credentials that were never rotated, accounts without MFA and sessions that outlive a password reset turn a past infection into present access.

What an infostealer takes

An infostealer is malware built for one job: collect everything of value from an infected machine and send it to the operator. It is not a remote-access tool and it does not usually stay around. It runs, harvests and moves on, which is part of why it is easy to miss.

Microsoft’s description of Lumma, one of the most widely used families, lists passwords, credit card details, bank account information and cryptocurrency wallets. In enterprise environments the more valuable haul is often different. Wiz’s recent research, based on infected-machine data from NordStellar, shows what stealers collect from developer and cloud workstations:

Long-lived cloud access keys and cached sign-in tokens for AWS, Azure and Google Cloud.
Source-control tokens and SSH keys. Wiz reports that about half of infostealer families collect GitHub credentials.
Browser session cookies, which can let an attacker act as a signed-in user without repeating the login.
API keys for AI platforms and, in Wiz’s analysis, credentials stored by AI coding tools on developer machines.

Wiz analyzed the secrets that were harvested and found that, of all compromised secrets in its dataset, AWS made up 46%, Google Cloud 13%, GitHub tokens about 10% and AI platforms about 5%. These figures come from one dataset and describe what that dataset contains. They show the mix of what is being taken. They do not show how often it is later used.

Why it keeps working

Old credentials stay valid

The clearest public case study is the Snowflake customer data-theft campaign investigated by Mandiant. The attackers, tracked as UNC5537, used credentials previously stolen by infostealers. The malware families involved included Vidar, RisePro, RedLine, Raccoon, Lumma and MetaStealer. Mandiant found no evidence that the access came from a breach of Snowflake’s own environment.

Three details matter for defenders. At least 79.7% of the accounts used in the campaign had prior credential exposure. Some credentials had not been rotated for as long as four years after the original infection. And the affected accounts had no MFA, with no network allow-list restricting where logins could come from, so a valid username and password was enough. Mandiant and Snowflake notified roughly 165 potentially exposed organizations.

In several of the investigations, the original infection occurred on contractor systems that were also used for personal activity such as gaming and downloading pirated software. This is an observation from specific cases, not proof that contractor devices are the dominant source. It does show how a personal device can become the entry point for a corporate environment.

Session theft sidesteps MFA

MFA protects the moment of login. A stolen session cookie or access token represents a login that has already happened. Wiz notes that console session cookies for cloud and source-control platforms can bypass MFA when replayed, and that cached single sign-on tokens on a workstation can last for weeks and be used to obtain fresh credentials. MFA remains essential, and the Snowflake case shows the cost of lacking it. It is not sufficient against material stolen after authentication.

The ecosystem is resilient

In a coordinated action, Microsoft’s Digital Crimes Unit, the US Department of Justice and Europol disrupted Lumma’s infrastructure, seizing or blocking around 2,300 domains. Microsoft reported more than 394,000 Windows computers infected with it over a two-month window. Wiz’s current analysis still ranks Lumma, RedLine and Vidar together as 85.7% of detected incidents in its dataset. Wiz also describes stealers being sold as a service for a few hundred dollars a month, citing other research. Takedowns raise costs and cause disruption. They have not ended supply.

Reading the breach statistics correctly

The latest Verizon Data Breach Investigations Report shows credential abuse as an initial-access vector at 13%, down from 22% the year before, and exploitation of vulnerabilities as the leading vector at 31%. That could read as good news for identity defense. The report itself offers two reasons for caution. Pretexting was added as a separate vector, and without it credential abuse would have been 16%. And when credential abuse is counted at any point in a breach, not only at entry, it remains the most common pattern at 39%, with use of stolen credentials as an action appearing in 36% of breaches.

The reasonable interpretation is that stolen credentials are less often the first move and remain a routine part of the middle of an intrusion: moving, escalating and reaching data. For a defender, that means credential defense cannot be relegated to a perimeter problem.

The attack path

The table below describes a representative path. The “Basis” column separates what has been observed in public investigations from what is analytical inference.

Stage	What happens	Defender opportunity	Basis
Infection	Malware runs on a personal, contractor or poorly managed device and harvests stored credentials, cookies and tokens	Device posture requirements; restrict corporate access from unmanaged devices	Observed (Mandiant, Wiz)
Collection and sale	Logs are packaged and traded, often long after the infection	Monitor for corporate credentials in stealer-log sources	Observed (Mandiant); market detail from vendor research
Validation	Operator tests which credentials still work, particularly on single sign-on, VPN, SaaS and cloud consoles	Alerting on logins from new infrastructure; account-level lockdown signals	Inference from observed outcomes
Access	Valid credentials or a replayed session reach a cloud, SaaS or build environment	MFA; allow-listing; short session lifetime; device-bound sessions where supported	Observed (Mandiant)
Expansion	Attacker looks for further tokens, keys and higher-privilege roles	Least privilege; short-lived credentials; detection of unusual token use	Observed in part; varies by case
Impact	Data theft and extortion in the Snowflake campaign; ransomware in other cases	Tested response plans; segmentation of crown jewels	Observed (Mandiant); ransomware linkage varies by case

What defenders should change

Most of the work is unglamorous. Listed here in the order that tends to reduce exposure fastest.

Treat an infection signal as a session event, not a password event. When a device is found to carry an infostealer, or when corporate credentials appear in stealer logs, revoke active sessions and tokens and rotate every secret that machine could reach, including API keys and cloud credentials. Resetting the password alone leaves replayable sessions in place.
Close the no-MFA and no-allow-list gaps on data platforms. The Snowflake case turned on both. Check every internet-reachable data platform and SaaS tenant for accounts that can authenticate with a password alone.
Move high-value access to phishing-resistant MFA and device-aware sessions. Where your identity platform supports it, require a compliant, managed device and bind sessions to it, so a stolen cookie is useless on another machine.
Shorten the life of what can be stolen. Replace long-lived cloud and source-control keys with short-lived credentials. Reduce single sign-on token lifetimes for sensitive roles. Keep standing keys off developer laptops wherever the workflow allows.
Treat contractor and personal-device access as your weakest endpoint. Apply the same posture checks, or provide managed virtual desktops, for anyone reaching production data.
Monitor stealer-log exposure and set an action time. A feed of exposed corporate credentials is only useful if someone is accountable for revoking and rotating within a defined window.
Hunt for token misuse. Look for valid credentials or tokens used from new infrastructure, sessions that continue after a user’s device posture changes, and cloud API calls from unfamiliar addresses using keys that normally run from fixed ones. Mandiant’s published hunting guidance for the Snowflake campaign is a useful model for building queries.

Questions for attack path analysis

If you map attack paths to your most important systems, add infostealer exposure as an input. Ask which identities and tokens lead to crown jewels, and which of those could be present on an unmanaged device or a developer workstation. Ask which of them lack MFA, device binding or an allow-list. The overlap is your realistic short list.

Intelligence gaps and limits

Prevalence. No source reviewed for this brief measures how many enterprise intrusions begin with infostealer material. Verizon’s data covers credential abuse in general, not stealer-sourced credentials specifically.
Attribution of cause. Linking an intrusion to a particular past infection is often not possible. Investigators frequently infer the connection from credential age and exposure records.
Vendor data. Several figures here come from security vendors’ telemetry. They reflect those vendors’ customers and sensors, and may not represent your sector or region.
Ecosystem change. Family names and market share shift as operators rebrand or rebuild after disruption. Treat family-level detail as a snapshot.

NEXT STEP

Pick your three most important systems and test whether a stolen session on an unmanaged device could reach them today.

Sources

Mandiant (Google Cloud), UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion: initial access via infostealer credentials, credential age, absence of MFA and network allow-lists, notification figures. cloud.google.com
Verizon, Data Breach Investigations Report (latest edition) and executive summary: initial-access vector percentages, credential abuse across the breach progression, use of stolen credentials. verizon.com
Wiz Research, The Infostealer Incursion: Cloud, Code & AI Breaches: stealer family share, secrets harvested by type and platform, session-token behavior. Statistics derived from NordStellar data as described by Wiz. https://www.wiz.io/blog/infostealer-incursion-cloud-ai-credentials
Microsoft On the Issues, Disrupting Lumma Stealer: Microsoft leads global action against favored cybercrime tool: scale of infection, data targeted, takedown actions by Microsoft, the US Department of Justice and Europol. blogs.microsoft.com