The Rise of SharePoint Phishing

Introduction

SharePoint has become the “front door” to modern work. It’s where teams store files, collaborate on projects, publish internal pages, and access shared resources. That popularity has also made SharePoint, and Microsoft 365 login flows around it, an irresistible theme for phishing. Users are conditioned to trust SharePoint links, open documents quickly, and sign in when prompted. Attackers know this, and they’re increasingly pairing believable SharePoint-themed lures with a more advanced technique: adversary-in-the-middle (AiTM) phishing.

Traditional phishing tries to steal a username and password and hopes the attacker can reuse them later. AiTM phishing is more dangerous because it aims to steal something better than the password: the authenticated session. In many AiTM scenarios, a victim can complete MFA and still get compromised, because the attacker captures the session cookie or token that proves the user already passed MFA. Microsoft has highlighted this shift as MFA adoption grows: attackers move “up the stack” and target the session itself instead of only the credential.

Why SharePoint is such an effective lure

SharePoint-themed phishing works because it blends naturally into everyday workflows. A message that claims “You have a new shared file,” “A document was uploaded,” or “Access requested for this folder” fits perfectly into how users collaborate. That credibility is amplified when attackers mimic Microsoft branding, reference OneDrive/SharePoint terminology, and include a link that looks like it belongs in a business context.

There’s also a practical reason attackers like SharePoint lures: SharePoint access often implies broader Microsoft 365 access. If an attacker obtains a valid Microsoft 365 session, that session can open the door to Outlook, Teams, OneDrive, and other cloud resources, exactly why AiTM campaigns are frequently used as entry points for follow-on activity like business email compromise (BEC).

What “adversary-in-the-middle” means in plain English

AiTM is best understood as a “malicious middleman.” Instead of sending a victim to a fake login page that simply records what they type, AiTM places an attacker-controlled service in between the victim and the real sign-in service.

In many cases, the phishing site acts like a reverse proxy: it relays the victim’s traffic to the legitimate Microsoft sign-in endpoints in real time, while secretly observing (and often modifying) the conversation. Suppose the victim enters valid credentials and completes MFA, the legitimate service issues an authenticated session (often represented through cookies/tokens). The attacker’s proxy captures that session material, allowing the attacker to reuse it and “become” the victim, often without needing to prompt MFA again. Microsoft describes AiTM phishing as an attempt to obtain a user’s session cookie so the attacker can skip authentication and act as the user.

This is why people sometimes say AiTM “bypasses MFA.” MFA still worked; the user really did approve a second factor, but the attacker stole the proof of that success and replayed it.

The role of AiTM “kits” and tooling

AiTM phishing has been accelerated by toolkits and “phishing-as-a-service” ecosystems that lower the barrier for attackers. Microsoft has documented how these kits are bought, rented, and scaled for high-volume campaigns, often with features designed to evade detection and improve success rates.

In security conversations, you’ll often hear names like Evilginx2 (sometimes misheard as “Evil Jinx”) and EvilProxy referenced as examples of AiTM tooling. At a high level, these tools are associated with proxy-based phishing approaches intended to capture credentials and session cookies so the attacker can reuse the authenticated session.

Defenders don’t need to know how to run these tools to protect against them, but it is important to recognize what they change about the threat model:

• Credential theft isn’t the end goal; session theft is.
• MFA prompts aren’t always a reliable “stop sign.”
• Detection needs to focus on sign-in context, token use, and post-auth behavior, not just the login screen.

Why MFA alone isn’t enough (and what actually is)

It’s tempting to react to AiTM by concluding “MFA doesn’t work.” That’s the wrong lesson. MFA remains one of the best security upgrades an organization can make, but attackers have adapted. The real lesson is that organizations should raise assurance for high-risk access and reduce the value of stolen sessions.

Microsoft’s direction in this area is clear: move toward phishing-resistant authentication methods and enforce them using Conditional Access and authentication strengths.

Phishing-resistant methods (like FIDO2/passkeys and certain certificate-based approaches) are designed so that an authentication response can’t simply be captured and replayed from a lookalike site in the same way traditional factors can. Microsoft provides planning and deployment guidance for phishing-resistant passwordless authentication and notes that these methods are built to deflect phishing attempts more effectively than traditional MFA.

Practical controls that reduce AiTM risk

Most organizations can’t flip a switch overnight and become passwordless everywhere. The good news is you can meaningfully reduce exposure with a layered approach that targets the attacker’s leverage points: initial lure, session capture, session reuse, and persistence.

Here are high-impact steps that work well together (minimal bullets, because the details matter more than the list):

• Require phishing-resistant MFA for privileged users and sensitive apps. Start with admins, finance, and anyone with mailbox delegation or payment authority, then expand. Microsoft documents how to require phishing-resistant MFA using Conditional Access.
• Use Conditional Access to bind access to “good context.” Enforce compliant devices, trusted locations, and risk-based sign-in controls so a stolen session from an unusual device/IP is less useful. (Even when attackers steal a session, they still have to use it.)
• Tighten session policies thoughtfully. Limiting long-lived sessions and requiring reauthentication in risky scenarios can shrink the window in which a stolen session remains valuable.
• Improve visibility and detection around token/session abuse. AiTM detection often shows up as “something is off” in sign-in logs: suspicious IPs, unfamiliar devices, anomalous token activity, or unexpected access patterns. Microsoft Sentinel guidance and Microsoft security research discuss investigating and detecting AiTM-style campaigns.
• Harden email and user decision points. Since SharePoint-themed phish is delivered through messaging, invest in safe-linking, attachment protections, and user coaching that focuses on verification habits, not fear.

Where SASE and Zero Trust fit in

The conversation you had about SASE and Zero Trust is directly connected to this trend. AiTM is an identity-centric attack: it succeeds when an attacker can present themselves as a trusted user session. Zero Trust assumes that identity and sessions must be continuously validated, not simply trusted after the first login. SASE architectures support this by pushing consistent access controls closer to where users work, combining capabilities like secure web gateways, CASB, and zero trust network access (ZTNA) to enforce policy across cloud and web traffic.

In plain terms: if email is the “delivery mechanism” and AiTM is the “session theft method,” then Zero Trust and SASE are part of the long-term answer because they help you continuously evaluate access, limit blast radius, and make stolen sessions harder to convert into business impact.

The takeaway for organizations

SharePoint-themed phishing isn’t new. What’s changed is the quality of the trap and the attacker’s target. With AiTM, the attacker doesn’t just want what users know (passwords). They want what the cloud trusts (sessions). Microsoft and other defenders are tracking this as a growing, MFA-era phishing technique, and the most effective response is not abandoning MFA, but upgrading to phishing-resistant authentication where it matters most, enforcing smarter Conditional Access, and building detection around session and token misuse.