Case: recovering a taken-over mailbox (teaching example)

This is a teaching example, not a report from a real engagement and not a guarantee that your case will look the same. Names and the company are invented. The order of actions is deliberately simple — like the account-takeover emergency card, except here you see decisions and mistakes, not only checkboxes.

Monday, 08:40 — symptoms

Anna runs a B2B supply shop. A wholesaler calls: “We got an email from you about a new bank account for payment. Confirm?”. Anna did not send that email.

In the office@ mailbox:

• a message “sent” at 07:12 with a PDF “account update”,
• in Sent — a few emails she does not remember,
• a Microsoft 365 notice: sign-in from another city at 06:58.

The work phone is on the desk. The mailbox password was “changed in May”. MFA was “to enable someday”.

First 60 minutes — what they did right

1. They did not write from the suspect mailbox to clients “it wasn’t us”. They used the phone and the wholesaler’s known number.
2. They did not “clean reboot” the only laptop with mail — first another trusted phone for the admin panel.
3. They noted the time of the first odd email and the sign-in notice (useful for the bank / insurer / us).
4. They told the wholesaler clearly: hold the transfer, verify on a second channel — as in bank-detail change verification.

Mistakes they avoided (and one they almost made)

They almost clicked a “recover account” link from an SMS that arrived a minute after the wholesaler’s call. The SMS looked like Microsoft. They stopped because the link was not the official domain they knew from the panel. They signed in by typing the panel address from a bookmark, not from the SMS.

What they did not do: send a full mailbox dump to “a friend in IT on Messenger”. Paste passwords into a form “just in case”.

Recovery — decisions, not magic

On a trusted phone:

1. Sign-in to the Microsoft 365 admin account (separate from office@).
2. Sign out / revoke sessions for office@ and force a password change.
3. Enable MFA for the office mailbox and the admin account.
4. Check mailbox rules (forwarding outside) — there was a rule copying mail to a foreign address. Removed.
5. Review OAuth / connected apps — one unknown; permissions revoked.
6. A short note: what, when, who approved cutting access.

Clients with open invoices were notified on a separate channel (phone / known mail on another domain), not from the taken-over mailbox mid-chaos.

Closing — next day

• Passwords changed, sessions cut, MFA on.
• The “suspect” laptop left for review; work on another device.
• List: who else has M365 access, whether office RDP existed, whether mailbox backup exists at all.
• The wholesaler got confirmation on a known channel that the bank account does not change.

If money had already moved — bank on an official number, not from an SMS. Roles: who does what in an incident.

What this case does not promise

It does not promise recovering money. It does not promise “calm in 15 minutes”. It does not replace the emergency card in your case — Anna did not have ransomware or browser session theft; you might (see also session theft).

If you are in a similar moment: first first odd login, then the account-takeover card, then — if you want external triage — a consultation or the SOC / IR form. Phone is temporarily unavailable; the form usually gets a reply within 1 business day.