Microsoft 365 Phishing Attacks: A Defense Guide for IT Teams
Microsoft 365 sits at the center of corporate identity for most mid-market and enterprise organizations. A single compromised M365 credential gives attackers Outlook, SharePoint, OneDrive, Teams and often a path deeper into Azure AD itself. That blast radius is why M365 is consistently the most-targeted platform in published phishing reports - and why a phishing simulation program that does not address M365-specific attack patterns leaves the largest hole open.
This post walks through the four M365-specific attack patterns IT teams need to defend against, why standard MFA does not stop two of them and how to design phishing simulation training that reflects the real attack surface.
The four M365-specific attack patterns
1. Fake Sign-In Page (the classic)
An email or SharePoint document directs the user to a page styled to look like login.microsoftonline.com. The user enters their credentials. The page either captures the password and replays the error ("Wrong password, try again") to disguise the harvest or it forwards the user to the real Microsoft login afterward to make the experience feel normal.
Defense: phishing simulation programs that include cloned M365 sign-in templates train employees to check the URL bar before entering credentials. Most modern platforms ship with these templates as a standard category - see the broader piece on effective phishing email templates for the full template-category breakdown.
2. Consent phishing (OAuth grant abuse)
Consent phishing is the M365-era evolution of credential theft, and it is more dangerous than the classic pattern because MFA does not stop it.
The attacker registers an app in their own Azure AD tenant with permissions like Mail.Read, Files.Read.All, or offline_access. They send a victim a link that triggers the OAuth consent prompt for that app: "App XYZ wants permission to read your mail and files. Allow / Cancel." The user clicks Allow because the prompt looks legitimate (it is - Microsoft is rendering the consent screen). The user never types a password. MFA never prompts. The attacker now has refresh tokens that work indefinitely until either the user or an admin explicitly revokes the grant.
Defense: the user has to recognize the consent prompt itself as the attack surface. Training has to teach: read the publisher name, refuse anything not on a known allowlist, escalate to IT for any consent prompt that looks unfamiliar. Admin-side: restrict OAuth consent to admin-only or to a verified-publisher allowlist via Azure AD's "User consent settings."
3. AiTM (Adversary-in-the-Middle) reverse-proxy phishing
AiTM uses a reverse-proxy phishing site that sits between the user and the real Microsoft login. The user enters credentials and completes MFA on the proxy; the proxy forwards both to Microsoft in real time, captures the resulting session cookie and ships it to the attacker. The attacker imports the cookie and logs in as the user - bypassing MFA entirely.
Tools like Evilginx and Caffeine have made AiTM accessible to non-elite attackers since 2022. The shift in the threat landscape is significant: many organizations relied on MFA as the answer to phishing for the previous decade. AiTM resets that assumption.
Defense at the technical layer: phishing-resistant MFA (FIDO2 / WebAuthn / passkeys) defeats AiTM because the cryptographic challenge is bound to the legitimate origin - a proxy on a different domain cannot complete the challenge. Defense at the human layer: simulation training that includes the exact AiTM lure pattern (mismatched URL on a Microsoft-styled page) so employees recognize and report.
4. Teams and SharePoint phishing (the "trusted surface" lures)
External Teams chats from an attacker-controlled tenant arrive as in-product chat invitations that bypass email gateway filtering entirely. They look exactly like internal Teams messages - same UI, same notification chrome - and most users have not been trained to question them.
SharePoint phishing typically uses a malicious document hosted on a legitimate-looking tenant.sharepoint.com subdomain. The document asks the viewer to "Sign in to access" - and the sign-in form behind that link is one of the M365-specific attack patterns above (fake Sign-In, consent phish or AiTM).
Defense: multi-channel phishing simulation that includes Teams-style lures and SharePoint document-share lures, not just email. Most platforms now support Teams-channel simulations or at least template categories that mimic the visual pattern. Pair with the broader piece on auto-assigned phishing training so users who fall for the lure receive immediate context-specific remediation.
Where MFA still helps and where it does not
Standard MFA (SMS code, TOTP authenticator app, push notification) stops password-only theft from credential-harvesting pages. That covers the classic fake Sign-In Page attack reasonably well.
Standard MFA does NOT stop consent phishing (no password is involved) or AiTM (the proxy completes MFA in real time). Phishing-resistant MFA - FIDO2 hardware keys, platform passkeys, certificate-based authentication - does stop both, because the cryptographic ceremony is bound to the legitimate origin.
The practical recommendation: roll out FIDO2 / passkeys for high-privilege accounts (admins, finance, executives) first, then expand. Track the rollout in your executive phishing-program metrics as a separate KPI.
Program design for M365-heavy organizations
If your workforce lives in M365 (true for most enterprises today), the phishing simulation program should reflect that reality. Concrete design choices:
- Template mix: M365-themed templates should be at least 30% of campaigns. Mix the four attack patterns (sign-in clone, consent prompt, AiTM-style mismatched URL, Teams/SharePoint lure) - not just one.
- Difficulty progression: easy = obviously-wrong sender domain on a fake sign-in. Hard = visually-perfect AiTM proxy with a domain that looks correct at a glance (typosquat or homograph).
- Auto-assigned remediation: the training module that fires after a user clicks should be specific to the lure category. A user who fell for a consent phish needs different training than a user who fell for a fake sign-in. Auto-assignment based on the lure category is what makes this scale.
- Reporting that names the categories: the executive packet should show click rate per M365-attack-category, not just an aggregate. Boards and insurers ask: "do your users still fall for consent phish?"
For cyber insurance + compliance buyers
Cyber insurance carriers in 2026 ask about M365 specifically as part of phishing-program due diligence - see the cyber insurer renewal walkthrough for the full question list. The presence of M365-specific simulation evidence in your renewal packet is often weighted favorably in underwriting because it signals your program reflects the real attack surface, not a generic one.
SOC 2 and HIPAA auditors are starting to ask the same. Both want to see that the security awareness program addresses where your users actually live; for the majority of organizations that means M365.
Where Bait & Phish fits
Bait & Phish ships with cloned Microsoft 365 sign-in templates as a standard category, plus generic Outlook, SharePoint and Teams-styled lures across the three difficulty tiers. Auto-assigned training fires the moment a user clicks. Multi-channel coverage means you can run M365-themed campaigns on email, SMS and voice in the same program. Start a free trial up to 25 users and run an M365-themed campaign in your environment, or contact us if you want to walk through the M365-specific template library.
This post is informational. Specific Conditional Access, Azure AD app-registration and FIDO2 rollout decisions are organization-specific - consult your identity team or Microsoft FastTrack engineer for tailored guidance.
See also: Phishing Trends 2026 - annual roundup covering AiTM commoditization, AI-generated lure quality, collaboration-tool phishing, ransomware dwell-time compression and other patterns that defined the year.