An employee's password is in a stealer log: what to do next

What the finding means

A stealer log is the output of an infostealer: malware that copies what a device has stored and sends it to the attacker. MITRE ATT&CK describes the two techniques at the heart of it, reading credentials from web browsers and stealing web session cookies. In their May 2025 advisory on LummaC2, CISA and the FBI list what one family takes: credentials, cryptocurrency wallets, browser extensions and MFA details.

So the finding is about a device first and a password second. A single log typically contains:

The site address next to each password matters more than it looks. It makes each record a ready ULP list entry (URL, login, password) that a buyer can use without guessing. Our analysis of login paths in stolen credentials shows how those addresses also name the supplier portals and internal systems a company relies on.

The response at a glance

The order follows one rule: nothing new should be typed on a device that may still be infected, and nothing stolen should stay valid longer than it has to.

First hour: contain the device, end the sessions, change the main password

1. Take the device out of use. If the log names a corporate laptop, isolate it with your endpoint tool or take it off the network. If the employee's personal computer is the source, ask them to stop using it for work and for anything sensitive. Do not ask them to change passwords on it: a password typed on an infected machine can be stolen again.

2. End the sessions. A stolen session cookie lets the attacker skip both the password and the MFA step. Microsoft's token theft playbook puts it plainly: tokens are replayed after the user "has satisfied multifactor authentication", so the attacker is let in. That is why changing the password is not enough on its own:

• Microsoft Entra ID: revoke the user's sessions, which revokes their refresh tokens (Revoke-MgUserSignInSession). Microsoft notes that access tokens already issued can stay valid for their typical one-hour lifespan, except in applications that support Continuous Access Evaluation.
• Google Workspace: after resetting a user's password, Google says you should also reset the user's sign-in cookies. Google adds that this does not sign the user out of apps such as Gmail and Google Drive for desktop, so check those separately.
• Okta: use Clear user sessions in the Admin Console, which clears active sessions and can revoke the OAuth and OpenID Connect tokens issued to the user.

Single sign-on helps here: ending the session at the identity provider cuts off every app that depends on it. Apps outside single sign-on keep their own sessions and need the same step one by one.

3. Change the corporate identity password in the same sitting. Do it from a clean device, right after ending the sessions, so the stolen password cannot open a new session. Google's instruction above puts the two steps together for the same reason.

First day: change passwords and rotate secrets

4. Change the remaining passwords, from a clean device. Start with the mailbox if it has its own password, because it resets everything else. Then work through every corporate address in the log. NIST's current password guidance, SP 800-63B-4, says verifiers "SHALL force a change if there is evidence that the authenticator has been compromised". A stealer log is that evidence.

5. Do not stop at corporate accounts. The same log holds the employee's private passwords. Any of them reused at work is a way back in through credential stuffing. Help the employee change the reused ones and move away from storing passwords in the browser.

6. Rotate what is not a password. A developer's log can also hold API keys, cloud credentials and access tokens for code hosting. Revoke them with the service that issued them, then replace them. The poisoned LiteLLM release of Black October is a recent example of stealer code going after exactly those keys.

7. Check the third parties in the log. Supplier portals, payment platforms and partner systems listed in the log need the same treatment. Where the account belongs to a supplier's system, tell the supplier.

First week: find out whether it was used

8. Review activity back to the infection date. The device details in the log often show when the theft happened, and the record may have circulated for weeks before you saw it. From that date on, look for:

• sign-ins from new locations, devices or networks, and sign-ins that reuse a session without a fresh MFA prompt;
• new MFA methods, app passwords or recovery addresses added to the account;
• new mailbox forwarding rules and OAuth applications granted access;
• downloads, sharing changes and new tokens in the systems the employee could reach.

If you find use, this is an incident, not a hygiene task: widen the scope to the systems that account could reach, and follow your incident response plan.

9. Clean or reimage the device. Microsoft's playbook lists "Remediate infected devices" as a step of its own, next to revoking tokens and resetting passwords. For a personal device, the UK's National Cyber Security Centre advises wiping it and reinstalling everything, starting with the operating system, if security software cannot clean it, and warns that copying data off an infected device can carry the infection over.

When the device is personal

Often the source is a device your company does not manage. In Verizon's 2025 Data Breach Investigations Report, 30% of the compromised systems in the infostealer logs analysed were enterprise-licensed devices, and 46% of the compromised systems that had corporate logins were non-managed, holding both personal and business credentials. Verizon says these are most likely devices in a bring-your-own-device program or company devices used outside policy.

That changes the response. You cannot reimage a personal laptop, and your endpoint tools never saw the infection. What you can control is the corporate side: end the sessions, change the corporate passwords from a managed device, and decide whether this person keeps access from personal hardware. The employee needs help with the rest, including their private accounts and banking, and without blame: one bad download is enough, and it can happen to anyone.

Why the same log keeps coming back

A stealer log is a product. It is sold or shared in Telegram channels and on dark web marketplaces, resold in bulk, and folded into combolists and leak databases. Our look at Telegram clouds found sellers advertising "fresh" or "private" logs that were recycled and renamed copies of older ones. So a finding may be new to you and old to the market, and the same credentials can turn up again under a different name. Our overview of how stolen data is sold follows that route from the theft to the buyer, and combolists vs stealer logs vs database dumps explains what each kind of leak contains.

The scale explains why this is routine rather than rare:

These counts come from different collections and cannot be added up. Takedowns slow one family down; the logs already stolen stay in circulation.

Prevent the next one

• Keep work on managed devices. Conditional access that requires a compliant device keeps corporate sign-ins off personal laptops, so a stealer on one of them finds fewer work credentials.
• Stop storing work passwords in the browser. The browser's own password store is the first place a stealer reads. A password manager keeps credentials out of it.
• Bind sessions to the device. Chrome added App-Bound Encryption for cookies on Windows in July 2024, and in April 2026 Google made Device Bound Session Credentials publicly available for Chrome on Windows, with macOS announced. Websites have to adopt DBSC for it to protect their sessions. In Microsoft Entra, Token Protection binds sign-in tokens to the registered device; native apps on Windows, macOS and iOS are covered, browser sign-ins only in a limited preview.
• Shorten the window. Shorter session lifetimes for sensitive apps and Continuous Access Evaluation where it is supported reduce how long a stolen session works.
• Train for how stealers arrive. Teach people to treat unexpected downloads, cracked software and prompts that ask them to run a command with suspicion.

What a stealer log cannot tell you

A log shows what was on the device when the malware ran. It does not show whether anyone has used it, whether the password is still valid, or whether the same device was infected again later. Logs are also traded, merged and relabeled, so the date a log was posted is not the date the device was infected. Treat the device details in the log as the best evidence of timing, and your own sign-in records as the evidence of use.

If the person in the log is an executive, the same steps apply with a shorter fuse: their accounts reach more and are targeted more. For a password that leaked in a breach of a service rather than from a device, see what to do when an executive's password is in a breach.

How WebThreat can help

WebThreat does not clean devices or run your identity provider; the steps above belong to your IT and security teams. Our part is the data that has already left.

• EDG3 is WebThreat's threat intelligence for leaked data. It watches the places where stealer logs are posted and sold: dark web forums and marketplaces, Telegram and other channels, and leak databases. For a domain you have authorized, it shows what has been posted about your company, where and by whom, and links reposted copies of a leak back to its first post while keeping the provenance of each. An EDG3 briefing with a threat intelligence analyst walks through what is out there for your domain, with every finding tied to its source.
• CEM looks at your leadership team. It finds the executives from your company name and checks their current and past email addresses against breach corpora and leak databases. It does not read stealer logs or session tokens; for those, EDG3 is the right tool.

If an employee's credentials have turned up in a stealer log and you want to know what else about your company is circulating, book an EDG3 briefing or contact us.

This article reflects the vendor documentation and reports linked above as of 25 October 2026. Identity provider settings change; the vendor pages are the authority for the exact steps.