A customer calls to ask "did you change your bank account?", a colleague finds a message in their own Sent Items that they never wrote, or a cloud service raises a sign-in alert from an unfamiliar location: any of these can mean a company mailbox has been taken over. A compromised mailbox is not fixed by changing the password. Microsoft's response guidance treats disabling the account, revoking sessions, checking MFA, checking app consents, checking admin roles and checking forwarding as separate steps, because each is a way for an attacker to keep access and regain control later, independently of the password[1].

This article is for IT administrators at small and mid-sized companies running Microsoft 365 or Google Workspace. It covers the warning signs, the containment order based on each vendor's official documentation, how to find out what the attacker read and sent (logs expire, so the longer you wait the less you can see), and then notifying the people you deal with, reporting, and preventing a repeat. For general incident response principles, see The first 24 hours of a suspected breach.

Recognize it: common signs of a compromised mailbox

Microsoft lists these common symptoms of a compromised Microsoft 365 mailbox[1]:

  • The mailbox is blocked from sending email.
  • Email is missing or deleted.
  • Suspicious inbox rules, such as rules that automatically forward mail to unknown addresses, or move messages to folders nobody looks at, like Notes, Junk Email or RSS Subscriptions.
  • Sent Items or Deleted Items contain messages the user did not write.
  • External email forwarding was recently added.
  • Frequent password changes or unexplained account lockouts.
  • The user's contact details in the Global Address List, or their email signature, have been changed.

Beyond the mailbox itself, look at account-level changes: MFA devices or methods the user does not recognize, and apps the user has consented to that should not have access to data[1]. Several Microsoft 365 default alert policies map directly to these signs, including the creation of an inbox rule that forwards or redirects mail (it only tracks rules created in Outlook on the web or Exchange Online PowerShell), autoforwarding to a suspicious external account, suspicious email sending patterns, and a user being restricted from sending email; the required subscription differs by alert[2]. In Google Workspace, User log events list successful and failed web sign-ins in your domain, and suspicious sign-ins are flagged with a warning icon[3].

Inbox rules and forwarding deserve special attention: they can keep the mailbox owner from ever seeing replies or bounces from the people they deal with. For real business email compromise cases, see Phishing and business email compromise; Taiwan's Administration for Cyber Security (ACS) also notes that attackers often set up forwarding quietly in the background to intercept verification codes and break in again[4]. If a customer received a payment-change notice that appears to come from you, first use message trace in Microsoft 365[1] or Email log search in Google Workspace[3] to check whether that message really left your system. If it did, treat it as an account takeover and follow this article. If it did not, the customer's own mailbox may be compromised, or someone may be spoofing or imitating your domain; for the latter, see the SPF, DKIM and DMARC deployment guide.

Containment: order matters more than speed

The most common mistake is "reset the password and call it done". A new password stops the attacker signing in again with the old one, but it does not necessarily stop what is already in place: signed-in sessions, app passwords, apps the user consented to, and automatic forwarding and inbox rules. Microsoft notes that resetting a password does not automatically revoke app passwords[1], and Google advises resetting a user's sign-in cookies after resetting their password[5]. The ACS's Cybersecurity Incident Response Action Guide, published in July 2026, likewise lists checking email filters and automatic forwarding rules, and forcing sign-out from all devices and apps after the password change, as response actions for a stolen account, and warns against continuing to use a compromised account because attackers have usually planted a backdoor or reset access credentials[4]. If the attacker stole a signed-in session through AiTM phishing (see the MFA rollout guide for how that works), revoking sessions is a step you cannot skip. The principle: first make the account temporarily unusable, then remove every access path in one pass, and only hand the account back once the investigation has reached a stopping point. Before deleting rules or grants, take screenshots or export the settings as evidence.

Microsoft 365

  1. Disable the account: Microsoft recommends disabling the affected account until the investigation is complete; if you cannot, the next best step is a password reset. Do not email the new password to the user, because the attacker may still be reading the mailbox; if the account is synced from on-premises Active Directory, reset the password in AD, and reset it twice[1].
  2. Revoke sessions: in the Microsoft Entra admin center, open the user, clear Account enabled under Account status, then select Revoke sessions on the user's overview page; PowerShell users can run Revoke-MgUserSignInSession[6]. After revocation the account cannot get new tokens, but access tokens already issued remain valid until they expire, by default after 1 hour, and Entra ID cannot directly revoke a session token issued by an application itself[6].
  3. Remove app passwords: resetting the password does not automatically revoke app passwords, so delete the existing ones and create new ones[1].
  4. Check MFA: review the user's registered MFA devices and methods and remove anything unrecognized[1].
  5. Check app consents: review the apps the user has consented to, and remove and revoke any that should not be there[1]. Once an app is confirmed malicious, Microsoft recommends disabling it rather than deleting it: a deleted app can come back if another user grants consent later, while a disabled app cannot obtain new tokens to access data[7].
  6. Check admin roles: remove any roles the user should not have[1].
  7. Check forwarding and inbox rules: in Exchange Online PowerShell, use Get-Mailbox to check the mailbox's forwarding settings, where a value in ForwardingSmtpAddress means mail is being forwarded to an external recipient; then run Get-InboxRule -IncludeHidden to list every inbox rule, hidden ones included, and look for forwarding and redirection[1]. Also review mailbox delegation and shared access to make sure no extra account can read or send mail on the user's behalf.

When the investigation is done, reset the password and re-enable the account. If the account was used to send a large volume of mail, it may have been placed on the Restricted entities page and blocked from sending, and an administrator has to remove it[1].

Google Workspace

Google's checklist makes suspending the user the first step, because suspending a user resets their sign-in cookies and OAuth tokens[3]. Then:

  1. Revoke access: reset the password, revoke the user's OAuth 2.0 tokens, and remove any app passwords the user created[3]. If you reset the password without suspending first, also reset the sign-in cookies from the user's account page under Security > Sign-in cookies > Reset; after a password reset, third-party mail apps that use OAuth, such as Apple Mail and Thunderbird, stop syncing until the user signs in again with the new password[5].
  2. Investigate: if the compromised user is an administrator, start with the Admin audit logs for recent configuration changes; review mobile devices linked to the account and wipe any suspicious ones; then work through User log events, Email log search and OAuth log events (see the next section). User-level Gmail settings such as forwarding can be retrieved through the Gmail API[3].
  3. Return the account: unsuspend it, give the user a temporary password and require a new, unique one that is not used anywhere else; work through the Gmail security checklist with the user to confirm that filters, forwarding and account recovery options have not been changed by the attacker[3].

Investigation: what did the attacker read and send?

Once the account is contained, you need to answer two questions: which messages did the attacker look at, and what did they send from the account? The answers decide who must be notified and whether personal data was exposed. The catch is that each log has its own retention period, and some last only days. Microsoft also warns that if auditing was not enabled before the attack, there is no audit data to investigate afterwards[7].

Microsoft 365

  • Unified audit log: Microsoft Purview Audit (Standard) keeps records for 180 days (records generated before October 17, 2023 were kept for 90 days); Audit (Premium) keeps Microsoft Entra ID, Exchange, OneDrive and SharePoint audit records for one year by default and supports custom retention policies[8]. Note that auditing is not on by default for small and medium business licenses such as Microsoft 365 Business Basic, Business Standard and Business Premium, or for tenants on free trials of enterprise licenses: these must turn it on manually, and while auditing is off, audit log searches return no results, so confirm it is on before an incident happens[9].
  • Entra sign-in logs are separate: Microsoft Entra sign-in and audit logs are separate from the Microsoft 365 unified audit log. Entra ID Free keeps them for 7 days and P1 or P2 for 30 days; upgrading later does not bring back data that has already expired, and longer retention requires archiving to a storage account through Azure Monitor in advance[10]. In other words, a company without P1 or P2 may have only a week of sign-in history.
  • MailItemsAccessed: this mailbox auditing action records access to mail through protocols including POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST. It is part of Audit (Standard) and is enabled by default for users assigned an Office 365 or Microsoft 365 E3/E5 license[11]. There are two access types: sync is only recorded when desktop Outlook downloads a set of messages, and it is logged per folder, with Microsoft's guidance being to assume every item in that folder is compromised; bind records the InternetMessageId of each individual message accessed, so you can list which messages the attacker accessed[11]. Comparing fields such as ClientIPAddress and SessionId separates the attacker's activity from the user's own; but if the attacker syncs mail to their own computer and reads it offline, mailbox auditing cannot record that reading[11].
  • What was sent: use message trace in the Microsoft Defender portal to find messages sent from the account during the suspicious period, and compare with the Sent Items folder[1].

Google Workspace

  • User log events: web sign-ins can be reviewed for up to 6 months[3].
  • Email log search: shows delivery logs for mail to and from the account[3], but only for 30 days[12].
  • Gmail log events and OAuth token log events: kept for 6 months; OAuth log events can take up to a few hours to appear in search results[12].
  • No extensions: Google states that administrators cannot delete log event data or change how long it is available[12].

In practice, export the relevant logs on the day you discover the compromise rather than waiting for the investigation to finish. For which logs to centralize and how long to keep them in normal times, see Logging and log retention.

Follow-through: warn your contacts, stop payments, report

The most direct losses from a compromised mailbox often land on someone else: the attacker sends a payment-change notice from your mailbox and your customer pays the wrong account, or uses a compromised manager's or salesperson's mailbox to tell your own finance team to pay a new account.

  • List the recipients: use message trace or Email log search to compile the messages sent from the account during the incident window and who received them[1][3].
  • Warn them proactively: the ACS recommends proactively notifying the contacts, colleagues and customers who deal with the account, and asking them to be wary of any recent payment requests, links or files sent in its name[4]. In practice, call customers and suppliers, or use established contact channels, and tell them not to act on any payment or bank-detail change sent from that mailbox during this period, and that future changes will always be confirmed by calling a known number. For a payment-change verification process, see Phishing and business email compromise.
  • Check your own payments and linked systems: have finance review bank-detail changes and pending payments received during the incident window and put them on hold; any request to change a payee account or make an urgent payment must be confirmed with the counterparty through the phone number or fax registered in the original contract, or in person, never by replying to the suspicious email[4]. Also review the online banking, third-party payment and procurement systems tied to the account, to prevent unauthorized purchases and payments[4].
  • If money has already been sent: contact your bank at once through its official website or a verified hotline and ask it to stop the transfer; at the same time, call the 165 anti-fraud hotline and report the case at your local police station, bringing the conversation records and transaction receipts[4]. Keep the fraudulent emails' headers, the correspondence, attachments and remittance receipts intact, delete nothing, and consult your legal team to support later prosecution and insurance claims[4]. For stop-payment and flagged-account procedures, see Impersonation and deepfake fraud.
  • Incident reporting: ordinary companies can report through TWCERT/CC's general incident reporting online form or by email to int_report@cert.org.tw[13]; agencies covered by the Cyber Security Management Act and listed companies have additional reporting or disclosure obligations, see The first 24 hours of a suspected breach.
  • Personal data: mailboxes routinely hold customer lists, quotations and copies of ID documents. Microsoft advises assuming that more mail was compromised than you can trace, and notes that depending on the data in the messages, you might face regulatory fines unless you can prove sensitive information was not exposed[11]. If personal data was accessed, or you cannot rule it out, assess your notification obligations using Responding to a personal data breach.

If your team cannot handle containment, investigation and external communication at the same time, consider bringing in an incident response service.

Preventing a repeat

  • Move to phishing-resistant MFA: Microsoft recommends enabling and enforcing MFA on the affected account and calls MFA essential for accounts with admin privileges[1]; Google recommends security keys over 2-Step Verification codes for better protection against phishing[3]. For a comparison of methods, see the MFA rollout guide.
  • Block legacy authentication: Microsoft's analysis found that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication protocols that do not support MFA; block them with a Conditional Access policy, or, for organizations without licenses that include Conditional Access, with security defaults[14]. In Google Workspace, regularly review and remove app passwords that are no longer needed.
  • Block automatic external forwarding by default: Microsoft 365 outbound spam policies have three automatic forwarding settings. The default, Automatic - System-controlled, behaves differently from one organization to another, so Microsoft recommends setting On or Off explicitly; with Off, inbox rules and mailbox forwarding to external addresses stop working, while internal forwarding is unaffected. Where there is a business need, Microsoft notes you can allow automatic forwarding in the policy and use remote domains to limit which external domains mail can be forwarded to; when settings conflict, the block typically wins[15]. In Google Workspace, automatic forwarding is on by default; you can turn it off, or limit it to internal addresses, in the Admin console under Apps > Google Workspace > Gmail > End User Access, and set it per organizational unit[16].
  • Restrict user consent to apps: by default, Microsoft Entra lets users consent to permissions that do not require admin consent, such as letting an app access their own mailbox; Microsoft recommends allowing consent only for apps from verified publishers with permissions classified as low impact, and having administrators approve everything else[7]. In Google Workspace, the setting is under Security > Access and data control > API controls; for unconfigured third-party apps the default is "Allow users to access any third-party apps", which you can change to allow only apps that request basic sign-in information, or to block all third-party apps until an administrator configures them[17].
  • Make sure someone reads the alerts: confirm that the Microsoft 365 default alerts for forwarding rules and sending restrictions go to a mailbox someone actually works from[2]; Google Workspace administrators can turn on account activity alerts to be notified of potentially suspicious sign-ins or service setting changes by other administrators[3]. On top of that, review inbox rules and forwarding across the company once a quarter.

Action checklist

  • Turn this article's containment order (disable, revoke sessions, app passwords, MFA, app consents, admin roles, forwarding and rules) into your own written procedure, noting which console each step uses and who has the rights to do it.
  • Check today: whether Microsoft 365 auditing is on and how many days of Entra sign-in logs you keep; Google Workspace Email log search covers only 30 days, so export anything you need to keep longer.
  • Turn automatic external forwarding off by default and allow it only for listed accounts with a business need.
  • Restrict user consent to third-party apps and turn on an admin approval process.
  • Block legacy authentication, and review and remove app passwords that are no longer needed.
  • Move administrator, finance and executive accounts to phishing-resistant MFA first.
  • Confirm that alerts for forwarding rules, unusual sending and suspicious sign-ins are received and acted on.
  • Prepare a one-page contact card: your bank's contact, 165, how to report to TWCERT/CC, and known phone numbers for key customers and suppliers.
  • Run a tabletop exercise on the scenario "an executive's mailbox is compromised and a customer receives a fake payment notice".