Infostealers: how employee passwords end up in leak logs

An infostealer is malicious software that steals data from an infected device. Depending on the malware, that can include saved passwords, the session cookies that keep a person signed in, payment details and documents; this article follows the browser data, because browsers can store work passwords and the sessions that keep someone signed in. The malware sends what it takes to the attacker as a package called a stealer log. On an employee's computer, that log can hold working logins to company systems anyone can reach from the internet.

That makes it one of the ways a work password is stolen without the attacker ever entering the company's internal network. One person installs a cracked program or opens a fake invoice on a laptop they also use for work. The stealer can copy what the browser has saved. Nothing on the company's own network has to change.

What an infostealer takes

Browsers save logins so that people do not have to type them again. MITRE ATT&CK, the public catalog of attacker techniques, describes how malware reads those files: "Web browsers commonly save credentials such as website usernames and passwords so that they do not need to be entered manually in the future" (T1555.003).

A joint advisory by the FBI and CISA on the LummaC2 stealer was published on May 21, 2025. It lists what the malware goes after: "personally identifiable information, financial credentials, cryptocurrency wallets, browser extensions, and multifactor authentication (MFA) details" (CISA AA25-141B). A log from a work laptop can therefore include:

• saved logins, each with the site address, username and password;
• session cookies, which keep someone signed in without a password;
• autofill data such as names, addresses and card details;
• details of the computer itself, such as its operating system and installed software.

For a sense of scale: on May 21, 2025, the same day as the advisory, Microsoft said it had identified over 394,000 Windows computers infected by Lumma between March 16 and May 16, 2025. It also said it had helped seize, take down, suspend or block about 2,300 malicious domains used by the malware (Microsoft).

How infostealers get onto a computer

The FBI and CISA advisory describes several routes: "spearphishing hyperlinks and attachments"; malware hidden "within spoofed or fake popular software (i.e., multimedia player or utility software)"; and fake CAPTCHA checks, where the page tells the visitor to open the Windows Run box and paste what it has put on the clipboard, which runs the installer. In practice that looks like a free video tool from the wrong website, a cracked copy of a paid program, an attachment that claims to be an invoice, or a "prove you are human" page that asks you to run something.

The computer may not be one the company manages. In several of the Snowflake investigations described below, Mandiant found that the first infection happened on contractor systems "that were also used for personal activities, including gaming and downloads of pirated software". An employee may also check work email or the company's remote-access portal (VPN) from a home laptop the family shares. The company's security tools may have no view of such a machine, but the passwords saved on it open company doors.

Compromised credentials: what an attacker does with a log

Stolen logs are traded. Mandiant describes an underground infostealer economy in which "large lists of stolen credentials exist both for free and for purchase". Whoever holds the compromised credentials in a log can use them in several ways.

• Sign in directly wherever a password alone is enough: webmail, a VPN portal, a software-as-a-service admin panel, a cloud console.
• Reuse a session cookie. MITRE describes attackers using stolen session cookies "to gain access to web applications or Internet services as an authenticated user without needing credentials" (T1539). MITRE also notes that a stolen session cookie can let an attacker past some multi-factor authentication checks.
• Try the same password elsewhere, which is the next section.

A leaked password can matter most on a login page that nobody remembers is online. Our piece on reconciling the declared and the actual perimeter shows how such pages turn up; a forgotten self-hosted Gitea server is one example.

Credential stuffing: one password, many doors

Credential stuffing is the automated testing of stolen username and password pairs against other services, betting that people reuse passwords. MITRE's definition: adversaries "may use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts through credential overlap" (T1110.004). A password reused between a personal shopping account and a work login puts a second account at risk.

A login system can screen for this in part. NIST SP 800-63B, Revision 4, finalized on July 31, 2025, requires that when a password is set or changed, the system that checks it "SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords" (section 3.1.1.2, NIST). That screening rejects the passwords on the blocklist; it does not tell you whether an employee reused a work password on another service.

The 2024 Snowflake campaign: infostealer credentials and no MFA

On June 10, 2024, Mandiant, part of Google Cloud, published its investigation of a group it tracks as UNC5537. The group had accessed many organizations' Snowflake customer accounts with stolen credentials, "primarily obtained from multiple infostealer malware campaigns that infected non-Snowflake owned systems". The earliest infection linked to a credential used dated back to November 2020. Some credentials were "still valid, in some cases years after they were stolen". About 165 potentially exposed organizations were notified (Mandiant).

Mandiant found no evidence that this access stemmed from a breach of Snowflake's enterprise environment. It named three factors instead: the affected accounts had no multi-factor authentication, the stolen credentials had not been rotated, and there were no network allow lists limiting access to trusted locations.

How to reduce the risk from infostealers and credential stuffing

None of these is complete on its own. Together they make a stolen log much less useful.

• Phishing-resistant multi-factor authentication on the systems reachable from the internet, which the FBI and CISA advisory recommends: a password plus a FIDO2 security key, or a passkey unlocked with a PIN or fingerprint, rather than codes sent by text message. Then a password alone is not enough to sign in. This protects the sign-in; it does not remove the need to secure the devices themselves and to revoke stolen sessions.
• End sessions, not only passwords. When a device is found infected, reset its passwords from a trusted device and revoke its active sessions in each affected service. A stolen session cookie can outlive a password change.
• Check passwords against known leaks when they are set or changed, as NIST asks of login systems.
• Keep work logins on managed devices where you can, and control which software can run on them; application control is among the advisory's mitigations.
• Limit where the most sensitive systems accept logins from. Mandiant pointed to missing network allow lists for "crown jewels".
• Monitor for leaked company credentials, so your team can reset them and investigate.

Data leak monitoring: what it can show, and what it cannot

SeguriScan, IntruForce's attack surface monitoring and data leak detection platform, checks the websites and systems your company exposes to the internet and looks for company data and work passwords exposed in leaks. It brings both into one place, which helps your team find the affected accounts and decide which passwords to reset first.

It has limits worth stating. A leak finding alone cannot show whether a device is infected right now, or whether a stolen session is in use. Leak monitoring can only find what has surfaced in the sources it checks, so finding nothing does not prove the credentials are safe. And what a finding means depends on what it contains: an exposed password still used by an active account calls for a reset and for ending that account's sessions, while an email address appearing in a leaked dataset does not by itself show that a password was stolen.

What to do when a work password turns up in a leak

1. If a device may be infected, disconnect it from the network and tell IT or your provider. Ask them to preserve what an investigation needs before cleaning or reinstalling it. A leaked password on its own may not identify the device.
2. Reset the exposed password from a trusted device, then follow each service's procedure to end sessions and revoke refresh tokens. Check when existing access tokens stop working: it may not be immediate.
3. Review the available sign-in and account-change logs, including activity from before the reported leak date.
4. Ask whether the same password was used anywhere else, at work or outside it, and change it there too.
5. Turn on multi-factor authentication for the account if it was missing.

To ask which company accounts and internet-facing systems can be seen from outside, use Check My Company at the end of this page, or on its own page. It is a request to the IntruForce team, answered by email. Nothing that interacts with your systems runs without your confirmation.