A security vendor or a customer writes to say "your company's domain appears in stealer logs". Or an account that has had MFA for years is found reading mail from an unfamiliar location, and the user says they never saw an MFA prompt. Both situations usually trace back to the same kind of malware: the infostealer. It takes more than passwords. It also takes the sessions that are already signed in inside the browser, and an attacker who has those can simply pick up a connection that passed MFA long ago.

This guide is for IT staff and managers. It explains what infostealers take and why MFA does not stop them, then looks at how infections happen and how stealer logs are traded, using the 2024 Snowflake customer data theft and the 2025 Lumma takedown as examples. It ends with what to do when you get a notification and how to prevent the next one. Comparing MFA methods is out of scope here; see the MFA rollout guide.

More than passwords: why MFA does not stop it

Take Lumma, a common infostealer. Microsoft's analysis shows it extracts saved passwords, session cookies and autofill data from Chromium-based browsers (including Edge) and Mozilla-based browsers, and also collects cryptocurrency wallets, VPN configuration files (.ovpn), email and FTP client data, Telegram data, and user documents such as PDF and DOCX files[1]. In other words, one infected computer hands over every credential the user ever saved in the browser, work and personal accounts alike.

MFA usually checks identity only at the moment of sign-in. After a successful sign-in, the site gives the browser a session cookie, and every later request relies on that cookie to prove "this person has already been verified". An attacker who imports the cookie into their own browser looks to the site like a signed-in user, and is not asked for a password or MFA again. MITRE ATT&CK tracks this as T1539, Steal Web Session Cookie, and notes that it can bypass some MFA mechanisms[2]. Google acknowledges that there is no reliable way to stop cookies from being exfiltrated using software alone, on any operating system[3].

The outcome is the same as the AiTM phishing described in the MFA guide: the session is stolen. The difference is that AiTM intercepts the session during sign-in, while an infostealer lifts it afterwards from the user's own computer. MITRE notes that FIDO hardware keys, which build the sign-in domain into the authentication exchange, prevent cookies from being captured by a proxy during sign-in[2]. But phishing-resistant MFA protects the sign-in, not the cookie that sits on the computer after it. That part needs the session binding and device controls covered later.

How infections happen: fake CAPTCHAs, cracked software, and the PC at home

Common infection routes

The joint FBI and CISA advisory on LummaC2 from May 2025, together with Microsoft's analysis, lists these main routes[4][1]:

  • Fake CAPTCHA pages (ClickFix): the page shows an "I'm not a robot" check, and clicking it silently copies a malicious command to the clipboard. The page then tells the user to press Windows + R to open the Run dialog, paste with Ctrl + V and press Enter, which runs a Base64-encoded PowerShell command[4][1]. Microsoft has seen these pages injected into legitimate websites that had been compromised[1].
  • Malvertising and fake download sites: fake search ads target queries such as "Notepad++ download" or "Chrome update" and lead to clones of the vendor's site[1].
  • Pirated and cracked software: cracked copies of legitimate applications are bundled with the malware and shared on file-sharing platforms; installation looks normal and the malware runs silently after launch[1]. Bitdefender notes that victims often dismiss security warnings as a normal side effect of cracked software[5].
  • Phishing email and fake software: links or attachments in spearphishing emails, or installers disguised as popular media players and utilities[4].

The FBI and CISA also warn that LummaC2's obfuscation lets it slip past EDR and antivirus products designed to flag common phishing and drive-by downloads[4], so endpoint detection cannot be the only line of defense. ClickFix leaves a trace in the history of the Windows Run dialog (the RunMRU registry key), and Microsoft's published hunting query looks there for entries containing strings such as powershell and mshta[1]. Any company with EDR or registry logging can run the same check.

The same kind of threat shows up in Taiwan. The July 2026 monthly cybersecurity report from the Administration for Cyber Security (Ministry of Digital Affairs) says analysis of government joint-defense threat intelligence found attackers spreading LxBase RAT through malicious email. It is an information-stealing remote access trojan that takes browser data, digital wallets and social media passwords, and can download further malware[6].

Personal computers and synced browser profiles

Infostealers often succeed on machines the company does not manage. Verizon's 2025 Data Breach Investigations Report (DBIR) analyzed stealer logs and estimated that about 30% of the compromised systems could be identified as enterprise-licensed devices. Of the compromised systems that had corporate logins in their data, 46% were non-managed and held both personal and business credentials, which the report attributes most likely to BYOD or to company devices used outside policy[7].

Browser sync makes this harder to see. Okta's customer support system was accessed without authorization between 28 September and 17 October 2023, affecting files tied to 134 customers, some of them HAR files containing session tokens that could be used to hijack sessions[8]. Okta's root cause analysis found that an employee had signed in to a personal Google profile in Chrome on an Okta-managed laptop, and that the credentials of a service account had been saved into that personal Google account. Okta judged the most likely route of exposure to be a compromise of the personal account or of the employee's personal device, and afterwards used a Chrome Enterprise setting to stop managed laptops from signing in to Chrome with personal Google profiles[8]. The reverse works the same way: an employee who signs in to the same browser profile on a home PC syncs the work credentials there, and if that PC is infected, the company is exposed.

The stealer log market and two real cases

Malware as a service

Infostealers are mostly sold as malware-as-a-service (MaaS). Microsoft's Digital Crimes Unit (DCU) says Lumma has been sold on underground forums since at least 2022, with its developer offering tiered plans through Telegram and Russian-language forums. Buyers can build their own versions of the malware, add concealment and distribution tools, and track stolen data through a web portal; in a November 2023 interview the developer claimed about 400 active clients[9]. Microsoft has also seen ransomware groups such as Octo Tempest use Lumma in their campaigns[1].

The stolen data is packaged into "logs" and resold. The FBI and CISA cite industry figures showing more than 21,000 market listings selling LummaC2 logs on multiple criminal forums from April to June 2024, a 71.7% increase on the same period a year earlier[4].

How stealer logs differ from old combolists

The combolists that used to dominate were mostly compiled from one website's database breach, so the risk to a company came from employees reusing the same password across sites. Stealer logs are taken straight from the victim's own computer. Troy Hunt, who runs Have I Been Pwned, explains that each entry ties together a URL, an email address and a password, so the logs include services that were never breached at all[10]. If your VPN portal, cloud console or SSO URL shows up in a log, someone signed in to it from an infected computer: an employee, a contractor or possibly a customer. Add the cookies from the same machine, and the attacker may hold ready-to-use access.

These logs overlap clearly with ransomware incidents. Verizon matched the victims named by ransomware groups in 2024 against stealer logs and marketplace postings, and found that 54% of the victims had their domains in that data and 40% had corporate email addresses in it. The report suggests these credentials could have been used in the breaches and points to possible involvement of initial access brokers[7].

Case: the 2024 Snowflake customer data theft

In April 2024 Mandiant received threat intelligence about leaked database records, traced them to one company's Snowflake instance, and went on to uncover a data theft and extortion campaign against Snowflake customers, tracked as UNC5537[11]. The key points:

  • Mandiant and Snowflake notified about 165 potentially exposed organizations. The investigation found no evidence of a breach of Snowflake's own enterprise environment; every incident Mandiant handled traced back to compromised customer credentials[11].
  • Most of the credentials came from historical infostealer infections, involving families including VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER. At least 79.7% of the accounts used had prior credential exposure, and the earliest infection dated back to November 2020[11].
  • Three conditions made it work: the accounts had no MFA; credentials from stealer logs were still valid years later, in many cases unchanged for as long as four years; and there were no network allow lists limiting access to trusted locations[11].
  • In several cases the initial infection was on contractor computers that were also used for gaming and downloading pirated software[11].
  • After exporting large volumes of data, the attackers extorted many victims directly and tried to sell the data on criminal forums[11].

These accounts lacked even MFA, the most basic gap. But the case shows how long stealer logs stay useful: if the password is never changed, an infection from years ago still works.

After a takedown: the Lumma example

On 13 May 2025 Microsoft's DCU filed a legal action in the US District Court for the Northern District of Georgia and, under a court order, seized, took down or blocked about 2,300 domains that formed Lumma's infrastructure. The US Department of Justice seized Lumma's central command structure and disrupted the markets where it was sold, while Europol's European Cybercrime Centre (EC3) and Japan's JC3 helped act against local infrastructure[9]. Microsoft counted more than 394,000 Windows computers infected with Lumma worldwide between 16 March and 16 May 2025[9].

The takedown did not make it go away. Bitdefender reported in February 2026 that Lumma's operators had moved to bulletproof hosting providers that cooperate less with law enforcement, and that Lumma was again spreading at scale through loaders such as CastleLoader and through fake CAPTCHA pages[5]. For a company, law enforcement action buys some time but cannot be part of the defense plan. And Lumma is not the only family: the Snowflake case alone involved at least six.

After a notification that your domain is in stealer logs

First, work out the exposure

Notifications can come from security vendors, threat intelligence services or law enforcement, and you can also check yourself. Have I Been Pwned's domain search first requires you to verify that you control the domain. Stealer log data can be queried by email domain or by website domain, but it needs a paid subscription and returns only domains and email addresses, never passwords[12]. When evaluating a commercial intelligence service, the question is whether it can tell you which account, which URL, when the infection happened, and whether the victim device belongs to the company. Once you have the data, sort it:

  • An email address on your domain appears in a log: some computer this person used is infected. It is not necessarily a company computer, and the same log may hold their personal accounts too.
  • One of your URLs appears in a log: for example your VPN, SSO or customer portal. Someone signed in to it from an infected computer, whether an employee, a contractor or a customer.
  • Match the infected computer: stealers such as Lumma also collect system details like OS version, locale and installed applications[1], which you can match against your asset inventory to find the machine.

Response steps

Once you confirm that an account or device appears in stealer logs, work through these steps in order:

  1. Deal with the infected device first: isolate a company computer and rebuild it, rather than running one antivirus scan and putting it back into service. Infostealers often arrive with other malware; the LxBase RAT mentioned by the Administration for Cyber Security can download further malware[6], and Microsoft has seen Lumma bundled with XWorm in the same executable[1]. For a personal computer, ask the owner to rebuild it and block it from company resources until they have.
  2. Reset passwords from a clean device: not just the work account, but every password saved in that browser, including personal accounts that are also used to sign in to company services.
  3. Revoke all sessions and refresh tokens: changing the password does not necessarily invalidate cookies that have already been stolen. For how to do this in Microsoft 365 and Google Workspace, see Compromised company email account: response steps; sessions in your VPN, SaaS and internal systems need revoking too.
  4. Rotate keys and tokens found on the computer: API keys, cloud CLI credentials, SSH keys, VPN profiles, and passwords stored in FTP and email clients. Lumma collects VPN configuration files, FTP and email client data and user documents[1], and the Snowflake case shows that unchanged credentials stay valid for years[11].
  5. Check whether the account was tampered with: new MFA methods, inbox rules and forwarding, and app consents the user granted. See Compromised company email account: response steps for how to check.
  6. Review the logs: from the infection date onwards, look for access to these accounts from unfamiliar IP addresses or devices. MITRE recommends watching for impossible travel and other signs of replayed sessions[2]. For how long logs should be kept, see What to log and how long to keep it.

If you already see the attacker active in your environment, switch to The first 24 hours of a suspected breach. If you lack the people to handle it internally, consider incident response services.

Prevention: make stolen data useless

  • Stop browsers from saving passwords: turn off the browser's built-in password saving by policy and use a company-managed password manager instead; for choosing and rolling one out, see Password policy and password managers. With Microsoft Edge's PasswordManagerEnabled policy, for example, disabling it stops users from saving new passwords, but previously saved passwords can still be used[13]. So also have users move the passwords they still need into the password manager and then clear the old ones from the browser. At the same time, block signing in to personal accounts and syncing in browsers on company computers, which is exactly what Okta did afterwards[8].
  • Phishing-resistant MFA: in the Snowflake case, MFA alone would have stopped a password-only sign-in. The FBI, CISA and Microsoft all recommend phishing-resistant MFA[4][1]; for rollout order, see the MFA rollout guide.
  • Session binding (Microsoft): to make a stolen cookie useless, the session has to be bound to the original device. Microsoft Entra Token Protection is a Conditional Access session control that accepts only sign-in session tokens bound to the device. It can currently be enforced for native applications accessing Exchange Online, SharePoint Online and Teams on Windows and on MDM-managed Apple devices, while support for web applications in the browser is still in preview and limited to selected apps that access Azure Resource Manager[14]. In other words, browser sessions such as Outlook on the web are not yet covered.
  • Session binding (Google): Google made Device Bound Session Credentials (DBSC) publicly available in Chrome on Windows in April 2026, with macOS to follow in a later release. It uses hardware such as the TPM to create a key that cannot be exported, and the server issues new short-lived cookies only when the browser proves it holds the private key; other websites, however, have to add their own registration and refresh endpoints on the backend[3]. Google accounts already use it: DBSC is being enabled by default for Google Workspace accounts in Chrome on Windows in a gradual rollout that started on 25 May 2026 and may take up to 60 days, with no admin control to turn it off. Personal Google accounts are covered too, and admins can see binding events in the security investigation tool's audit logs[15]. Token Protection and DBSC both cover only some applications and platforms for now. Turn them on where they are supported, but they cannot yet replace the other controls.
  • Require compliant devices in Conditional Access: MITRE recommends Conditional Access policies that allow sign-ins only from trusted devices, such as those enrolled in Intune or joined to Entra, so stolen tokens cannot be reused on unauthorized devices[2]. Microsoft also warns that Token Protection currently covers only Windows and Apple devices and that attackers may pose as another platform to get around it, so pair it with policies that block unknown platforms and require device compliance on all known platforms[16]. For core systems such as databases and cloud consoles, add network location allow lists as well[11]. This also keeps company accounts off unmanaged home PCs.
  • Shorten session lifetimes: MITRE recommends shortening how long cookies stay valid, or regularly deleting persistent cookies[2], which shortens how long a stolen cookie can be used.
  • Application control and EDR: the FBI and CISA recommend application allowlisting; properly configured, it blocks any program not on the list, including portable executables, which antivirus may miss when they are compressed, encrypted or obfuscated[4]. Microsoft recommends running EDR in block mode and enabling attack surface reduction (ASR) rules, such as blocking executables that do not meet prevalence, age or trusted-list criteria and blocking potentially obfuscated scripts[1].
  • Make one point clear in awareness training: no genuine verification page asks you to press Windows + R and paste a command. Put real screenshots of fake CAPTCHA pages, fake download sites and cracked software into the training material.

Action checklist

  • Check your company domain's exposure in Have I Been Pwned or a similar service, and decide who handles stealer log notifications.
  • Write the response order into a procedure: rebuild the device, reset every saved password from a clean device, revoke sessions, rotate keys and tokens, check MFA methods and mailbox rules.
  • Turn off built-in browser password saving by policy, clear existing saved passwords, and move to a company-managed password manager.
  • Block signing in to personal accounts and syncing in browsers on company computers, and allow company accounts only on compliant devices.
  • Move administrator, remote access and cloud data platform accounts to phishing-resistant MFA first, and restrict which network locations can connect.
  • Assess which applications in your environment Entra Token Protection and Chrome DBSC can cover, and enable them where supported.
  • Deploy application allowlisting, or at least run EDR in block mode, and explicitly ban cracked software in company policy.
  • Use RunMRU records to check whether anyone has followed a fake CAPTCHA's instructions, and add this technique to security awareness training.
  • Include contractors and outsourced staff: require managed devices, or at least narrow what their accounts can reach.