Your email security stack was built to catch bad links. SharePoint phishing does not send you a bad link. It sends you a real one, hosted on a real Microsoft domain, with a real authentication prompt sitting behind it. We have watched this attack pattern move from a niche technique to one of the most reliable ways into mid-market networks, and it works precisely because every control your team built is looking for the wrong signal.
Here is the problem in one sentence: your filters are trained to flag malicious domains, and this attack does not use one.
Why SharePoint Phishing Bypasses Traditional Filters
- The domain is real. A link to sharepoint.com or onedrive.live.com will not trigger a reputation-based block, because Microsoft’s own infrastructure is hosting the payload.
- The certificate is valid. TLS inspection sees a properly signed Microsoft certificate, so there is nothing to flag at the connection layer.
- The file preview looks native. Attackers upload a lure document to a compromised or trial SharePoint tenant, and the shared file preview renders inside Microsoft’s own UI.
- The credential harvest happens one click later. The actual phishing page, usually a fake Microsoft 365 login, is not hosted on SharePoint at all. It is one redirect away, and by then the user has already trusted the chain.
- MFA fatigue does the rest. Once credentials are captured, we are seeing a high rate of push-bombing against Microsoft Authenticator to complete the session takeover before the victim thinks to report anything.
We are not describing a theoretical gap. We have responded to incident cases in the last two quarters where the initial access point was a SharePoint share notification that passed through Exchange Online Protection, Defender for Office 365, and a secondary email gateway without a single flag.
What We Are Seeing in the Wild
The pattern is consistent enough now that we can describe the attack chain step by step.
The Lure Is a Shared Document, Not a Link
The email itself is minimal. It states that a document has been shared, usually framed as an invoice, a contract, or an HR form. There is no urgency language, no spoofed sender name, and no attachment. This is deliberate. Attackers know urgency cues and attachment scanning are what your filters are tuned to catch, so they remove both.
- What we recommend: Treat unexpected SharePoint or OneDrive share notifications as a distinct risk category, not a subset of general email, and apply conditional access rules that challenge the session before the document renders.
The Redirect Chain Is the Actual Attack Surface
Once the user opens the shared file, the document contains a second link, often disguised as a “View Document” button. This link exits Microsoft’s domain and lands on an attacker-controlled page built to mirror the Microsoft 365 login screen pixel for pixel. Some campaigns route this through a legitimate URL shortener or a compromised WordPress site to add a second layer of trusted-domain camouflage.
- What we recommend: Enforce FIDO2 security keys or platform authenticators for privileged and finance-adjacent accounts. Phishing-resistant MFA is the only control in this chain that holds regardless of how convincing the lure is, because a cloned login page cannot pass a hardware key challenge.
Detection Has to Move to Behavior, Not Signatures
By the time a signature-based tool identifies the payload domain, the credentials are usually already compromised. The organizations recovering fastest from this attack are not the ones with the best filters. They are the ones with session monitoring that flags impossible travel, new device sign-ins, and mailbox rule changes within minutes rather than hours.
- What we recommend: Deploy continuous access evaluation in Entra ID and pair it with SIEM alerting on new inbox rules, since attackers almost always create a forwarding rule immediately after account takeover to maintain visibility even after the password is reset.
This is the core of the argument we have been making to CISOs all year: containment before detection. You cannot rely on catching the phishing email. You have to assume one will land, and build the access architecture so that a single compromised credential does not become a domain-wide incident.
Frequently Asked Questions
What makes SharePoint phishing different from a normal phishing email?
The link itself is genuine. It points to a real Microsoft domain like sharepoint.com or onedrive.live.com, so reputation-based filters and TLS inspection have nothing to flag. The malicious page only appears one redirect later, after the user has already trusted the chain.
Can Microsoft Defender for Office 365 stop this attack?
It can catch some variants, but not reliably. We have seen this attack chain pass through Defender for Office 365, Exchange Online Protection, and a secondary email gateway without triggering a single alert, because the initial notification contains no malicious payload at the point of scanning.
- Why: Signature and reputation-based tools are scanning the wrong layer. The risk is in the redirect chain and the credential harvest, not the initial link.
Does user awareness training actually help against SharePoint phishing?
It helps, but it is not sufficient on its own. The lure emails are deliberately stripped of urgency language and spoofed sender names, the two things most training programs teach users to watch for.
- What we recommend: Train users to treat unexpected share notifications as a distinct category worth pausing on, not just “another link,” and pair that training with technical controls that do not depend on the user making the right call every time.
What is the single most effective control against this attack?
Phishing-resistant MFA, specifically FIDO2 security keys or platform authenticators, on privileged and finance-adjacent accounts.
- Why: A cloned login page can capture a password and a push-based MFA approval, but it cannot pass a hardware key challenge. This is the one control in the chain that holds regardless of how convincing the lure is.
How do I know if an account has already been compromised through this method?
The fastest indicator is a new inbox forwarding rule, since attackers create one almost immediately after account takeover to maintain visibility even after a password reset.
- What we recommend: SIEM alerting on new mailbox rule creation and Entra ID continuous access evaluation for impossible travel or new device sign-ins, so the account is flagged in minutes rather than discovered after data has already left the mailbox.
The Takeaway
SharePoint phishing is not a training failure and it is not a filter failure in the traditional sense. It is a design failure in how most mid-market networks still treat identity as a one-time gate instead of a continuously verified state. The fix is not a better email banner warning users to “verify the sender.” The fix is phishing-resistant MFA on anything that matters, conditional access that treats unexpected file shares as a risk signal, and behavioral monitoring that catches the account takeover in minutes, not after the forwarding rule has already exfiltrated three weeks of email.
If your current stack is still relying on domain reputation to catch this, you are already behind. We would recommend a review of your conditional access policies and MFA enforcement before your next SharePoint notification becomes your next incident report.
SharePoint Phishing Defense and Identity-First Security Architecture Expertise from Matt Rosenthal
Matt Rosenthal, CEO of Mindcore Technologies, has over 30 years of experience helping mid-market organizations build the access architecture that contains a SharePoint phishing compromise before it becomes a domain-wide incident, because the attack passes through Exchange Online Protection, Defender for Office 365, and secondary email gateways without a flag and the credential harvest happens one redirect away from a real Microsoft domain that every reputation-based filter is trained to trust. He has seen firsthand how organizations relying on signature detection to catch this attack pattern discover the account takeover only after the forwarding rule has already exfiltrated three weeks of email, because by the time any signature-based tool identifies the payload domain the credentials were already captured and the attacker had already completed a push-bombing sequence against Microsoft Authenticator. Matt leads a team that enforces FIDO2 security keys and platform authenticators on privileged and finance-adjacent accounts so a cloned login page cannot complete the session regardless of how convincing the lure is, deploys continuous access evaluation in Entra ID paired with SIEM alerting on new inbox rule creation, and treats identity as a continuously verified state rather than a one-time gate that an attacker needs to pass only once.
