Infostealer Threat Guide

Infostealers turn one infected laptop into a bundle of working passwords, session cookies and cloud keys that criminals sell on, and most organisations only find out when someone uses them. This guide explains how the infostealer economy works, how infections happen, why the payload is really identity, and how to prevent, detect and respond to stealer exposure across managed and personal devices. It is written for security operations, identity and endpoint teams, and for incident responders who have just received a "your credentials appeared in a stealer log" alert. Malware behaviour is described only at MITRE ATT&CK description level, using ATT&CK v20, government advisories and law enforcement announcements.

Key takeaways

• The product is the log, not the malware. Stealers such as Lumma, RedLine and META are rented as malware-as-a-service, and their output is sold as "logs" to fraudsters and initial access brokers.
• Session cookies defeat MFA after the fact. ATT&CK notes that replaying a stolen web session cookie "bypasses some multi-factor authentication protocols since the session is already authenticated" (T1550.004).
• The infected device is often not yours. In the Snowflake campaign, Mandiant found initial infections on contractor systems "also used for personal activities, including gaming and downloads of pirated software."
• Cleaning the endpoint is not the response. Every credential, cookie, token and secret on the device must be treated as stolen and revoked, including API keys and cloud credentials on developer machines.
• Takedowns help but do not expire old logs. Snowflake credentials used in 2024 dated back to infections in November 2020 and had not been rotated for up to four years.

How the infostealer economy works

An infostealer is malware built to collect stored credentials, browser data and files from a device and send them to the operator, usually in a single pass. ATT&CK describes Lumma Stealer (S1213) as malware-as-a-service (MaaS) "where captured data has been sold in criminal markets to Initial Access Brokers." The model separates three roles:

• Developer: builds the stealer, runs the panel and sells subscriptions. Microsoft reported that Lumma's Russia-based developer, alias "Shamel", sold access tiers priced from $250 to $1,000, plus a $20,000 source code tier.
• Affiliate (customer): buys a licence and runs the distribution campaigns. The US Department of Justice described RedLine and META as a "decentralized" MaaS model in which affiliates buy a licence and run their own campaigns.
• Log buyer: buys the output. Logs are sold individually on marketplaces (Russian Market is a well-known example), in bulk on Telegram channels, or flattened into combolists (username and password pairs) used for credential stuffing.

Scale is significant. FBI and CISA advisory AA25-141B cites private-sector data showing more than 21,000 market listings selling LummaC2 logs between April and June 2024, a 71.7 percent increase on the same period in 2023. Microsoft identified over 394,000 Windows computers infected with Lumma between 16 March and 16 May 2025.

Families documented by official sources

Genesis Market shows where the economy leads. When it was disrupted in Operation Cookie Monster (April 2023), the DOJ said it had offered data from over 1.5 million compromised computers and over 80 million credentials, packaged with device fingerprints combining identifiers and browser cookies so buyers could "circumvent anti-fraud detection systems." See the Malware Guide for the wider malware landscape.

How infections happen

Stealers rely on the user running something. The vectors below come from AA25-141B, the Operation Magnus announcement and Microsoft's ClickFix analysis.

ClickFix deserves particular attention because the user, not a file, launches the payload, so file-based controls may never see it. ATT&CK v20 lists it as T1204.004, describing "fake fixes or CAPTCHAs" that tell users to paste code. Microsoft named Lumma Stealer the most prolific ClickFix final payload it observed. See the Phishing Guide and the PowerShell Security Guide.

What gets stolen, and why identity is the payload

Stealers collect quickly and exfiltrate over the command and control channel (T1041). For defenders, the useful view is what each item lets a buyer do next.

Where identity fits

Identity is the reason infostealers matter to enterprises. A session cookie for an identity provider or SaaS application is a bearer credential: whoever holds it is the user until it expires or is revoked. The DOJ noted that stolen cookies can help attackers get past MFA, and Google's Chrome team observed that stolen cookies keep working even after antivirus removes the malware.

Developer and administrator machines carry non-human identity secrets: cloud access keys, Git and package registry tokens, Kubernetes configuration and API keys for AI services. A stealer on one of these devices compromises the workloads those secrets control, not just one person. The Bybit hack turned on a developer's AWS session tokens, and credential stealers in the Trivy supply chain attack and the telnyx PyPI compromise, both attributed to the TeamPCP group, were built to harvest CI and cloud credentials from developer and build environments. See the Token and Session Security Guide and the Secrets Management Guide.

Personal devices and synced browser profiles

Many stealer logs containing corporate credentials come from devices the organisation does not manage: home computers, contractor laptops and shared family machines. Three paths bring corporate identity onto those devices:

• Browser profile sync: a user signs in to a personal browser profile on a work device, or the reverse, and saved passwords and sometimes sessions follow. The Cisco breach began with a work credential synced to a personal browser account.
• Bring your own device (BYOD) web access: employees reach SaaS applications from home machines without any device check, leaving cookies and passwords in an unmanaged browser.
• Third parties: contractor and partner devices hold your credentials but sit outside your EDR. The Snowflake breach and the Scania breach both involved credentials stolen from outside the victim's own estate.

Controls that work regardless of the device sit at the identity layer: require a compliant or registered device for sensitive applications, restrict browser sign-in to corporate accounts on managed devices, and bind sessions to devices where the platform supports it. See the Device Trust and Posture Guide and the Third-Party Access Guide.

Prevention controls

Endpoint

• Application control: AA25-141B recommends that organisations "Implement application controls to manage and control execution of software", noting allowlisting can block portable executables that antivirus misses. See the Application Allowlisting Guide.
• No standing local admin: Chrome's App-Bound Encryption (Windows, from Chrome 127) means malware must gain system privileges or inject into the browser to read cookies. Google notes this helps most where users cannot run downloads as Administrator. See the Endpoint Privilege Management Guide.
• Attack surface reduction: Microsoft recommends the ASR rules "Block execution of potentially obfuscated scripts", "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" and "Block JavaScript or VBScript from launching downloaded executable content" against ClickFix chains.
• ClickFix hardening: apply the Group Policy "Remove Run menu from Start Menu" where users do not need the Run dialog, enable PowerShell script block logging, and use the Windows Terminal setting that warns on multi-line paste.
• EDR in block mode on every endpoint: AA25-141B notes LummaC2 uses obfuscation aimed at evading EDR and antivirus. See the EDR Evasion and Defence Guide.

Browser

• Managed browser policy: disable the built-in password manager where an enterprise password manager is provided (PasswordManagerEnabled), restrict profile sign-in to corporate accounts (RestrictSigninToPattern in Chrome) and disable sync to personal accounts (SyncDisabled).
• Extension allowlisting: block all extensions by default and allow approved ones by ID (ExtensionInstallBlocklist and ExtensionInstallAllowlist).
• Keep App-Bound Encryption on: leave the ApplicationBoundEncryptionEnabled policy at its default except where roaming profiles require otherwise. See the Enterprise Browser and Browser Security Guide.

Identity

• Phishing-resistant MFA everywhere: all three Snowflake contributing factors were identity controls: no MFA, credentials not rotated, and no network allow lists.
• Token binding: Microsoft Entra Token Protection is a Conditional Access session control that accepts only device-bound sign-in session tokens such as Primary Refresh Tokens. It is generally available for native Exchange Online, SharePoint Online and Teams clients on Windows, with browser support in preview for Azure Resource Manager only. Google's Device Bound Session Credentials (DBSC) work binds browser sessions to a TPM-held key; it was a prototype when announced in April 2024.
• Shorter sessions for high-value applications: reduce sign-in frequency for admin portals, cloud consoles and code repositories so stolen sessions expire sooner.
• Short-lived NHI credentials: replace long-lived cloud keys and personal access tokens on developer machines with federated, short-lived credentials so a stolen file is worth little. See the API Key Management Guide.

Detection and measurement

• Endpoint signals: non-browser processes reading browser credential and cookie stores (ATT&CK analytic AN1402), Chrome Event ID 257 in the Application log when App-Bound Encryption verification fails, suspicious entries in the RunMRU registry key, and PowerShell script block events (4104) launched from the Run dialog.
• Identity signals: a session used from a new user agent, ASN or country without a matching sign-in (AN1406 "Use of session cookies from unusual user agents or locations"), impossible travel within one session, new MFA method registration and new OAuth consents after a suspected exposure.
• Cloud and NHI signals: API calls from an access key or token at an unexpected source address, and first use of a long-dormant key.
• External intelligence: stealer log and leaked credential monitoring for corporate domains, SSO URLs and key prefixes, matched to the user and device. See the Threat Intelligence Guide and the Detection Engineering Guide.

Responding to an infostealer exposure

Treat a confirmed infection, or a credible log containing your users' data, as a credential compromise incident. The order matters: revoke before you clean, or the buyer keeps access through sessions you have not ended.

1. Scope from the log: if you have the log or a monitoring summary, list every domain, application and credential type it contains, plus the infection date. Browser history widens the list.
2. Isolate the device: contain it through EDR; for unmanaged devices, block the user's access from that device and ask the owner to rebuild it.
3. Revoke sessions: revoke identity provider sessions and refresh tokens (in Microsoft Entra, the Revoke sessions action), then sign the user out of each SaaS application that keeps its own sessions. A password reset alone may not end existing sessions.
4. Reset credentials and check MFA: reset passwords, remove unrecognised MFA methods and OAuth grants, and re-enrol authenticators if MFA extension data was taken.
5. Rotate NHI secrets: rotate every cloud key, personal access token, SSH key and API key that was on the device, and review their recent API activity. See the Leaked Credential Response Playbook.
6. Hunt for use: search sign-in and API logs from the infection date forward for activity from new devices or locations.
7. Rebuild, then fix the cause: reimage rather than clean, and address the root cause (cracked software, admin rights, personal profile sync) to prevent reinfection. See the Incident Response Guide.

Implementation roadmap

1. Weeks 0 to 4, visibility: start stealer log and leaked credential monitoring, inventory which SaaS applications are outside SSO, and find long-lived cloud keys on developer endpoints.
2. Weeks 4 to 8, response readiness: write the revocation runbook above, test it on a test account per major application, and record which applications cannot revoke sessions centrally.
3. Weeks 8 to 16, browser and endpoint: pilot browser policies (sign-in restriction, sync, extension allowlist) and ASR rules in audit mode with one IT ring, review blocked events, then enforce by ring. Roll back by moving a ring back to audit, not by removing the policy.
4. Months 4 to 9, identity binding: deploy device compliance conditions and token binding in report-only mode first, capturing interactive and non-interactive sign-in logs as Microsoft advises, then enforce for administrators and developers before everyone else.
5. Ongoing: replace long-lived NHI credentials with short-lived federated ones and validate controls against the ATT&CK techniques in AA25-141B, as the advisory recommends.

Decision guidance: a small organisation without EDR on every device gains most from SSO with phishing-resistant MFA, managed browsers and a revocation runbook, because these work even when the endpoint is lost. A large organisation should add stealer log monitoring and token binding, and prioritise developers and administrators, whose devices hold the highest-value NHI secrets.

Framework mapping

Common failure patterns

• Cleaning the device and stopping there: stolen cookies and keys keep working after the malware is gone. Revocation is the response.
• Never rotating old credentials: Snowflake credentials used in 2024 had not been rotated for up to four years. Stealer logs stay useful until you act.
• Trusting a password reset to end sessions: many SaaS applications keep sessions and refresh tokens alive after a reset unless explicitly revoked.
• Ignoring third-party and personal devices: the Schneider Electric breach began with credentials linked to an infostealer infection, a pattern also seen at Scania and Snowflake.
• Forgetting the NHI secrets: responders reset the user's password but leave the cloud access keys and tokens from the same laptop untouched.
• Single-factor access to data platforms: warehouse and SaaS accounts without MFA or network restrictions are the easiest buy for log purchasers.

Practitioner checklist

• Monitor stealer logs and leaked credential sources for your domains, SSO URLs and key prefixes, with a named owner for alerts.
• Maintain a tested session and token revocation runbook for the identity provider and every high-value SaaS application.
• Remove standing local admin rights and enforce application control on endpoints.
• Apply ClickFix hardening: Run dialog restrictions, PowerShell script block logging and ASR rules in block mode.
• Enforce managed browser policies: corporate-only sign-in, no personal sync, extension allowlisting, App-Bound Encryption on.
• Require phishing-resistant MFA and compliant devices for administrators, developers and data platforms.
• Pilot token binding in report-only mode and enforce for privileged users first.
• Replace long-lived cloud keys and personal access tokens on developer machines with short-lived credentials.
• Rotate every credential, token and secret on an infected device, not just the user's password.
• Track time to revocation and repeat infections, and report both monthly.

Standards and references

• FBI and CISA: Threat Actors Deploy LummaC2 Malware to Exfiltrate Sensitive Data from Organizations (AA25-141B)
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• MITRE ATT&CK: Lumma Stealer (S1213)
• US Department of Justice: U.S. Joins International Action Against RedLine and META Infostealers
• Microsoft: Disrupting Lumma Stealer: Microsoft leads global action against favored cybercrime tool
• Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• Microsoft Learn: Token protection in Microsoft Entra Conditional Access
• Google Security Blog: Improving the security of Chrome cookies on Windows

Related NHI Mgmt Group resources: Malware Guide · Token and Session Security Guide · Leaked Credential Response Playbook · Account Takeover Prevention Guide · EDR Evasion and Defence Guide