The alert says an employee's work email and password appeared in a stealer log yesterday. What happens in the next 24 hours decides whether this is a routine password reset or the start of a breach report. This is the playbook.
Hour 0 to 1: triage
Read the alert carefully. The three details that set your priority:
- Is the password in cleartext? A cleartext password means the credential can be used right now. A hash from an old breach is lower priority.
- How recent is the source? A stealer log from this week implies an infected device, which is a second incident on top of the leaked password. A 2017 breach dump is historical.
- Who is the user? An administrator, an executive or someone in finance raises the stakes immediately.
Check whether the leaked password is the user's current password or one they still use elsewhere at work. If you cannot be sure, treat it as current.
Hour 1 to 4: contain
- Reset the password on the primary identity (Microsoft 365, Google Workspace or your directory) and on any system where the user may have reused it: VPN, admin panels, SaaS tools.
- Revoke active sessions and tokens. Stealer logs include browser cookies. A reset alone does not log the attacker out of a session that is already open. Use your identity provider's "sign out everywhere" function.
- Enforce MFA on the account if it was not already enabled, and verify the registered MFA methods have not been changed.
- Check for persistence. Look for new mailbox forwarding rules, new OAuth app consents and new MFA devices. Attackers set these up within minutes of a successful login.
- If the source is a stealer log, isolate the device. The user's PC is likely infected. Take it off the network and reimage it; do not rely on an antivirus scan alone. Every password saved in that browser should be treated as compromised.
Hour 4 to 12: investigate
- Pull sign-in logs for the account for the period since the leak date. Look for unfamiliar locations, impossible travel and sign-ins at unusual hours.
- Check sent items and deleted items for messages the user did not write. Business email compromise often starts with a quiet reconnaissance phase.
- Review what the account had access to: shared drives, finance systems, customer data. This determines whether you have a reportable incident.
- Search the rest of the leak. If one employee is in a combolist, colleagues often are too. Run a fresh dark web scan across the whole domain.
Hour 12 to 24: communicate and decide
- Inform the user about what happened and what to do with personal accounts that shared the password.
- Inform management with a short summary: what leaked, what was accessed (or that nothing was, with evidence), what was done.
- Assess reporting obligations. If there is evidence of unauthorised access to personal data, GDPR's 72-hour clock may already be running. Under NIS2, a significant incident requires an early warning within 24 hours. When in doubt, involve your DPO or counsel now, not later.
- Record everything: timestamps, actions, evidence. This is the material your auditor, insurer or regulator will ask for.
After 24 hours: prevent the repeat
- Make MFA mandatory for all users, not just the one who was hit.
- Block known-breached passwords at the identity provider so leaked values cannot be reused.
- Ban password reuse between work and personal accounts in policy, and explain why with this incident as the example.
- Keep continuous dark web monitoring running so the next alert arrives on day one, not day ninety.
- Run endpoint checks across the fleet for the malware family involved.
A note on scale
Most of the steps above take a single administrator less than a day. The expensive version of this story is the one where nobody knew about the leak until the attacker used it. Monitoring exists to make sure you are in the first group. If you want to know whether your domain already has exposed credentials, SecurityScanner.AI dark web monitoring will tell you in minutes.