Business Email Compromise: What It Looks Like and How to Recover

Business email compromise does not encrypt anything. It reads. An attacker with a mailbox login sits quietly, learns who pays whom, and waits for an invoice to intercept. When they act, it is a changed bank account number on a real invoice thread, sent from the real mailbox, and the money is gone before anyone notices.

The recovery has two halves: getting the attacker out of the tenant completely, and finding everything they touched. Both are done in a specific order, and skipping steps means they come back.

What it looks like from the inside

The first sign is usually external: a customer asks why the bank details changed, or a vendor says they never sent that invoice. Inside the tenant, the attacker has left a trail, because the same tricks work every time.

• Inbox rules that move mail to RSS Feeds, Archive or a folder named with a single character, or that delete anything containing 'invoice', 'payment' or the attacker's target's name. The victim never sees the replies.
• Forwarding to an external address, set either as a mailbox rule or as SMTP forwarding on the mailbox itself.
• A consented OAuth application with mail read permissions, which survives a password reset because it uses its own token.
• New MFA methods registered to the account: a second phone number or authenticator the user does not recognize.
• Sign-ins from unfamiliar locations or from a VPN provider's address space, often interleaved with the real user's sign-ins.

Evict the attacker, in this order

A password reset alone does not end a session. Access tokens stay valid, OAuth apps keep their own credentials, and any extra MFA method the attacker added lets them straight back in. Do all of the following for every affected account, and consider every account affected until proven otherwise.

1. Reset the password from the Entra admin center and immediately revoke sessions: Users > user > Revoke sessions. Or in PowerShell: Revoke-MgUserSignInSession -UserId user@domain.com
2. Remove unrecognized MFA methods: Entra admin center > Users > user > Authentication methods. Re-register MFA with the real user on a call.
3. Delete malicious inbox rules: Get-InboxRule -Mailbox user@domain.com | Format-List Name, Description, Enabled and then Remove-InboxRule for each one.
4. Clear mailbox forwarding: Set-Mailbox user@domain.com -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false
5. Revoke consented apps: Entra admin center > Enterprise applications, filter by recently added, and delete anything unrecognized. Check the user's own consents under Users > user > Applications.
6. Check delegated access on the mailbox and remove anything unexpected: Get-MailboxPermission and Get-RecipientPermission.
7. Turn on MFA enforcement through Conditional Access if it was not already, and block legacy authentication tenant-wide.

Connect-ExchangeOnline
# Find every rule in the tenant that forwards or deletes
Get-Mailbox -ResultSize Unlimited | Get-InboxRule | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage } | Format-Table MailboxOwnerId, Name, Enabled
# Find mailbox-level forwarding
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } | Format-Table Identity, ForwardingSmtpAddress, ForwardingAddress

Find out what they did

Once the attacker is out, the question becomes scope. Which mailboxes did they read? Which files did they download? Who else did they email from the account? The Unified Audit Log answers this, provided it was enabled before the incident; it is on by default in tenants created in recent years, but check.

Search the audit log for the affected user across the full retention window. Look for MailItemsAccessed, New-InboxRule, Set-Mailbox, Add-MailboxPermission, FileDownloaded and Consent to application. Export the sign-in log for the same period and match the attacker's IP addresses to activity.

• Purview portal > Audit > New search, filter by user and date range. Or Search-UnifiedAuditLog -UserIds user@domain.com -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).
• Search the Sent Items and Deleted Items folders for messages the user does not recognize, including the Recoverable Items folder the attacker cannot purge without eDiscovery rights.
• If the attacker sent invoices or payment changes, list every recipient and contact them by phone, not by email from the same tenant.
• If any file contained personal data of customers or employees, note it. Counsel will decide about notification obligations.

Close the door for next time

The attacker got in with a password and probably a phished MFA approval. The fix is the same set of controls every time, and if they had been in place the incident would not have happened.

1. Conditional Access: require MFA for all users, require phishing-resistant MFA for admins, block legacy authentication, block sign-ins from countries you do not operate in.
2. Disable user consent to applications: Entra admin center > Enterprise applications > Consent and permissions > Do not allow user consent, with admin consent workflow enabled.
3. Alert on new inbox rules and forwarding: Defender portal > Policies > Alert policy includes 'Creation of forwarding/redirect rule' and 'Suspicious email forwarding activity'. Make sure the alerts go to a mailbox someone reads.
4. Disable external forwarding at the tenant level: Set-RemoteDomain Default -AutoForwardEnabled $false, and use the outbound spam policy to block automatic forwarding.
5. Institute a payment change procedure: any change to a vendor's bank details is confirmed by phone to a number already on file, never to one in the email.

Frequently asked questions

Takeaway

A mailbox compromise is quiet, and the damage is a wire transfer, not a ransom note. Evict the attacker in the right order, search the audit log for what they touched, and then turn on the Conditional Access and consent controls that would have stopped it. Then make bank detail changes a phone call, forever.