A work email account was hacked
Customers asking about an invoice you never sent. A sign-in alert from another country. A mailbox rule nobody remembers creating. When someone else is inside a work email account, changing the password is only the start. Intruders leave ways back in, they read everything, and they often use the mailbox to trick customers into paying them. This playbook walks you through containing it, cleaning up, then telling the right people.
Get outside help now if an administrator account is affected, money has been sent, several accounts are involved, or you can't get control back. Run the fake invoice or ransomware playbook alongside this one when those happen too.
Who does what. Anyone can take the first steps. Account changes belong to whoever runs IT (a staff member, your IT provider or you). The owner makes the business calls: payments, customers, outside help. Only make changes you're authorized to make, and follow your provider's current instructions where they differ from ours.
Do this now
For the employee, or the owner if there's no IT support:
- Call IT now, on a number you already know. Don't use the affected mailbox to talk about it, send passwords or share documents.
- Stop approving sign-in prompts. Don't use recovery links from unexpected messages: reach the provider through its own website or a bookmark.
- Use a different, trusted device for anything to do with recovery. Opened a suspicious file, installed an extension, pasted a command or allowed remote access recently? Tell IT. If malware is likely, disconnect that device from the network, then leave it on for IT.
- Pause questionable payments. Tell whoever handles money to check recent requests about invoices, bank details, payroll or gift cards with a phone call to a known number. If money has already gone, call the bank's fraud team now.
- Keep what you have. Note when you first noticed. Keep suspicious messages, alerts plus anything customers forwarded. Don't delete the mailbox, clear history or wipe a device.
No IT support at all? From a trusted device, use the provider's official recovery process, change the password, then use its "sign out everywhere" option. Contact the provider's business support straight away. Those steps don't replace the admin checks below, so get help with those.
For whoever runs IT
Use a separate admin account on a trusted device. Block or suspend the affected account, then revoke its sessions, following your platform's procedure. Keep the account with its records: don't delete it. If your only admin account is the one affected, use your emergency ("break-glass") admin account, or the provider's business support. [1] [2] [7]
Expect some disruption. Blocking the account can cut the employee off from other work apps too. Agree with the owner how they'll work in the meantime. Don't quietly unblock it because someone needs an invoice sent.
What does the report actually show?
| What you've got | How to read it |
|---|---|
| A customer got an odd email showing the employee's name | Could be a lookalike address, not the real mailbox. Get the original message, then check its headers with your provider's records. A display name alone proves nothing. |
| A successful sign-in the employee can't explain | Look at the time, device, app plus what happened around it. Location alone isn't proof either way. |
| A forwarding rule, recovery method or app permission nobody set up | Treat it as a compromise. Contain the account now. |
| The employee typed their password into a page, or approved an unexpected prompt | Contain the account while you investigate, even if nothing looks wrong yet. |
| The employee can't sign in | Could be an intruder, or an ordinary lockout. Check with your admin tools. |
Don't wait for certainty when there's credible evidence. If it turns out to be impersonation only (a lookalike address), write down why, lift the restrictions, then deal with the fake messages separately.
Take the account back
Microsoft 365
Follow Microsoft's compromised account procedure from a trusted admin session:
- Block sign-in, then revoke sessions.
- Reset the password where the account lives. Synced or federated accounts need the matching identity-provider steps.
- Remove sign-in methods the employee doesn't own. Review app passwords, app consents, admin roles.
- Check forwarding with inbox rules, including hidden rules. Record each malicious change, then remove it.
- Review sign-in logs, the audit log, message trace. Restore access only once it's clean, sending the new credentials through a trusted channel. [1] [6]
Google Workspace
Follow Google's compromised account checklist:
- Suspend the user. This resets their sign-in cookies plus OAuth tokens.
- While it's suspended, reset the password, then remove unknown app access with app passwords. Don't leave these until after a long investigation.
- Investigate user, email, OAuth activity in the audit logs. Check recovery options, two-step verification, Gmail filters, forwarding.
- Unsuspend only once it's clean, with recovery instructions sent through a trusted channel. [2]
Other email providers
Ask the provider how to suspend access, end existing sessions, remove app access, check forwarding with delegated access. If you can't do these yourself, open an urgent support case. Write down what they confirm, plus what's still unknown.
Sessions need their own check. A password reset or "sign out everywhere" may not end every session straight away. Apps connected through single sign-on can keep their own. Check the important ones separately, then confirm the block actually worked. [3]
Recovery methods. Remove anything the intruder controls straight away, then keep the account blocked until the employee's own methods are in place. Confirm who you're talking to before setting up their new sign-in: call them on a number you already had, or meet in person. Never verify them through the hacked mailbox itself, or a phone number the intruder might have added. Check passkeys, security keys, recovery addresses, phone numbers, backup codes.
Find the ways back in
Keep a change log as you go: what you found, where, when, what you removed. Take a screenshot or export of each setting before you change it, if that doesn't slow containment down.
- Delegates with send-as rights. Who else can open the mailbox, or send as this person?
- Apps with their own permissions. Block a malicious app, then remove its permission grants. Revoking the user's sessions does not remove an app's own access. Stop it being approved again. Existing tokens can stay valid until they expire. [5] [8]
- Devices on the account. Ask the employee which devices they really use. An unfamiliar name is worth investigating, not automatically malicious. Never wipe a device just because it's on a list.
- Organization-wide settings, if an admin was affected or anything wider looks changed: transport rules, connectors, new accounts, new admin roles. A fix on one mailbox can leave a wider door open. [6]
Access comes back after you've contained it? Keep the account blocked, then escalate. Likely causes: an infected device, an app permission you missed, another compromised account, or sessions that weren't fully revoked.
Work out what happened
Find the earliest suspicious activity you can, not just when it was reported. Export the records now: how long logs are kept depends on your subscription.
| Question | Where to look |
|---|---|
| When did the intruder get in, then get shut out? | Sign-in plus audit logs, the employee's timeline, your containment times |
| What did they send? | Message trace or email log search, recipients' copies, the mailbox itself |
| Did they hide or divert mail? | Rules, forwarding, delegates, related changes |
| What could they have read? | Mailbox access events, folders, attachments, business context |
| Did they reach beyond email? | File storage, shared mailboxes, connected apps, password reset emails |
| Who else was targeted? | Recipients of their messages, similar reports, related alerts |
Sent Items isn't enough. Intruders often delete what they send. Use your provider's message trace or log search. [6]
Separate what you know from what you don't. Write "confirmed", "possible", "unknown" next to each finding. For example: "An unauthorized person could open the mailbox. The available logs don't show which messages they read." Missing logs don't mean nothing was read.
Follow the money and the resets. The owner knows which business processes run through this mailbox: payroll, vendor payments, customer records, domain or website admin. Look for password reset emails for other services during the intrusion. Secure those services too. Check shared mailboxes the person could open, not just their own inbox.
Watch for conversation hijacking. Intruders often register a lookalike domain (one letter different), then move an invoice conversation onto it. Search for recent replies to lookalike addresses, then warn the people involved.
Look after customers and colleagues
The owner:
- Start with anyone who got payment instructions, or a malicious message. Contact them on a number or address you already had, not by replying to the thread.
- Tell them the facts: which address, which subject or dates, what to do. Don't forward the malicious message as an example.
- Anyone who sent money should call their bank now. Report business email compromise to the FBI at IC3. Getting money back isn't guaranteed.
- Name someone to assess data exposure, plus any duty to notify customers or regulators, with your legal or incident adviser. Don't wait for the technical report before stopping a live fraud attempt.
Whoever runs IT: keep representative copies of the malicious messages, find other internal recipients, then remove or quarantine the copies where your tools allow. Messages already in other organizations' inboxes need their own IT to act. Don't promise you can recall them. [6]
Keep notices factual. Don't say every contact was affected, or that no information was exposed, without evidence. Send them from a safe channel while the mailbox is restricted.
Bring the employee back safely
Whoever runs IT makes the technical call. The owner accepts any remaining business risk.
- Containment steps are done, with results recorded.
- The password plus recovery methods belong to the real employee; two-step sign-in is set up.
- The device they use has been checked, with a recorded decision for any suspected malware.
- A fresh sign-in from a trusted device works under your normal sign-in policy. (A passkey or security key may not show a separate prompt. That's fine.)
- Test messages in both directions arrive where they should.
- Settings match what you expect, with no new suspicious activity in the logs.
- The employee knows to report new prompts, missing mail or customer complaints straight away.
A successful sign-in proves the employee can work. It doesn't prove the intruder is gone: check your clean-up evidence separately.
Sending blocked by the provider because of spam? Finish the clean-up before you ask for the block to be lifted. Re-enabling outbound mail too early lets the attack carry on. [9]
When to bring in outside help
Straight away if an admin account is affected, more than one account is involved, money was sent, sensitive information may be exposed, access keeps coming back, or you can't establish control. Call your IT provider, an incident response firm, plus your cyber insurer's incident line if you have one. Agree who owns containment, investigation, recovery, then set the next update time. Keep containing while you arrange help.
Self-hosted email, organization-wide configuration changes or a suspected server compromise need a specialist. This playbook covers a mailbox, not a whole mail server.
Close it, then follow up
Write down the lead, affected accounts, where the evidence is, the timeline, what you did, the business impact, open questions, plus who approved closing it. Keep the record access-controlled. Never put passwords, recovery codes or tokens in it.
Close only when access is under control, affected services have a recovery decision, the people affected have been contacted, with every open issue given an owner and a deadline. It's fine to close with documented uncertainty. It's not fine to hide it.
Check again the next business day, then within a week. A confirmed compromise may need longer monitoring with your responder. Those are check-in points, not a guaranteed all-clear.
If personal information might be involved, start a short notification log early: who might need telling, by when, under which rule. Let your adviser decide which rules apply.
Stop it happening again
Pick changes that match the cause, then give each one an owner with a date:
- Phishing-resistant sign-in (passkeys or security keys), starting with admins plus anyone who handles money.
- Alerts for new forwarding rules. Microsoft 365 includes alert policies for this; make sure someone actually reads them. [10]
- Tighter app consent, so staff can't approve risky apps on their own. [11]
- Fewer admin rights, with a separate admin account kept for admin work only.
- A call-back rule for payments: any new or changed bank details get confirmed by phone, on a number you already had.
- DMARC on your domain, so nobody can send email that pretends to come from your exact address. [12]
Sources
Checked October 14, 2026. Permissions, logs and controls vary by subscription. This playbook follows NIST SP 800-61 Rev. 3 for incident response, plus the platform guidance below. It's a careful, documentation-based guide, not a certification, and it hasn't yet been exercised in a live environment.
- Microsoft: Respond to a compromised email account
- Google Workspace: Identify and secure compromised accounts
- Microsoft Entra: Revoke user access in an emergency
- FBI IC3: Business email compromise
- Microsoft Entra: App deactivation and existing tokens
- Microsoft: Phishing investigation playbook
- Microsoft Entra: Emergency access accounts
- Microsoft Entra: Review application permissions
- Microsoft Defender for Office 365: Outbound spam protection
- Microsoft Defender: Alert policies
- Microsoft Entra: Configure user consent
- Microsoft Defender for Office 365: Set up DMARC