← IncidentReady

Company email account hacked? Do this in the next 30 minutes

For companies whose entire IT department is one person. No SOC, no SIEM assumed. Works for Microsoft 365 and Google Workspace. Print this.

The first 15 minutes

1. Disable sign-in first, don't just reset the password. A live session survives a password change until you revoke tokens — disable the account, then reset, then revoke, in that order.
2. Revoke all active sessions and refresh tokens the moment the account is disabled — this is the step that actually kicks an attacker out in real time, not the password reset.
   • M365 / Entra ID: Entra admin center → Identity → Users → [user] → Revoke sessions (or Block sign-in to stop password-based re-auth too).
   • Google Workspace: Admin console → Directory → Users → [user] → Sign out user, then Security → Suspend user if you need a full lockout while you work.
3. Reset the password to a strong, unique value. Deliver it out-of-band — phone call or in person, never by email to the compromised account.
4. Sweep inbox rules and forwarding. This is the fastest-deployed persistence mechanism, so do it now, not after the wipe-your-hands moment. Check both admin-level mail flow rules and the mailbox's own rules — an attacker with even a few minutes of access commonly adds a rule that forwards or hides mail matching payment or password keywords.
5. Check MFA methods registered on the account. Remove any phone number, authenticator app, or security key the user doesn't recognize, then require re-registration.
6. Check OAuth/app grants. A malicious app grant survives a password reset — this is the step people skip and the reason accounts get "re-hacked" a day later.
7. Check for new devices or sessions registered on the account in your identity provider. Remove/revoke anything unrecognized.
8. Start an incident log — timestamps for every action above. You'll want them later to correlate against audit logs.

Microsoft 365 / Entra ID: exact paths

• Authentication methods: Entra admin center → Identity → Users → [user] → Authentication methods — review and remove unrecognized methods, then Require re-register multifactor authentication.
• Legacy auth check: Identity → Monitoring & health → Sign-in logs, filter Client App = legacy. Legacy authentication bypasses modern MFA — disable it at the Conditional Access policy level if it's still permitted.
• OAuth grants: Identity → Applications → Enterprise applications, or per-user Users → [user] → Applications. Look for apps with broad Mail.Read, Mail.Send, or Files.ReadWrite.All scopes granted recently. Remove anything unrecognized.
• Inbox rules: PowerShell — Get-InboxRule -Mailbox user@domain.com — or Exchange admin center → Mail flow, for rules the user didn't create.
• Mailbox delegation: Exchange admin center → Recipients → Mailboxes → [user] → Mailbox delegation — check for "send as" or full-access grants you didn't authorize.

Google Workspace: exact paths

• 2-step verification: Admin console → Directory → Users → [user] → Security → 2-step verification — review enrolled methods, revoke and force re-enrollment if anything looks unfamiliar.
• App passwords: Admin console → Directory → Users → [user] → Security → App passwords — revoke all of them. App passwords bypass 2FA prompts entirely and are a favorite persistence mechanism.
• Connected apps / OAuth: Admin console → Security → API controls → App access control → Manage third-party app access, or per-user Directory → Users → [user] → Security → Connected apps. Revoke anything with Gmail or Drive scope you don't recognize.
• Gmail rules and forwarding: Admin console → Reporting → Audit and investigation → Gmail log events, filter for rule and forwarding changes, or have the user check Gmail Settings → Filters and Blocked Addresses / Forwarding directly.
• Delegate access: Gmail Settings → Accounts → "Grant access to your account," or Admin console audit log filtered for Grant delegate access.

If it's an admin/privileged account

Treat it as a full-tenant incident, not a single-account issue:

• Assume the attacker used the admin session to create a second foothold — check new admin role assignments, new app registrations with high-privilege API scopes, new org-level mail-flow rules, and new Conditional Access exclusions.
• Rotate credentials for every admin account, not just the compromised one — if one was phished, others may have been targeted in the same campaign.
• Verify your break-glass/emergency-access account is still yours and wasn't reachable from the compromised admin's password vault.
• Don't use the compromised admin account to do any of this remediation — use a separate, verified-clean admin account.

The mistakes that make it worse

• Resetting the password before revoking sessions — the attacker's live session survives the reset.
• Skipping the OAuth grant review — this is how "fixed" accounts get compromised again within days.
• Re-enabling the account before checking inbox rules, delegates, and new devices — a lingering token can silently re-add a rule 24–48 hours later, so check again after re-enabling.
• Emailing colleagues about the incident from the affected mailbox before you're sure it's clean.

Preparedness templates, not legal advice. © 2026 IncidentReady