To triage a leaked password alert, first check that the alert is real, then work out whether the password came from an old breach or from malware on a device. Reset the password, end all open sessions, review the sign-in logs and mail forwarding rules, and tell the user. Malware leaks are more urgent, because a stolen session cookie can let an attacker skip the second factor.
A leaked password alert tells you that a password linked to your company showed up somewhere it should not be, such as a criminal forum or a data dump. It does not always mean someone has broken in. It means you have a decision to make, and the sooner you make it, the better.
Most alerts come from two sources: old breaches at other websites, and password-stealing malware. This malware, often called an infostealer, runs on a person’s device and copies saved passwords and browser sessions. Good dark web monitoring finds both kinds, so your team needs a quick way to tell them apart.
How do you check that a leaked password alert is real?
Before you act, spend a few minutes on three checks.
- Does the account exist in your systems, and is it still active?
- Is the password in the alert in a format you use? A password that could never pass your rules is probably not yours.
- How old is the source? A leak from years ago is lower risk than one from this week.
Work out how it leaked
The way a password leaked decides how fast you need to move.
Third-party breach
The person used their work email and password on another website, and that website was breached. The risk is real if they reuse passwords, but nothing was taken from your own systems.
Malware on a device
This is the more urgent case. Infostealers copy session cookies as well as passwords, and a cookie can let an attacker sign in without the password or the second factor. Groups such as APT28 are known to use stolen credentials to get in, so treat a malware leak as a possible intrusion.
- Infostealer runs on a deviceCopies saved passwordsTechnique T1555.003 (MITRE ATT&CK, opens in a new tab)
- Browser sessions copiedSession cookies are taken as wellTechnique T1539 (MITRE ATT&CK, opens in a new tab)
- Attacker signs inA cookie can skip the password and the second factorTechnique T1078 (MITRE ATT&CK, opens in a new tab)
Decide how urgent it is
Use this table as a starting point and adjust it to your own risk.
| Situation | Risk | First action |
|---|---|---|
| Old breach, password already changed | Low | Note it and close the alert |
| Current password, no multi-factor sign-in | High | Reset the password now and turn on multi-factor sign-in |
| Administrator account | Very high | Reset, end all sessions and review recent admin actions |
| Malware log with session cookies | Very high | Isolate the device, then reset and end all sessions |
In what order should you act?
Work through these steps in this order, so you do not leave a door open.
- Reset the password.
- End all open sessions, so a stolen cookie stops working.
- Check the sign-in logs for logins you do not recognize.
- Check for mail forwarding rules. Attackers often add one to keep reading mail. A rule named
Forward all to externalis a typical example. - Tell the user what happened and what to do next.
A sign-in log line that deserves a closer look might read like this:
2026-03-02T03:14:09Z signin success user=user@example.com ip=203.0.113.10 mfa=noneClose the gap
Once the alert is handled, make the next one less likely. Turn on multi-factor sign-in for every account. Give people a password manager so they stop reusing passwords. Keep monitoring running, so you hear about the next leak early.
Treat a leaked password as used until the logs say otherwise.
For more on handling incidents, see the guidance at CISA.