When a mailbox is hijacked, work in this order: disable the account or reset its password, revoke active sessions, remove unknown MFA devices, review app consents and admin roles, then remove forwarding and inbox rules. Investigate sign-in and audit logs afterwards. This follows Microsoft's published guidance.
Before you start
Write down the time the user first noticed something odd. You will filter logs from just before it. Do not send a new password to the user by email, because the attacker may still be reading the mailbox.
The steps
1. Disable the account. Microsoft says disabling is preferred until the investigation is done. If you cannot, reset the password to a unique value. For accounts synced from Active Directory, reset in Active Directory, and Microsoft suggests doing it twice to reduce pass-the-hash risk. App passwords are not revoked by a password reset, so have the user delete and recreate them.
2. Revoke sessions. Invalidate active sessions and refresh tokens so stolen access stops working. This matters most when the cause was session theft, covered in AiTM phishing.
3. Review MFA methods. Remove any device or method you do not recognize. Attackers add their own to stay in.
4. Review user consented applications. Revoke anything that should not be there. See consent phishing.
5. Review administrative roles. Remove roles the user should not hold.
6. Review mail forwarding. Check the mailbox forwarding properties, including ForwardingAddress, ForwardingSmtpAddress and DeliverToMailboxAndForward. Then list all inbox rules, including hidden ones, and look at RedirectTo, ForwardTo and ForwardAsAttachmentTo.
Investigate
Use Entra sign-in logs to examine IP address, location, time and success or failure. Search the audit log from just before the first suspicious activity, without filtering on specific actions at first. Use message trace and the Sent Items folder to see what was sent.
Then decide who else was exposed: recipients of fraudulent mail, shared mailboxes the account could reach, files in OneDrive or SharePoint.
After the investigation
Reset the password and re-enable the account if you disabled it. If the account sent spam, it may be on the restricted entities list, so remove it there. Enforce MFA, and phishing-resistant MFA for admins, as Microsoft recommends.
Tell the right people
Notify finance if payment threads were involved, and contact any counterparty who received altered instructions. Keep a record of times and actions for your incident file.
A note on evidence
Keep copies of what you find before you remove it. Export the rule definitions, forwarding settings and relevant log entries, then clean up. If a regulator, insurer or customer later asks what happened, a dated record of the original malicious rule and the time you removed it is far more useful than a summary written from memory. Store the export somewhere the compromised account cannot reach.
Quick check
Why revoke sessions if the password is already reset?
A stolen session or refresh token can keep working after a password change. Revoking forces a fresh sign-in.
What should I look for besides forwarding?
Hidden inbox rules, new MFA methods, newly consented apps and unexpected admin roles.
Sources
Last reviewed: 19 October 2026.