Microsoft 365 Account Compromised? The First 60 Minutes, Step by Step

Disable the account first, then revoke its active sessions. Resetting the password is not step one and, on its own, does not remove an attacker who already holds a valid session token. That single point is the difference between an incident that ends in an hour and one that comes back on Thursday.

This runbook follows the order Microsoft publishes for responding to a compromised Microsoft 365 account, with the Australian reporting obligations that run alongside it. It is written for the person who has the problem right now: an internal IT lead or a business owner with Global Administrator access. If nothing has happened yet, the checklist and phishing guides in this series are the better place to start.

How to tell an account is compromised

Microsoft lists the signs that a mailbox has been taken over. Any one of them is enough to act on.

• The mailbox is suddenly blocked from sending email, which usually means Microsoft detected outbound spam before you did.
• Inbox rules nobody created: rules that forward to an unknown external address, or that move messages into Notes, Junk Email or RSS Subscriptions so the real owner never sees the replies.
• Suspicious messages in Sent Items or Deleted Items, or a Sent Items folder that has been emptied.
• Recently added external forwarding on the mailbox itself.
• Frequent password changes or unexplained account lockouts.
• Changes to the user's entry in the global address list, such as a changed display name or phone number.
• An email signature that is not theirs, or a colleague asking about a message the user never sent.

The rules that hide replies are the tell that matters most. A criminal reading invoice traffic wants the conversation to continue without the real owner noticing, and an inbox rule filing everything from the finance address into RSS Subscriptions does exactly that.

Step 1: Disable the account

Microsoft's stated preference is to disable the affected account for the duration of the investigation rather than to reset its password. Disabling stops new sign-ins immediately and keeps the mailbox intact for investigation. In the Microsoft 365 admin center this is Users, Active users, select the user, then Block sign-in.

If the business cannot tolerate the account being disabled, reset the password instead, and observe three rules Microsoft is explicit about. Do not send the new password to the user by email, because the attacker may still be reading that mailbox. Do not reuse a recent password even if the history policy allows it. If the identity is synchronised from on-premises Active Directory, reset it there and reset it twice, which mitigates pass-the-hash. For a federated identity the password change has to happen in the on-premises environment.

Step 2: Revoke the active sessions

This is the step most commonly skipped, and skipping it is why some incidents recur. A password reset invalidates the password. It does not, by itself, immediately invalidate the refresh tokens an attacker already holds, which is what keeps a mailbox open in their client after you think you have closed it. Revoking sessions invalidates those tokens and forces every client to reauthenticate.

In the Microsoft Entra admin center, open the user and choose Revoke sessions. The scripted equivalent uses Microsoft Graph PowerShell and the User.RevokeSessions.All scope, running Revoke-MgUserSignInSession against the user principal name. Do it for every account you suspect, not only the one that reported the problem.

Step 3: Check the registered authentication methods

An attacker who gets in will often register their own multifactor authentication method so they can return after the password changes. A new phone number, a second authenticator app, an unfamiliar security key. This is the persistence mechanism that survives everything in steps one and two if you do not look for it.

In the Microsoft Entra admin center, open the user, then Authentication methods. Remove anything the user does not recognise, and have the user re-register from a known-good device. Check the same list for any other account that shares a manager or a role with the compromised one.

Step 4: Review applications the user has consented to

Illicit consent is the quieter form of persistence. Rather than stealing a password, an attacker persuades the user to grant an application ongoing permission to read their mail or files. The consent survives a password reset, a session revocation and a new authenticator, because it is not a credential at all.

In the Microsoft Entra admin center, review the enterprise applications the user has granted permissions to, and revoke anything unexpected. While you are there, check whether user consent to applications is restricted at the tenant level. In a small business it usually should be, so that granting an application access to company data is an administrator decision rather than a click in a phishing flow.

Step 5: Review the administrative roles on the account

Two questions. What could this account do, and did the attacker add anything? Open Roles and administrators in the Microsoft Entra admin center and check the assignments on the compromised account, then check whether any new administrator assignment appeared anywhere in the tenant during the incident window. An attacker who reaches an account with role-assignment rights will usually create a second way in before doing anything noisy.

If the compromised account held Global Administrator, the scope of the incident is the whole tenant rather than one mailbox, and the honest position is that you are now in an engagement that needs outside help.

Step 6: Find the forwarding and the inbox rules

There are three separate places mail can be diverted from, and checking only one is the usual mistake.

1. 1Mailbox-level forwarding. In Exchange Online PowerShell, Get-Mailbox for the user and read ForwardingAddress, ForwardingSmtpAddress and DeliverToMailboxAndForward. A non-blank ForwardingSmtpAddress means mail is going to an external recipient right now.
2. 2Inbox rules, including hidden ones. Get-InboxRule with the -IncludeHidden switch, reading Name, Enabled, RedirectTo, ForwardTo and ForwardAsAttachmentTo. Hidden rules do not appear in Outlook, which is precisely why attackers use them.
3. 3The Auto forwarded messages report in the Microsoft Defender portal, which lists every mailbox in the tenant currently forwarding externally. Run it for the whole tenant, not just this user. A second name on that list is a second incident you did not know you had.

Record what you find before you remove it. Then set the outbound spam policy's automatic forwarding control explicitly to off rather than leaving it on the ambiguous Automatic default. Once off, a rule that tries to forward externally generates a bounce with code 5.7.520, internal forwarding is unaffected, and genuine business exceptions can be handled per domain through remote domain settings.

Then investigate: what did they see, and what did they do?

Containment is the first hour. The investigation determines whether this was a nuisance or a notifiable data breach, and the difference is usually decided in logs rather than opinions.

• Microsoft Entra sign-in logs: IP address, location, time and success or failure. You are looking for the first successful sign-in from the attacker so you know when the window opened, and for the same IP or user agent against other accounts.
• Audit logs in the Microsoft Defender portal: filter from immediately before the first suspicious activity and do not narrow by activity type on the first pass, because you do not yet know what you are looking for.
• Message trace: what left the mailbox during the window and who received it. Combine with the Sent Items folder, remembering that a careful attacker empties it.
• SharePoint and OneDrive activity: an account compromise is a file access compromise too. Check what was opened, downloaded or shared externally during the window.

Write down the incident window with a start and end time. Every obligation in the next section is easier to discharge with that one line written down, and much harder without it.

The Australian parallel track

These run at the same time as the technical work, not after it. Assign them to somebody who is not doing the containment.

The Notifiable Data Breaches obligation is the one most often missed in a small business, because the instinct is to treat a mailbox takeover as an IT problem. If the mailbox held personal information about customers, staff or patients, and unauthorised access is likely to cause serious harm, the scheme applies regardless of how the access happened. The 30 days is the assessment window, not a grace period before you have to start.

Closing the incident properly

Three things finish it. Re-enable the account with a new password delivered out of band, which means in person, by phone or through a channel the attacker never had. Check whether the mailbox was blocked from sending during the incident and, if so, remove it from the Restricted entities page in the Defender portal, which is the step that gets forgotten and produces a week of mail delivery complaints. Then write down what the entry point was.

That last one determines whether this happens again. If the entry point was a phished password, phishing-resistant multifactor authentication for that role is the fix. If it was legacy authentication, the block policy is the fix. If it was illicit consent, restricting user consent to applications is the fix. Closing an incident without naming the entry point means the same door is still open, and the next attacker will find it faster than the first one did.