The essentials
- Identity is the perimeter: revoke sessions and refresh tokens for affected accounts tenant-wide — a password change without revocation leaves the attacker logged in.
- Persistence hides in four places: OAuth app grants, inbox rules and forwarding, new or elevated admin accounts, and changed federation or authentication settings. Check all four.
- Export the audit logs now; default retention is short and the investigation depends on them.
- Common entry: MFA-fatigue prompts, phished session tokens, and legacy protocols that bypass MFA entirely.
- Scope what was read — mailboxes, files, sharing links — before declaring the incident closed; legal duties ride on that answer.
In a cloud tenant, the attacker does not need your network — the account is the asset. A compromised identity reads mail, exfiltrates files, registers innocuous-looking apps for durable access, and quietly forwards a copy of everything to the outside.
Eviction is therefore about identity mechanics, not machines: sessions, tokens, grants, rules, and settings. Do it as one coordinated pass, or the surviving foothold lets them back in behind you.
Do this now
- Revoke sessions and tokens. For every affected account: revoke sign-in sessions and refresh tokens, then reset passwords and re-enroll MFA. In that order — the token revocation is the eviction; the password is the lock change.
- Sweep the four persistence spots. Enterprise app and OAuth grants (record, then remove the unfamiliar), inbox rules and external forwarding across affected mailboxes, admin-role membership, and federation/conditional-access changes.
- Export the audit trail. Unified audit log or admin audit, sign-in logs, and mailbox audit for the suspect window — exported to files now, retention extended where the license allows.
- Scope the access. Which mailboxes were read, what was searched, which files were downloaded or shared externally, what the registered apps could reach. This is the factual basis for every notification decision.
- Close the entry class. Disable legacy authentication, tighten conditional access (location, device, risk-based), and switch MFA to phishing-resistant methods for admins first.
- Bring in help proportional to reach. If admin roles, federation settings, or many mailboxes were touched, professional scoping is warranted — tenant-level persistence is easy to miss and expensive to miss twice.
What not to do
- Do not stop at one password reset — tokens outlive passwords.
- Do not delete the attacker's app registrations or rules before recording them; they are both evidence and the map of intent.
- Do not leave legacy protocols enabled while congratulating yourself on MFA.
- Do not scope by assumption ("they only had it an hour") — read the logs.
- Do not run the eviction one account at a time over days; coordinate one pass.
Preserve the evidence
Whatever else happens, these are the artifacts the investigation — and any insurance claim, dispute, or prosecution — will be built from:
- Exported audit, sign-in, and mailbox logs for the window.
- The recorded list of app grants, rules, forwards, and role changes found.
- Download and sharing activity for scoped accounts.
- Timestamps of eviction actions, for the incident record.
Keep a clear head
Cloud incidents feel abstract — no smoking server, just settings pages — and that abstraction tempts teams to declare victory after a password reset. Hold the standard: eviction is done when tokens are dead, the four persistence spots are clean, and the logs say so.
Questions victims ask
We have MFA. How did they get in?
The usual three: bombing a user with push prompts until one is approved, phishing pages that relay the session token in real time, and legacy protocols (IMAP/SMTP basic auth) that skip MFA entirely. MFA raises the bar; these are the ways over it.
Is this different between Microsoft 365 and Google Workspace?
The mechanics rhyme: both have sessions/tokens to revoke, app grants to audit, rules/forwarding to sweep, admin roles and auth settings to verify, and audit logs to export. The menu names differ; the checklist does not.
Do we have to treat read mailboxes as a data breach?
Possibly — a mailbox is personal data by the crate. The honest answer comes from scoping: whose mail, what was in it, and what regulation applies. That is a counsel-plus-facts decision, which is why the logs get exported first.