Detecting and stopping Business Email Compromise in Microsoft 365

Business Email Compromise (BEC) in Microsoft 365 rarely involves malware. The attack chain involves phishing, session or token theft, inbox rules and OAuth consent abuse. A SOC detects BEC by correlating signals from Entra ID, Exchange Online and Defender for Cloud Apps. The email body alone is insufficient for detection. Responders revoke sessions, remove inbox rules, withdraw OAuth consents and enforce MFA again. They document these actions in line with ISG and insurance requirements.

SOC as a ServiceAllDetecting and stopping Business Email Compromise in Microsoft 365

How this compares to neighbouring topics

This page describes BEC as an attack vector in Microsoft 365. The underlying theft of credential material is described on Token theft and session hijacking. The platform page with Entra ID, Defender XDR and Sentinel is on SOC for Microsoft 365 and Sentinel. Phishing simulation covers the awareness programme and report button. ITDR explains preventive identity detection in detail. What is a SOC defines the service. The full operational picture is in the pillar SOC as a Service Switzerland.

What BEC in M365 is

BEC is a fraud pattern outside the malware category. An attacker takes over or impersonates a legitimate mailbox to carry out payment instructions, supplier changes or data exfiltration. In Microsoft 365, this almost always involves compromised identities. Infected endpoints rarely play a role. The mailbox looks clean, the message comes from the real address, and the signature is correct. That is exactly why email filters on their own fail.

CEO fraud: payment instruction in the name of executive management, often just before the weekend.
Supplier redirection: change of bank details on a real open invoice.
Payroll redirection: change of an employee's salary bank details.
Data exfiltration: targeted external forwarding of sensitive attachments via inbox rule.

The typical attack chain in M365

Phase	What the attacker does	Signal in the tenant
1. Phishing / AiTM	Reverse-proxy phishing (e.g. Evilginx) steals the session cookie despite MFA.	Unusual sign-in location, impossible travel, atypical user agent.
2. Session takeover	Attacker replays the session token, bypasses the MFA prompt.	Entra ID risk detection, non-interactive sign-in without MFA claim.
3. Persistence	Inbox rule for invoices with forwarding to RSS or Deleted Items, OAuth app with Mail.Read.	New-InboxRule, OAuth consent grant, app-only token.
4. Reconnaissance	Reading open invoices, supplier threads, payment runs.	MailItemsAccessed spikes, search query patterns.
5. Execution	Reply into a real thread with changed IBAN or a forged instruction.	Outbound mail to finance, same thread, new payment details.

Rule of thumb

MFA on its own no longer stops BEC. Relying on MFA alone defends against attackers from 2020, not those from 2026.

What a SOC correlates in the tenant

Entra ID: risky sign-ins, impossible travel, atypical countries, non-interactive logons without MFA claim.
Exchange Online: New-InboxRule with forwarding, deletion or RSS folder, Set-Mailbox with ForwardingSmtpAddress.
OAuth consent grants to unknown apps with Mail.Read, Mail.Send, offline_access.
MailItemsAccessed and search-query patterns (invoices, IBAN, payroll, supplier).
Defender for Cloud Apps: anomaly detection on mass download, unusual client apps.
Correlation with user-reported phishing via the report button, see Phishing simulation.

BEC response playbook

Revoke all sessions of the affected user (revokeSignInSessions), enforce password reset.
Inventory inbox and transport rules, remove malicious rules, export a backup first.
Revoke suspicious OAuth consents, revoke app-only tokens, audit Enterprise Apps.
Reset MFA methods, review Conditional Access for phishing-resistant MFA (FIDO2 or CBA) on risk roles.
Notify the finance team directly, actively recall open payments with altered IBAN.
Document the incident per notification duties (revFADP, ISG, FINMA where applicable) and insurer requirements.

Notification duties and insurance

BEC with financial loss usually triggers notification duties under revFADP (revised Federal Act on Data Protection) (data breach where personal data is affected) and ISG for critical infrastructure. Cyber insurers expect documented response steps within hours of discovery; see requirement logic on Cyber insurance and SOC. For concrete 72h response capability see Incident response within 72 hours.

Placement in SOC operations

The pillar SOC as a Service Switzerland describes how BEC detection fits into ongoing 24/7 operations.

Frequently asked questions

Is MFA enough against BEC?

MFA alone is insufficient. Reverse-proxy phishing such as Evilginx bypasses classic MFA (SMS, push, TOTP) by stealing the session after the MFA prompt. Effective controls are phishing-resistant MFA (FIDO2, certificate-based auth) and detection on token usage; see [Token theft and session hijacking](/en/soc/token-theft-session-hijacking).

How fast does a SOC detect a BEC compromise?

A SOC needs properly connected Entra ID and Exchange Online logs. It then detects compromise within minutes to a few hours of the first risk signal or inbox rule. Without sign-in and audit log ingestion, the finance team typically discovers the compromise weeks later. See [MTTD and MTTR in a SOC](/en/soc/soc-mttd-mttr) for the timing logic.

What is the minimum M365 licence tier?

Microsoft 365 Business Premium plus Entra ID P1 provides a practical starting point with baseline Conditional Access. Risk-based detection (risky sign-ins/users) and risk-based Conditional Access policies additionally require Entra ID P2 (Identity Protection). For deeper detection (UEBA, alert policies, MailItemsAccessed) E5 or additional licences are common. Without audit logging enabled, BEC detection cannot be reconstructed.

Is recovering the funds after BEC realistic?

Partial recovery is possible if the recall starts within a few hours and the receiving bank cooperates. After 24 to 48 hours the odds drop sharply. That is why calling the bank belongs in the playbook, not in a later legal phase.

How does BEC relate to awareness training?

Awareness reduces the click rate, but strong BEC waves are convincing enough to hit trained users too. The real value is in the report button: fast user report plus SOC response within minutes. See [Security awareness](/en/services/security-awareness-training) and [Phishing simulation](/en/services/security-awareness-training).

Continue reading in this cluster

SOC for Microsoft 365 and Sentinel: what matters

A SOC for Microsoft 365 and Sentinel environments correlates signals from Entra ID, Defender XDR, Exchange Online and Azure in one detection layer. It responds 24/7. Analysts, playbooks and documented response provide the operational value beyond the licence.

Security awareness training: turning click risk into reporting behaviour

Security awareness training is a measurable behavioural process, beyond a mandatory e-learning module. The target is not a zero click rate but a reporting rate for suspicious mail in the 40 to 50 percent target band before the SOC escalates. ANOMAL combines short role-specific modules, realistic phishing simulations and a reporting interface in Microsoft 365 so awareness becomes a detection source. The 'Regular security awareness training with phishing simulations' requirement of most Swiss cyber insurers is documented in the process.

Incident response within 72 hours

The outcome of a serious cyber incident is decided in the first hours. ANOMAL provides a Swiss incident response team that works within the 72-hour notification window of cyber insurance. It covers first analysis, containment, evidence preservation and communication with insurer, regulator and executive leadership. A retainer is not mandatory but recommended so the clock does not start with the first phone call.

SOC and cyber insurance: what Swiss insurers require

Cyber insurers in Switzerland and the EU increasingly require applicants to evidence security controls. MFA, EDR, segregated backups, a documented incident response plan and a patch process appear on nearly every proposal form. Missing 24/7 detection via a managed SOC or MDR is rarely a formal exclusion. It is a strong premium driver and, in many policies, the only realistic way to meet short policy notification deadlines.

MTTD and MTTR: the two SOC KPIs that count

Mean Time to Detect (MTTD) measures how fast a SOC spots an attack. Mean Time to Respond or Contain (MTTR, MTTC) measures how fast it is stopped. Together they are the only credible evidence that a SOC is working, not just running.

Look up short definitions in the glossary