How Attackers Use M365 Tenant Branding to Bypass 2FA

Your M365 tenant has a vendor it trusts. That vendor emails you every week. One day the message looks the same as always -- same sender, same format, same logo. The link goes to a page that looks exactly like your tenant login. Your training says to check the sender. The sender is correct. You enter your credentials. The attacker logs in with them in real time, answers your MFA prompt, and is inside your Entra tenant before your session has fully loaded.

This is trusted sender abuse, and it works specifically because it weaponizes the trust your own systems have already established.

The Attack Chain: From Trusted Sender to Live Credential Replay

The attack is not technically complicated, which is partly why it works so reliably. Here is the full sequence.

Step 1: The attacker identifies a trusted relationship

The attacker finds an email address, domain, or service that your M365 tenant has classified as trusted. This might be a vendor who regularly sends invoices, a partner company your IT team has whitelisted, or an internal system that sends automated mail. The specific trust mechanism varies -- it might be an SPF pass, a sender in someone's contacts, or a domain on an allow list in your email gateway. The point is that messages from this source land in inboxes without triggering suspicion.

Step 2: The attacker sends a phishing email from that trusted source

Armed with a legitimate-seeming sender identity, the attacker sends an email with an urgent business premise -- a shared document to review, a password reset request, a notification about a rule that requires attention. The email is crafted to look like it comes from the trusted sender, but the links point to infrastructure the attacker controls.

Step 3: The phishing page uses your own M365 tenant branding

This is the step that makes the attack feel legitimate even to careful users. The phishing page is designed to look exactly like the M365 login portal -- same logo, same colors, same domain structure in the URL bar (or close enough that casual inspection passes). The page is often hosted on infrastructure that spoofs the tenant's actual login subdomain.

Step 4: Credentials are entered and immediately replayed

The target enters their credentials. The attacker does not just store them -- they use them immediately to log into the real Entra tenant. Because the attacker is acting in real time, they can respond to MFA prompts as they arrive. If the tenant uses phone-based MFA, the attacker may have already compromised that channel, or may be positioned close enough geographically that the location signals do not trigger a impossible travel alert.

Step 5: The attacker establishes persistence

Once inside, the attacker moves quickly. They may add a rogue application to the tenant, export the address book, configure mail flow rules to exfiltrate data, or simply read existing email for as long as access remains open.

Why This Technique Bypasses Trained Users

Standard phishing training tells users to check the sender address, look for HTTPS, and verify the URL. Trusted sender abuse specifically defeats these checks because the sender address is legitimate, the URL may be close enough to fool casual inspection, and the attacker has chosen a trusted context specifically to reduce scrutiny.

The attackers also use real business urgency. A phishing email with spelling errors from a random sender gets caught by trained users. A properly formatted message that appears to come from your company's preferred payroll provider, referencing a benefits enrollment deadline, lands differently.

This technique also exploits the trust that Conditional Access policies and email gateways place in previously verified senders. If your email gateway has classified a domain as a trusted sender, it may apply fewer scanning rules to messages from that domain, giving the attacker's email a cleaner path to the inbox.

How to Detect Credential Theft in Real Time

Real-time detection is hard because the attacker is acting from within a legitimate session context. But there are signals that stand out.

Impossible travel

If a user logs in from Berlin at 9 AM and then from Lagos at 9:15 AM, that is not a normal pattern. Sign-in logs in Entra ID show the geographic coordinates, ISP, and ASN of each login attempt. Cross-referencing consecutive sign-ins for impossible travel takes minutes with the right tooling.

New application consents

When an attacker adds an application to the tenant, that application shows up in the Azure/Entra audit logs. Any unexpected application consent, especially to cloud storage or email-related permissions, warrants immediate investigation.

Mail forwarding rules set shortly after a sign-in anomaly

If a sign-in anomaly is followed within minutes by a new inbox rule that forwards messages to an external address, that is a strong indicator that credentials were used. Check the mail trace and the sign-in logs together.

Unexpected device registrations

A new device registered immediately after a suspicious sign-in can indicate that the attacker is trying to establish a more persistent foothold.

Conditional Access Policies That Help

Blocking this attack entirely with one setting is not realistic, but layered Conditional Access policies reduce the window of opportunity.

Require phishing-resistant MFA for high-privilege accounts

FIDO2 hardware keys or Windows Hello for Business are resistant to credential replay because the private key never leaves the device. If your tenant supports it, require phishing-resistant MFA for admin accounts and anyone with access to sensitive mailboxes.

Block sign-ins from unexpected geographic locations and ASNs

If your organization has no legitimate business in Nigeria, block sign-ins from Nigerian IP ranges. If your users never travel to certain regions, those regions can be blocked at the Conditional Access level.

Require compliant device for sensitive workloads

Device-based Conditional Access means an attacker using a non-managed device, even with valid credentials, cannot reach Exchange Online mail or SharePoint without meeting your compliance policy.

Session risk-based steps

Entra ID Protection can flag sign-ins with elevated risk. Combine this with step-up authentication for sensitive apps rather than blocking outright, to avoid disrupting legitimate users who trigger a risk signal.

The Role of Email Authentication in Preventing Trusted Sender Abuse

SPF, DKIM, and DMARC do not stop an attacker who has compromised a legitimately sending system. If the attacker is sending from an actual vendor's compromised SMTP infrastructure, the email will pass SPF, DKIM, and DMARC checks because it is genuinely coming from that vendor's infrastructure.

However, email authentication does help in two ways.

It prevents the initial sender impersonation

If an attacker tries to spoof your vendor's domain without actually compromising their infrastructure, properly configured SPF, DKIM, and DMARC will cause those messages to fail authentication. This means the attack cannot start from a truly fake sender -- it requires either compromising the vendor or finding a trusted relationship that does not use strong email authentication.

DMARC aggregate reports are an early warning signal for trusted sender compromise

If one of your trusted vendors suddenly starts sending from a new ASN, changes their DKIM selector, or begins routing through an unexpected mail provider, your DMARC aggregate reports will show those anomalies before your users report anything suspicious. That is worth treating as a real signal, not just a technical detail.

DMARCFlow aggregates DMARC reports across your domains and flags sending pattern changes from trusted sender domains. When a vendor's infrastructure suddenly behaves differently, that is often the earliest indication that their system was compromised and is being used as a trusted platform for phishing your users. Catching that signal in a DMARC report gives you hours or days of lead time that you would not get from your email gateway alone.

What to Do If You Suspect This Attack Has Succeeded

If you believe credentials have been compromised, act fast.

Immediately reset the affected account's password and revoke all active sessions. In Entra ID, you can force a sign-out from all devices.

Check the audit logs for any actions taken by that account in the past 24 to 48 hours. Look for new application consents, mail forwarding rules, role assignments, or PowerShell activity.

Review and revoke suspicious OAuth applications in the Entra admin center. Attackers frequently add rogue apps as a persistence mechanism after an initial compromise.

Notify your security team and follow your incident response process. If the compromised account had access to sensitive data, you may need to treat this as a data breach.

Notify the trusted sender whose infrastructure was used. If the attack came from a vendor's compromised email system, they need to know so they can clean up their own environment.

Frequently Asked Questions

Can standard MFA like SMS or authenticator app code stop this attack?

SMS and TOTP codes are less effective against live credential replay because the attacker receives the MFA prompt in real time and can answer it. Phishing-resistant MFA (FIDO2, Windows Hello) is the better defense because the private key cannot be intercepted or replayed.

Does this attack work against organizations that do not use M365?

The underlying technique -- using trusted sender relationships to phish credentials with real-time replay -- is not specific to M365. Any identity provider that supports standard OAuth flows and TOTP-based MFA is potentially vulnerable. The M365-specific element is the tenant branding, which makes the phishing page look especially convincing.

Can email authentication prevent all cases of trusted sender abuse?

No. If the attacker has genuinely compromised a vendor's email infrastructure, messages will pass SPF, DKIM, and DMARC. Email authentication prevents sender impersonation but cannot authenticate the intent of a legitimately sourced message. The defense is layered: email authentication stops the spoofing variant, and the controls described above catch the compromise variant.

How can DMARCFlow help with trusted sender abuse?

DMARCFlow aggregates DMARC aggregate reports across your domains and flags anomalous sending patterns from trusted sender domains. If a vendor who normally sends from one IP range suddenly starts sending from a different ASN, that shows up in your DMARC reports. You can use that signal to investigate or warn the vendor before their infrastructure is used in an attack against your users.

---

Trusted sender abuse is not a zero-day. It is a combination of existing techniques used together in a way that specifically defeats the defenses organizations have spent years building. Understanding the attack chain is the first step to building the layered controls that make it harder to pull off. Email authentication does not solve this problem on its own, but it is a useful early warning system when trusted senders start behaving unexpectedly.