Downstream Accounts to Check After a Mailbox Takeover

A password reset closes the inbox, not the incident.

That gap is the most common reason a "resolved" mailbox turns into a second incident a week later. The attacker still has OAuth refresh tokens, still has inbox rules that hide their activity, and may have already used the mailbox to reset passwords for other accounts. Until those downstream exposures are verified, the ticket should stay open.

This is the checklist to walk through before signing off a mailbox takeover in Microsoft 365, Google Workspace, or on-prem Exchange.

What the password reset actually undoes

Three things, and only three:

the old password stops working
any active session that was tied to that password stops authenticating with that credential
mailbox lockouts (if the tenant enforces them) reset

Three things the password reset does not undo:

any OAuth refresh token already issued to a malicious application
any inbox rule or forwarding rule added during the compromise window
any password reset email that an attacker triggered for a third-party account using the compromised mailbox

That last category is the silent one. The attacker gets in, sees the user has a banking relationship, hits "forgot password" on the bank, opens the reset email from the user's inbox, completes the reset, and locks the user out of the bank account before the helpdesk has even taken the call. The mailbox takeover was the stepping stone, not the destination.

The four classes of downstream exposure

Group everything that could still be touched from the compromised mailbox into four classes. The first three are admin-side. The fourth is user-side.

Class 1: Email-based password reset vectors. Any service that sends a password reset link to the user's email is open to the attacker as long as the attacker can read email in that mailbox. This includes the corporate SSO, the corporate VPN, third-party SaaS, banks, brokerages, and personal email-recovery for non-corporate accounts.

Class 2: OAuth grants and connected apps. Any application that was granted Mail.Read, Mail.Send, or equivalent offline access during or before the compromise. Offline access means the app keeps a refresh token; a password reset does not invalidate the refresh token.

Class 3: Persistent mailbox-side access. Inbox rules, forwarding to external addresses, folder permissions added during the window, mobile app pairings, and Outlook add-ins the attacker installed. These are easy to miss because they are inside the mailbox itself.

Class 4: Personal accounts the user owns. Personal banking, personal email, personal crypto exchange, the user's own social media. These are technically out of scope for IT, but the user needs a one-page reminder of what to reset. If you skip this, you will see the second incident in the helpdesk two weeks from now.

First hour: kill tokens and persistence

These are the steps you do while the helpdesk call is still warm.

Revoke Entra ID refresh tokens. In Microsoft 365, sign-in revocation kills the user's existing refresh tokens. The path is Entra ID, Users, the affected user, Sign-in, then Revoke sessions. The user will have to re-authenticate every device. The cost is acceptable; the cost of leaving tokens alive is not.

Audit inbox rules. Open the mailbox in Outlook on the Web and look for any rule created during the compromise window. Common attacker rules:

move messages containing "invoice" to a hidden folder
forward all messages to an external address
mark messages from a specific sender as read and move them to RSS Feeds
delete messages matching "password reset"

Rules with the word "stop" or "invisible" in the description are worth a closer look.

Disable external forwarding. In Exchange Online, set the forwarding rule to disable forwarding for the affected user. Then audit the audit log for any forwarding the attacker configured during the window.

Re-enrol MFA. Force the user to re-enrol any MFA factors. The attacker may have registered their own device or their own number as a fallback.

First day: rebuild trust on connected systems

These are the steps you do within the first 24 hours.

Enumerate OAuth grants. In Microsoft 365, go to Entra ID, Applications, App registrations, then filter for the affected user as owner. Anything the user does not recognise. Revoke. The M365 unified audit log has an OAuthConsentGrant event; pull all events for the user across the compromise window and review them.

Review connected apps in Google Workspace. In Google Admin, Security, API controls, filter by user. Anything the user does not recognise. Revoke. Google's equivalent audit event is under Reports, Audit log, filter for "Granted third-party app access".

Change passwords for any service that uses email-based reset. This is the high-effort step. The user has to log into every third-party SaaS they use (banking, accounting, payroll, CRM, support desk, password manager) and trigger a password reset from a fresh device, not from the compromised mailbox. The new password should be set on email.

Rotate app passwords. If the user has app passwords for IMAP or SMTP clients, rotate them. App passwords survive password resets on some platforms.

First week: verify the rest

These are the steps that close the ticket.

Have the user verify high-value accounts they own. Send them a one-page checklist. Personal banking: change password, review recent transactions. Personal email: change password, review forwarding. Crypto exchange: change password, revoke API keys. Social media: revoke any sessions the user does not recognise.

Audit the corporate domain's sending footprint. The mailbox takeover is over, but the corporate domain keeps being spoofed from outside, regardless of who sits in this particular inbox. Pull a DMARC aggregate report for the corporate domain and look for senders from IPs that are not part of your infrastructure. If any appear, they are spoofers. DMARC at p=reject on the corporate domain is what stops those spoofers from reaching external inboxes. A DMARC checker is one practical way to confirm that p=reject is enforced across the apex and every active subdomain before the ticket closes. DMARCFlow's RUA aggregator is one option that surfaces both the apex and every active subdomain in the same view, so a freshly-exploited subdomain does not slip past unnoticed.

Watch for new phishing against the same user. Attackers who compromised a mailbox once often come back through the same user with a fresh angle. Flag the user for enhanced monitoring in the M365 unified audit log and Google Admin alerts.

Document and close. A short incident report with timestamps for: detection, password reset, token revocation, OAuth review, mailbox rule removal, downstream account password reset, and ticket close. This is what you hand to legal if the incident expands.

FAQ

Do I really need to revoke OAuth grants after a password reset?
Yes. OAuth refresh tokens are issued to the application, not to the user's password. A password reset does not invalidate the grant. Revoke explicitly via Entra ID or Google Admin.

What mailbox rules should I look for during the compromise window?
Anything that hides, forwards, or deletes messages. Look for rules with names like "invoice", "hidden", "stop rules", and "RSS". Anything created during the window that wasn't there before is suspect.

Should the user change passwords for their personal accounts too?
Yes, if those accounts have password reset by email. Send the user a one-page checklist. The mailbox takeover was a stepping stone; the second incident may not be in the corporate tenant.

Is force sign-out the same as a password reset?
No. Password reset changes the credential. Force sign-out (or session revocation) kills active sessions but does not change the credential. After a takeover you need both.

Where does DMARC enforcement fit in mailbox-takeover response?
It does not prevent the takeover, but it limits what the attacker can do once they leave the inbox. A DMARC-reject policy across the user's domain stops lookalike senders from reaching external recipients under the corporate name.