How MSPs Can Stop Business Email Compromise Across Client M365 Tenants

The bookkeeper at one of your clients gets an email from a vendor they have worked with for months, asking about an overdue invoice. The message is sent through an existing email thread, the tone sounds right, and the only thing that changed is the bank account on the new payment instructions. 

Nothing about the message looks off, so finance pays it like any other invoice. The fraud surfaces later, when the real vendor asks why the bill is still unpaid. But by then, the money has already moved.

That pattern, an attacker stepping quietly into a live email conversation, is how a lot of business email compromise (BEC) plays out, and it is expensive. According to Guardz’s 2026 State of MSP Threat Report, confirmed BEC incidents ranged from $140,000 to $1.5 million per event.

The IBM 2025 Cost of a Data Breach Report found that phishing was the most common initial access vector, and the global average cost of a breach was $4.44M, making it one of the most expensive threat categories organizations face.

As an MSP, you are defending this same attack across dozens of Microsoft 365 (M365) tenants at once, each with its own users, policies, and gaps. BEC tends to follow a recognizable sequence once an attacker is inside, and that pattern works in your favor. 

If you know what the sequence looks like, you can watch for it across the clients you manage instead of reacting one breach at a time.

How BEC Plays Out Inside an M365 Tenant

Many BEC cases begin with a working login rather than malware on a device. Attackers phish credentials, capture a session token through an adversary-in-the-middle (AiTM) page, or trick a user into approving a malicious app. From there, they gain access to a legitimate account or authenticated session.

Once inside, the attacker typically studies the mailbox to understand payment processes, approval chains, vendor relationships, and invoice workflows. They often establish persistence or concealment mechanisms by taking advantage of built-in features such as inbox rules, forwarding rules, mailbox permissions, or OAuth application access. These mechanisms allow the attacker to monitor communications while reducing the chance of detection.

The attacker waits for a financial thread, inserts a fake payment instruction, and then suppresses the evidence so the victim does not notice. The $1.5 million case Guardz highlighted in the report worked this way, with the attacker monitoring a real payment conversation before injecting a fraudulent request. 

In that incident, the attacker used a spoofed, look-alike domain to slip into the existing thread, which let the message ride on the trust the participants had already built and skip the usual external-sender suspicion.

The signals BEC produces are consistent enough to build detection around: a sign-in from an unexpected location or device, a new inbox rule that forwards or hides mail, a delegate added to a mailbox, or a sudden block on messages from your IT domain. 

None of these confirms compromise on its own, but if observed continuously and in combination, they give you something to act on before money leaves a client’s account. And because the pattern can repeat across tenants, you can apply the same detection logic across your entire portfolio rather than diagnosing each incident from scratch.

Tighten Authentication With Conditional Access

BEC attacks are easier to execute when authentication mechanisms are weak. The scale of the threat against weak authentication is massive. According to the Microsoft Digital Defense Report 2025, identity-based attacks rose by 32% in the first half of 2025. To combat this surge, Microsoft’s defense infrastructure now processes more than 100 trillion security signals daily.

In light of this, one of the first places to focus your efforts on is conditional access. In M365, conditional access lets you decide who can sign in, from where, on what kind of device, and under which conditions. 

When you’re an MSP, it helps to establish a baseline set of policies you can apply the same way across client tenants, rather than configuring each one on an ad-hoc basis. A small library of policy templates you deploy at onboarding gives you that consistency and a record of what each tenant should look like.

Prioritize the following policies:

• Block legacy authentication protocols that bypass modern multi-factor authentication.
• Require phishing-resistant MFA, such as FIDO2 security keys or passkeys, for finance and administrative accounts.
• Apply device and location conditions so sign-ins from unmanaged devices or unusual locations face additional checks or are blocked.
• Shorten session lifetimes for sensitive roles so stolen tokens have a smaller window of usefulness.

OAuth consent deserves the same scrutiny as sign-ins. Attackers abuse the consent screen by tricking users into granting applications access to mailboxes, files, contacts, and other business data. A user who approves a malicious app can hand over persistent access that survives a password reset and sidesteps MFA.

Treat app consent as a security control:

• Restrict which apps users can approve on their own.
• Review consent grants on a schedule.
• Flag new grants the way you would flag a new admin account.
• Standardize consent controls across tenants.

By standardizing these settings, you can close a gap that password hygiene alone leaves open.

Detecting MFA Bypass and Token Theft

MFA stops many attacks, but it should not be treated as the final control. Two common methods allow attackers to get around MFA protections, and both leave traces that MSPs can monitor across client tenants.

The urgency for this monitoring is underscored by recent data from the IBM X-Force 2025 Threat Intelligence Index: Identity-based attacks accounted for 30% of all security intrusions, with adversaries increasingly opting to “log in” using valid credentials rather than attempting to “break in” through technical exploits.

Legacy Authentication Bypass

The first method is legacy authentication. Older protocols that predate modern sign-in can accept a username and password without ever prompting for a second factor. Attackers know this and deliberately target those paths.

In its 2026 analysis, Guardz counted 114,827 successful sign-ins where MFA was bypassed through legacy authentication. Each successful sign-in represents an account that an attacker could potentially read, send from, and configure rules on without triggering an MFA prompt.

That figure looks surprising because Microsoft disabled basic authentication for most Exchange Online protocols in 2022 and 2023. The block was never total, though. SMTP AUTH was left out of that change and stays enabled in many tenants for printers and line-of-business apps, and others still have gaps where legacy paths were never fully enforced. 

As an MSP, disabling legacy authentication across client tenants should be one of your high-priority fixes. You can enforce that by using conditional access as the control layer.

Session Token Theft

The second method is session token theft, usually through adversary-in-the-middle phishing. In this attack, the attacker proxies the real login page, lets the user complete MFA, and steals the resulting session token. Because the token is already authenticated, the attacker can reuse it without triggering another MFA prompt.

This cannot be detected reliably at the password layer, so monitoring has to focus on behavior after authentication. Suspicious signals include: 

• Impossible-travel sign-ins 
• Sessions resuming from a new IP range or device
• The same account appearing active in two distant locations
• Token use that does not match the user’s normal pattern

These signals show why identity monitoring matters. Conditional access may allow the initial authenticated session, but post-login behavior can still reveal that the session is being used by an attacker.

Monitoring Mailbox Rules for BEC Persistence

If there is one signal to prioritize in BEC detection, it is the creation of suspicious mailbox rules. Guardz found that inbox rules remain the number one persistence mechanism in BEC attacks. The reason is simple. An attacker who controls a mailbox does not want the real user to notice, so they build rules that quietly route and hide the messages that would give them away.

A handful of rule patterns come up again and again: 

• A forward-and-delete rule sends any message containing words like invoice or payment to an external address, then deletes the copy. 
• A move-to-RSS rule shifts inbound mail into the RSS Feeds or an Archive folder where nobody looks. 
• A mark-as-read rule keeps targeted emails from showing as new. 
• A block-sender rule silences messages from your IT or security team, or from password-reset services, so warnings never reach the user.

Delegate grants and send-on-behalf permissions deserve the same attention. A delegate can read, send, and delete mail without leaving a copy in any sent folder the attacker controls, which makes it stealthier than forwarding. 

Across many tenants, manually checking each mailbox for these changes does not scale. So the practical approach is to pull mailbox audit logs and alert on rule creation and permission changes as they happen. 

Responding to BEC Across Your Tenants

So what do you do when prevention fails on one of your tenants? You can apply these steps:

1. Cut off the attacker’s active access. Revoke the user’s sessions and tokens, not just the password, because a stolen token stays valid until it is killed. Then reset the password and check the recovery settings, since attackers often add a recovery email or a second authentication method to keep a way back in even after a reset.
   
2. Undo the persistence. Remove any inbox rules the attacker created, strip out delegate grants and forwarding, and confirm that no malicious app still holds consent.
   
3. Review the audit log. If audit logs are available, check what was read, sent, or changed during the access window. Logs can show whether a fraudulent payment request went out, who received it, whether the client should be notified, and, if a payment has already moved, how quickly to involve their bank.
   
4. Verify payment changes through a separate channel. Any change to payment details or unusual wire request should be confirmed through a separate channel, such as a phone call to a known number, rather than a reply to the email thread itself.
   
5. Document the response as a playbook. Because this response runs the same way on each tenant, write it down as a playbook your team can follow under pressure rather than improvising every time.

Making BEC Defense Repeatable at Scale

All of this is doable tenant by tenant. The hard part is doing it consistently across a portfolio without standing up a dedicated team for each client. That is where a platform built for multi-tenant work helps, and where Guardz fits the picture described above.

Guardz ITDR continuously monitors user behavior across Microsoft 365 and Google Workspace, correlating the same signals BEC produces: suspicious logins, impossible travel, MFA status, credential and token abuse, and mailbox rules. Those signals are mapped to the real user and pulled into a single incident timeline, an approach Guardz calls Identity-Centric Incident Management, so an analyst sees the whole attack path instead of scattered alerts.

Email protection, built on embedded Check Point and deployed through Microsoft and Google APIs, screens inbound phishing and BEC, flags impersonation by checking alias mismatches against a sender’s history, and surfaces suspicious mailbox rules in the same console. Guardz MDR adds 24/7 detection and response with agentic triage and human analysts who can suspend a compromised account, keeping the MSP informed throughout.

Closing Thoughts: The Pattern Is Known, the Defense Has to Match It

BEC is not going away, and attackers are already moving toward OAuth abuse and Graph API manipulation as inbox rules get easier to catch. The MSPs who handle it well are the ones who treat the post-login sequence as a known pattern, monitor for it across their tenants, and respond from a playbook. 

Build that once, apply it across your portfolio, and a $1.5 million email thread becomes a contained incident instead of a client’s worst week.