Employee login in a stealer log? What to do in 24 hours

You've found a staff member's work login in a stealer log. That means malware ran on a computer they use, and it copied their saved passwords, their browser cookies and details about the machine. Someone may already be using it.

This is the response we'd run, in order. Most of it can be done in an hour. The goal for the first 24 hours is to make the stolen data useless, find out whether anyone has used it, and make sure the infected machine can't leak the next password.

First, read the log entry properly

Before you reset anything, take two minutes to understand what leaked. The stealer-log record tells you more than a breach notice would:

• Which logins leaked. The work account, but also any other company systems the person saved in their browser, such as VPN, admin panels, cloud consoles or a customer support tool.
• When the machine was infected. A log from last week means the passwords are almost certainly current. A log from two years ago may have only old ones.
• Which machine it was. The computer name, operating system, IP address and country help you work out whether it's a company device, a personal one or a contractor's.
• Whether cookies were taken. If they were, assume any session that was open on that browser can be reused without a password or MFA prompt.

If you're not sure what a log contains or why the cookies matter, our explainer on stealer logs covers it.

Step 1: Revoke sessions, then reset the password

Order matters here. Changing the password doesn't sign anyone out. An attacker holding a stolen session cookie or refresh token can stay signed in after a reset.

1. Revoke all sessions and tokens for the account in your identity provider, and in any app that keeps its own sessions, such as email, chat and your cloud console.
2. Reset the password to something new and unique. Don't let the person choose a variation of the old one.
3. Reset any other company logins in the log. If their VPN, admin panel or a shared account was saved in the same browser, it's exposed too.
4. Check their MFA methods. Remove any phone number, authenticator or device you don't recognise, and re-enrol MFA if in doubt.

If the account belongs to an administrator or someone with access to production systems or customer data, do all of this now, before the rest of the list.

Step 2: Look for signs it's been used

Next, find out whether you're cleaning up an exposure or an incident. Check the account's activity going back to at least the infection date in the log:

• Sign-ins from new countries, IP addresses, devices or browsers, especially ones that skipped the MFA prompt.
• MFA changes such as new methods added or old ones removed.
• Mailbox rules that forward, delete or hide messages. Attackers use these to watch for invoices and hide security alerts.
• New OAuth apps or API tokens granted access to the account.
• Unusual access to file shares, code repositories, finance systems or customer data.
• Password reset emails for other services arriving in their inbox.

If you find any of this, it's an incident, not a hygiene task. Bring in whoever handles incident response, keep the logs, and widen the search to anything that account could reach.

Step 3: Deal with the infected machine

The stealer ran on a real computer, and that computer may still be infected. If the person signs in to anything from it, the new password can be stolen too.

If it's a company device, take it off the network and have IT investigate. Infostealers often remove themselves after running, but they're sometimes installed alongside other malware. Rebuilding the machine is usually quicker and safer than trying to clean it.

If it's a personal device, you can't manage it, but you can tell the person. Explain plainly that their computer was infected, that personal accounts such as email and banking were exposed too, and that they shouldn't use it for work until it's been wiped and reinstalled. Most people are grateful to be told.

If it's a contractor's or a supplier's device, contact the supplier. Their other staff may be affected, and they may have access to other customers' systems as well as yours.

Ask how the infection happened. Cracked software, game cheats and fake download pages are the usual causes. The answer tells you whether this was one person's mistake or a gap that affects others, such as staff installing their own software.

Step 4: Check for the same person elsewhere

One infected machine often shows up more than once. Search your stealer-log monitoring for:

• The person's other email addresses and usernames.
• The same machine or IP address, which can reveal other people who share that computer.
• Logins to your own websites from the same log, including accounts under personal email addresses.

If the same password appears for other staff, it may be a shared or default password that needs changing everywhere.

Step 5: Close the gap that let it happen

Once the immediate risk is handled, fix the conditions that made the login worth stealing:

• Stop browsers saving work passwords. Use a company password manager and single sign-on instead, and enforce it through browser policy on managed devices.
• Move to phishing-resistant MFA. Passkeys and hardware security keys tie the sign-in to the device, so a stolen password or exported authenticator code is far less useful.
• Shorten session lifetimes for sensitive systems, and bind sessions to the device where your identity provider supports it.
• Restrict access from unmanaged devices. If personal computers can reach your VPN or admin tools, that's where the next infection will come from.
• Monitor continuously. New stealer logs appear every day. Checking your domains weekly, or getting alerted when new results appear, turns this from an annual surprise into a routine task.

A checklist you can copy

• Read the log entry: which logins, when, which machine, whether cookies were taken
• Revoke all sessions and tokens for the account
• Reset the password, and any other company logins in the same log
• Review and re-enrol MFA methods
• Check sign-ins, MFA changes, mailbox rules and new app grants since the infection date
• Escalate to incident response if anything looks used
• Isolate and rebuild the machine, or tell the owner if it's personal
• Search for the same person, machine and password elsewhere
• Fix the root cause: saved passwords, MFA strength, unmanaged access
• Keep monitoring your domains for new logs

Find the next one before it's used

The difference between a near miss and a breach is usually time: how long a stolen login sits in a log before someone acts on it. How to check if your company's logins have been leaked covers setting up regular checks. If you want to see what's already out there for your company, run a free check on your domain.