Changing the password is the obvious move and it is not sufficient on its own. Here is the order to work in, and the four places an attacker leaves a way back that almost nobody checks.
If money has already moved, stop reading and call your bank to request a recall, then file with the FBI at ic3.gov. The recall window is measured in hours. No technical work should delay that call.
The instinct on discovering a compromised Microsoft 365 account is to change the password and get back to work. It is the right first move and it is not the whole job.
A password change closes the front door. It does nothing about the mail rule the attacker created, the third-party app they authorised, the phone number they registered as a recovery method, or the forwarding address quietly copying every message you receive. Any one of those lets them straight back in, and all four survive a password reset.
Do these first, in this order
- Reset the password — and do it from a device you trust, not the one you suspect.
- Revoke all active sessions. Without this, an attacker holding a stolen session token stays signed in even after the password changes.
- Check the account's MFA methods and remove anything you do not recognise. An added authenticator app or phone number is the most common persistence we find.
- Check for mailbox rules, especially any that forward, delete, or move messages to an obscure folder.
- Check mailbox forwarding separately — it is a different setting from mail rules and it is missed constantly.
- Review OAuth app consents and revoke anything unfamiliar. This is how an attacker keeps mailbox access without a password at all.
- Check delegate and mailbox permissions for accounts that should not have them.
The four hiding places almost nobody checks
In order of how often we find them, and every one of them survives a password reset:
- Inbox rules that delete or divert. A rule that moves anything containing the words 'invoice' or 'wire' to RSS Feeds means you stop seeing the conversation the attacker is having with your customers, from your account.
- SMTP forwarding on the mailbox. Set once, it copies everything, indefinitely, and it is not visible in Outlook's rules list.
- OAuth application consent. A user can be tricked into granting an app permission to read mail. That grant is not a password and is unaffected by changing one.
- An extra MFA method. Adding their own authenticator means the attacker can pass MFA on the new password you just set.
Then work out what they actually did
Containment stops the bleeding. It does not tell you what left the building, and that is the question your insurer, your lawyer and possibly a regulator will ask.
The Microsoft 365 unified audit log holds the answer — which messages were read, what was sent, whether files were downloaded, where the sign-ins came from. It is also on a retention clock, and the clock is shorter than most people assume. Capturing it early is the difference between a factual account and a shrug.
What not to do
- Do not delete the mailbox rules before recording them. They are evidence of intent and scope, and a screenshot costs nothing.
- Do not tell staff to ignore it and carry on. If invoices went out from your account, your customers need to know before they pay one.
- Do not assume a single account. Attackers pivot, and the second account is frequently one that shares a password.
- Do not skip telling your insurer because you hope it is minor. Late notification is a common reason cover is refused.
How this usually starts
Almost always a convincing sign-in page reached from a link, or a password reused from an unrelated breach. Occasionally an MFA prompt approved out of fatigue at the eighth attempt.
Which is why the fix afterwards is rarely about that one account. It is Conditional Access so a sign-in from an unrecognised device in another country is challenged or refused, legacy authentication blocked so nothing can bypass MFA entirely, and app consent taken out of end-user hands.
If you are in the middle of this now
Work down the first list. If you are unsure at any point, stop changing things — preserving the evidence matters more than tidying up, and an hour of the wrong kind of cleanup can permanently remove the record of what happened.
Frequently asked
I changed the password. Am I safe now?
Not necessarily, and this is the single most common mistake. A password change does not remove a forwarding rule, a consented OAuth application, or an authenticator the attacker registered. Any of those is enough for them to return. Sessions also need revoking, or a stolen token keeps working.
How do I know whether they read or sent anything?
The Microsoft 365 unified audit log records it, but only for as long as your retention allows — and the window is shorter than most businesses expect. That is the reason to capture it early rather than after the panic subsides.
Do we have to tell anyone?
It depends what data was involved and what sector you are in. HIPAA, Florida breach notification law and your own customer contracts can all apply, and the clocks are short. That is a question for your lawyer, and what they need from you is a factual timeline.
Should we just delete the account and start again?
Rarely a good idea, and never before the logs are captured. You would destroy the record of what happened while leaving any other compromised account untouched.