How-To Guides

Business Email Hacked? What to Do in the First Hour

When a business mailbox is compromised, the order you do things in matters. This runbook walks through the first hour in Microsoft...

Avatar photo Written by Sajal Jain · 9 min read >
Business Email Hacked? What to Do in the First Hour

When a business mailbox is compromised, the order you do things in matters. This runbook walks through the first hour in Microsoft 365 and Google Workspace: lock the account, end sessions, remove forwarding and rules, check MFA and app consents, preserve logs, warn contacts and report.

TL;DR

  • In the first hour: lock the account (disable or suspend it, or reset the password), end every active session, then remove the attacker’s forwarding, inbox rules, MFA methods and app consents. A password reset alone isn’t enough.
  • Check Sent Items and the audit log to work out who the attacker emailed, then warn those contacts by phone or from a different account.
  • Preserve evidence before you clean up too much: export the audit log search and note every change you make, with times.
  • If money or bank details were involved, call your bank straight away, then report it to ASD at cyber.gov.au/submit-a-report.
  • If personal information may have been accessed, you may need to assess it under the Notifiable Data Breaches scheme within 30 days.

Signs a business mailbox has been compromised

ASD’s Australian Cyber Security Centre (ACSC) lists signs like being locked out with the right password, being signed out on every device, sign-ins from times or places you don’t recognise, unexpected password reset emails, changes you didn’t make, and expected emails no longer arriving.

Microsoft adds a few that point straight at business email compromise: inbox rules that forward mail to unknown addresses or move messages into Notes, Junk Email or RSS Subscriptions; suspicious messages in Sent Items or Deleted Items; newly added external forwarding; and an account blocked from sending.

The rule-hiding trick is the one to know. An attacker who wants to intercept a supplier’s reply about an invoice creates a rule that moves anything containing "invoice", "payment" or the supplier’s name out of the inbox, so the real user never sees it.

If you see any of these, treat the account as compromised and start the runbook. Don’t wait for certainty.


Before you start: one person, one log

Pick one person to run this and one place to write down what happens. Note the time you noticed the problem and the time of every action ("10:42 disabled account", "10:45 revoked sessions"). ACSC asks for this detail in a report, your insurer will want it, and it stops two people undoing each other’s work.

Don’t email the affected user their new password, and don’t discuss the incident from the compromised mailbox. Use phone or another channel. Microsoft says this explicitly: the attacker may still have access to the mailbox.


The first-hour checklist

Here is the card version to print and keep with your incident plan. The detail for each step follows.

First hour: compromised mailbox

  1. Lock the account: disable or suspend it, or reset the password. Delete app passwords.
  2. End every active session.
  3. Remove mailbox forwarding.
  4. Remove inbox rules the user didn’t create (include hidden rules).
  5. Remove unknown MFA methods and admin roles.
  6. Revoke unknown app consents and OAuth tokens.
  7. List who the attacker emailed (Sent Items, message trace).
  8. Export the audit and sign-in logs.
  9. Warn contacts by phone or from another account.
  10. Report: your bank if money is involved, ASD (cyber.gov.au/submit-a-report), and assess under the NDB scheme if personal information is involved.

Work through these in order. Steps 1 and 2 cut the attacker off. Steps 3 to 6 remove the ways they would get back in. Steps 7 to 10 deal with the damage.

1. Lock the account

Microsoft 365. Microsoft’s preferred first step is to disable the account while you investigate. In the Microsoft Entra admin center, go to Entra ID > Users > All users, select the user, choose Edit under Account status, clear Account enabled and save. If you can’t disable it (for example, it’s the owner’s mailbox and the business can’t function without it), reset the password to a long, unique one instead.

  • If the account syncs from on-premises Active Directory, reset the password there, twice. Microsoft recommends this to reduce pass-the-hash risk.
  • App passwords aren’t revoked by a password reset. Delete them (Entra admin center, Users > Multifactor authentication > Manage user settings > delete existing app passwords).

Google Workspace. Suspend the user in the Admin console. Google notes that suspending a user resets their sign-in cookies and OAuth tokens. Then reset the password and remove any app passwords.

Check: try signing in as the user from a private browser window. It should fail (disabled or suspended) or demand the new password.

2. End every active session

A new password doesn’t log out an attacker who already holds a valid session token.

Microsoft 365. On the user’s Overview page in the Entra admin center, select Revoke sessions. The PowerShell equivalent is Revoke-MgUserSignInSession -UserId [email protected]. Microsoft notes that access tokens last an hour by default, so some apps may keep access until their token expires. Disabling the account in step 1 covers that gap.

Google Workspace. Suspending the user (step 1) resets sign-in cookies and OAuth tokens. If you can’t suspend the account, reset the password and revoke the user’s OAuth tokens (step 6) as well.

Check: in the Entra sign-in logs (or Google’s user log events), new sign-ins for this user from unfamiliar IP addresses should stop after this point.

3. Remove forwarding

Microsoft 365. In Exchange Online PowerShell:

Get-Mailbox -Identity [email protected] | Format-List Forwarding*Address,DeliverTo*

A value in ForwardingSmtpAddress means mail is being copied to an external address. Turn it off in the Exchange admin center (Recipients > Mailboxes > select the mailbox > Email forwarding > Manage email forwarding) or in PowerShell with Set-Mailbox -Identity [email protected] -ForwardingSmtpAddress $null -ForwardingAddress $null.

Google Workspace. Check the user’s Gmail forwarding settings, and Google’s advice is to confirm filters and forwarding options are configured as the user intended.

Check: run the command again; both forwarding fields should be empty.

4. Remove the attacker’s inbox rules

Microsoft 365. Include hidden rules:

Get-InboxRule -Mailbox [email protected] -IncludeHidden | Format-List Name,Enabled,RedirectTo,Forward*,Identity

Look for rules with odd names (a single character, "..", or a word copied from an existing rule), rules that forward or redirect, and rules that move or delete messages containing words like invoice, payment, bank or a supplier’s name. Before deleting, record each rule’s full details (Get-InboxRule -Identity "<Identity>" -IncludeHidden | Format-List) for your evidence log, then remove it with Remove-InboxRule.

Google Workspace. Review the user’s Gmail filters and delete any the user didn’t create.

Check: run the command again and confirm only rules the user recognises remain.

5. Check MFA methods and admin roles

Attackers often register their own phone or authenticator app so they can get back in after you change the password.

Microsoft 365. In the Entra admin center, open the user and select Authentication methods. Remove anything the user doesn’t recognise. If you’re unsure, Require re-register MFA deletes phone numbers, Microsoft Authenticator registrations and software OATH tokens (and deactivates hardware tokens) so the user sets them up again. It doesn’t remove other methods such as passkeys, so check those individually. While you’re on the user, check Assigned roles and remove any admin role they shouldn’t have.

Google Workspace. Check the user’s 2-Step Verification enrolment and recovery email and phone, and correct anything the user didn’t set.

Check: the methods listed match devices the user can show you.

6. Check app registrations and consents

A more persistent attacker grants a malicious app access to the mailbox. That access survives a password reset.

Microsoft 365. In the Entra admin center, go to Enterprise apps and review apps the user has consented to, especially recently added ones with mail permissions (such as Mail.Read, Mail.ReadWrite or Mail.Send, often alongside offline_access, which keeps access going without a new sign-in). Revoke and remove anything that shouldn’t be there. Also check App registrations for anything created recently that you don’t recognise.

Google Workspace. Revoke the user’s OAuth tokens for third-party apps they don’t recognise.

Check: nothing remains that the user can’t explain.

7. Find out who was emailed

Look at Sent Items and Deleted Items for messages the user didn’t send. In Microsoft 365, use Message trace in the Defender portal to see what left the mailbox in the suspicious period; in Google Workspace, use Email log search. Make a list of every external recipient, and note any message that mentions payments, bank details or attachments.

Check: you have a list of recipients and times, saved outside the compromised mailbox.

8. Preserve the logs

Microsoft 365. Microsoft turns audit log search on by default for Microsoft 365 organisations, but it can be switched off, so confirm it’s on (in Exchange Online PowerShell, Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled should return True). In the Microsoft Purview portal, open the Audit solution, set a date range that starts before the first suspicious activity, choose the affected user, and don’t filter by activity on the first pass (Microsoft’s advice). Export the results to CSV. Audit records are kept for 180 days on most licences (one year for Exchange, SharePoint and Entra activity on E5-level licences), and for core services like Exchange new events typically take 60 to 90 minutes to appear, so run the search again later in the day.

Also export the user’s Entra Sign-in logs for the same period: IP address, location, time and success or failure.

Google Workspace. Export User log events (sign-ins), Email log search results and OAuth log events for the user.

Check: you have exported files stored somewhere the attacker couldn’t have touched, and your log notes the time you exported them.

9. Warn your contacts

Tell the people the attacker emailed, and your regular customers and suppliers, by phone or from a different account. ACSC suggests warning them about payment requests, bank-detail changes and malicious links or attachments. If invoices were involved, tell them to verify any payment details by calling a number they already hold. Our call-back checklist for accounts teams is a useful thing to send them.

If customers or suppliers have lost money, ACSC asks you to encourage them to contact their own bank immediately.

10. Report

  • Money or bank details involved: contact your bank immediately. They may be able to stop transactions.
  • ASD: report it at cyber.gov.au/submit-a-report and keep the reference number (it starts with CIRS-). ACSC’s hotline is 1300 CYBER1 (1300 292 371).
  • Personal information: if the mailbox held personal information (customer details, HR records, health or financial information), you may have a suspected eligible data breach. Organisations covered by the Notifiable Data Breaches scheme must take all reasonable steps to complete an assessment within 30 days, and the OAIC treats 30 days as a maximum. If the assessment finds serious harm is likely, you must notify affected people and the OAIC. Most small businesses with annual turnover of $3 million or less are outside the scheme, but some are covered regardless of turnover, including those that provide a health service and hold health information, and those that trade in personal information. Our guide to the Notifiable Data Breaches scheme walks through the assessment. This is general information, not legal advice.
  • Identity theft: IDCARE (1800 595 160) offers free support.
  • Insurer: if you have cyber cover, notify them early. Many policies have notification conditions.

Would your team know what to do in the first hour? We help you write and rehearse an incident response plan that fits your organisation, so a bad day stays a bad day.


After the first hour

Once the account is locked down and the evidence is saved:

  • Re-enable the account with a new password and fresh MFA registration, set up in person or over the phone.
  • If the mailbox was used to send spam, Microsoft may have blocked it from sending. Remove it from the Restricted entities page in the Defender portal.
  • Work out how the attacker got in. Common answers are a phishing page that captured the password and MFA code, a reused password, or a user approving an MFA prompt they didn’t start. Device code phishing is another route worth ruling out; see our device code phishing guide.
  • Check whether other mailboxes received the same phishing email and whether anyone else clicked.
  • Make sure every account uses MFA, and that admins use phishing-resistant MFA. Turn off automatic external forwarding unless there’s a business reason for it.
  • Protect your domain from spoofing with SPF, DKIM and DMARC. Our Microsoft 365 setup guide has the steps.

A review of your Microsoft 365 tenant after an incident often turns up other gaps: legacy sign-in protocols still on, too many global admins, or no alerting on new forwarding rules. Our Microsoft 365 and cloud security review covers these settings.

Is your Microsoft 365 set up securely? Our Microsoft 365 security review checks sign-in, sharing, email and admin settings against current guidance and gives you a prioritised fix list.


Write it down before you need it

Every step above goes faster when it’s already written down with names and numbers filled in. Our incident response plan template sets out roles, contacts, severity levels, the reporting steps (ASD, the bank, the OAIC assessment) and a log page like the one described above.

Want the editable version? We’ll email you the Incident response plan template (Word). Just ask through our contact form. We won’t add you to any mailing list.

The open version is short enough to fill in now:

  1. Who runs an incident: name, mobile, and a backup.
  2. Who can make changes: the people with admin access to Microsoft 365 or Google Workspace, how to reach them, and a backup if they’re away.
  3. Outside contacts: your bank’s fraud line, your IT or security provider, your insurer’s claims line, ASD’s reporting page (cyber.gov.au/submit-a-report), IDCARE (1800 595 160).
  4. The first-hour checklist: the ten steps above, printed.
  5. Who decides on notification: the person who assesses whether personal information was involved and whether the OAIC must be notified.
  6. Incident log: time, action, who did it, result.

Key takeaways

  • Lock the account and revoke sessions first. A password reset alone leaves sessions, app passwords, rules, MFA methods and app consents in place.
  • Check and remove forwarding, hidden inbox rules, unknown MFA methods and app consents before you hand the account back.
  • Export the audit and sign-in logs early and keep a timed log of every action.
  • Warn the people the attacker emailed, by phone or from another account, and tell them to verify any payment details.
  • Call your bank immediately if money is involved, report it to ASD at cyber.gov.au, and assess any personal information exposure under the NDB scheme.

Sources

Want a second pair of eyes?

Catharsis Cyber Security is a Sydney cyber security company, certified to ISO/IEC 27001:2022. We help organisations protect, test and run their technology, and explain it in plain English.

Written by Sajal Jain
Cyber Security Enthusiast | OSCP | CEH | CHFI | CNSS | Master of IT Security & Master of IT Management Profile

Leave a Reply

Your email address will not be published. Required fields are marked *