The report usually comes in one of two ways: a client says odd emails are going out from someone's mailbox that they didn't send, or a user admits — often sheepishly, after the fact — that they entered their credentials on a page that turned out to be fake. Either way, you're now running an incident, not a ticket, and the first hour matters more than any hour that follows it. Details below are generic on purpose; treat this as the sequence, not a transcript of any one case.
The order here isn't arbitrary. Each step either closes a door the next step needs closed, or depends on evidence the previous step hasn't yet destroyed. Do them out of order and you'll either let the attacker keep working while you investigate, or wipe out the logs you needed to investigate with in the first place.
1. Contain — cut off access before you do anything else
Before you look at a single log entry, stop the attacker from continuing to act as the user:
- Reset the password. Necessary, but not sufficient on its own — see the FAQ below on why.
- Revoke active sessions and refresh tokens. This is the step that actually ends any session the attacker already has open. A password reset alone doesn't do this; a previously issued token can keep working until it's explicitly revoked.
- Block sign-in for the account while you investigate. Temporarily disabling sign-in stops any new authentication attempt — including one using a token you haven't found and revoked yet — while you work through the rest of this list.
Do this first because everything after it — checking for persistence, reading logs, assessing what was sent — is more trustworthy once you know the attacker can't act in the account anymore while you're looking at it.
2. Check for persistence — a password reset doesn't remove what the attacker added
This is the step people skip, and it's the reason accounts get "fixed" and then compromised again a week later. While they had access, an attacker routinely leaves themselves a way back in that survives a password change entirely:
- Malicious inbox rules. Look for rules that auto-forward mail to an external address, or that silently delete replies — a common pattern is a rule that moves any message containing words like "hacked," "phishing," or "suspicious" straight to Deleted Items or RSS Feeds, so the compromise stays invisible to the user for as long as possible.
- Added MFA methods. Check whether a new phone number, authenticator app, or verification method was registered during the compromise window. If so, remove it — otherwise the attacker can re-authenticate with their own second factor even after the password's been reset.
- OAuth app consents. Review what third-party applications the account has granted permissions to. A phishing page that harvests a password is one thing; a phishing flow that tricks a user into approving an OAuth consent prompt hands the attacker a token that doesn't care about password resets at all.
- Mailbox delegates. Check for any delegate access added to the mailbox that the user didn't set up themselves.
Do this before you move on to investigating, because any of these left in place means the "incident" isn't actually over — it just went quiet.
3. Investigate — find out where the attacker actually came from
With the account contained and cleaned of persistence, review the sign-in logs for the compromise window and pull out the IP address (or addresses) the attacker authenticated from.
Run each one through IP Lookup and ASN Lookup — the same pair of tools covered in Investigating a Suspicious IP Address and the VPN/proxy detection guide. You're asking the same question either way: does this IP belong to a data center, hosting provider, or VPN/proxy service, or does it look like ordinary residential or business connectivity in a plausible location for this user? An authentication from a hosting provider's IP block, or from a country the user has no business connection to, is a strong signal you're looking at the attacker's actual point of access rather than something explainable.
This step comes after containment and persistence cleanup on purpose — you want a clean read on what happened during the compromise window, without new sign-in attempts from a still-active attacker muddying the log while you're trying to read it.
4. Assess damage — what actually went out, and to whom
Now that you know the window and the source, work out the blast radius:
- What was sent. Pull the messages that actually went out from the account during the compromise window — subject lines, recipient count, and whether it's the same phishing template repeated at scale (which is the common pattern) or something more targeted.
- Who received it. Get the actual recipient list. You'll need it for the next step, and a client will reasonably ask.
- Whether anything sensitive was accessed, not just sent. Check whether the attacker opened or downloaded anything from the mailbox itself — attachments, saved credentials, anything that reads as sensitive — separately from what they sent out. Sending phishing emails and reading the mailbox's contents are two different outcomes with different follow-up.
5. Notify — warn the people the account was used against
Once you know who received the phishing emails, tell them — a short, plain message that the sender's account was compromised, the message they received wasn't legitimate, and they shouldn't click anything in it or enter credentials if they already have. Speed matters here more than polish; a same-day heads-up to 50 people who got a phishing email from a trusted contact is genuinely useful, and it's also the professional, expected response once a compromise is confirmed.
6. Recover and harden — close the door for next time
With the immediate incident handled, put in place what would have prevented it or shortened it:
- Enforce MFA if it isn't already required. If the account didn't have MFA enforced, this is the single highest-leverage change available.
- Conditional access policies. Where the client's licensing supports it, restrict sign-in by location or device compliance so a stolen password alone isn't enough from an arbitrary location.
- User awareness follow-up. Not as a blame exercise — as a practical debrief. If this started with a QR code, walk the user through Why Email Filters Miss QR Code Phishing so they understand why the filter didn't catch it and what to actually look for next time.
Talking to the client or their leadership
The instinct under pressure is to either downplay it or spiral into worst-case language. Neither helps:
- Lead with status, not narrative. "The account is contained, we found and removed how they were staying in, and we're now working out who else was affected" tells a client exactly where things stand without making them relive the discovery.
- Explain mechanism plainly, the same way you would a filter miss. "The password alone wasn't enough to lock them out because they had a still-valid session — that's why we revoked sessions as a separate step" gives a client something concrete, not just reassurance.
- Don't promise a damage scope before you actually have one. "We're still confirming exactly what was accessed, and we'll have a clear answer by [time]" is more trustworthy than guessing early and having to walk it back.
Where this checklist ends and legal/compliance advice begins
This is a technical response sequence, not legal or compliance guidance, and it isn't a substitute for either. Notifying the people who received phishing emails from the account is always appropriate and covered above — but some clients, depending on what data the mailbox held and what jurisdiction they operate in, may have formal breach-notification obligations that go beyond that. Recognizing that possibility is part of this job; deciding how to act on it isn't something to improvise. Loop in the client's legal counsel or cyber insurance carrier for that call rather than guessing.
Bookmark this page — it's built to be the reference you pull up in the first five minutes of a compromised-mailbox call, not something you read for the first time during one.