Attackers use SharePoint phishing by placing malicious files, fake login pages or deceptive links on SharePoint sites that appear legitimate to recipients. Because the platform is widely trusted, users may accept the content without scrutiny. Defenders should monitor sharing permissions, external access and unusual file uploads, and review links that lead from SharePoint to credential collection sites.
How SharePoint phishing works as an attack path
sharepoint phishing is effective because the lure is hosted on a familiar, trusted collaboration platform. Attackers can place a convincing file, page, or link inside a real SharePoint tenant, then rely on normal trust in the domain, branding, and shared access patterns to lower suspicion. The attack is less about breaking SharePoint itself and more about abusing its legitimacy as a delivery channel.
That matters because users often treat internal collaboration spaces as safer than email or random websites. When a SharePoint item looks like a routine document, shared folder, or login prompt, it can bypass the quick scepticism that would otherwise block a phishing attempt. NHIMG’s Phishing Guide covers how trusted platforms and other phishing patterns are used to create that false sense of safety.
In practice, the lure usually tries to move the victim to the next step in the kill chain: opening a malicious file, following a link to a credential harvesting page, or entering credentials into a fake sign-in flow that looks consistent with Microsoft branding. Once the victim engages, the attacker can collect credentials, tokens, or other access material and then pivot into mailbox, document, or cloud access.
Why SharePoint is attractive to phishers
SharePoint is attractive because it sits inside ordinary business workflows. A document shared from a real tenant can appear more credible than a standalone phishing domain, especially when the attacker uses a legitimate-looking filename, a familiar icon, or a page that mimics an internal process such as policy review, invoice approval, or shared document access. That trust advantage can materially improve click-through and credential capture rates.
Attackers also benefit from the fact that collaboration platforms are built for sharing. If a SharePoint item is sent through a shared link or embedded in another trusted channel, recipients may assume it has already been vetted. The result is a social-engineering advantage built on the platform’s normal purpose, not on any single technical vulnerability. Top 10 Phishing Techniques is a useful companion for understanding the common lure types used in these campaigns, including trusted-site abuse and consent-style phishing.
SharePoint phishing also blends neatly with other attacker techniques. A malicious file can deliver malware, a deceptive link can drive the victim to a credential prompt, and a shared document can be used to stage follow-on social engineering. That flexibility is what makes the technique durable: the delivery channel can change while the trust abuse stays the same.
What defenders should watch for in SharePoint-based lures
Defenders should focus on the control points that reveal abuse of the sharing workflow, not only on the final phishing page. Unusual external sharing, sudden public-link creation, anonymous access where it is not expected, and high-volume uploads into otherwise quiet sites are all signals worth reviewing. Suspicious filename patterns, newly created pages, and links that redirect from SharePoint to a credential collection site deserve similar attention.
It is also important to distinguish legitimate collaboration from abuse of legitimate collaboration. A campaign can originate from a real tenant, use a real shared folder, and still be hostile. That makes logging, tenant-level auditing, and link review essential, because the platform’s trust properties are exactly what the attacker is trying to exploit. CISA cyber threat advisories are a good reference point for broader phishing and credential-theft patterns that often accompany these lures.
When the lure is tied to Microsoft identity workflows, defenders should be alert for OAuth consent abuse, fake sign-in pages, and token theft rather than only username-and-password harvesting. In those cases, the attack objective is often persistent access, not a one-time credential capture. CoPhish OAuth phishing via Copilot Studio illustrates how phishing can be adapted to token theft and consent abuse in Microsoft-centric environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | SharePoint phishing is a phishing delivery technique that abuses trusted collaboration content. |
| Recommendation — Map SharePoint lures to phishing techniques and tune detections for trusted-site abuse. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excessive sharing and broad access make malicious SharePoint content easier to reach. |
| AU-6 — Audit Review, Analysis, and Reporting | Abuse is best detected by reviewing SharePoint sharing, uploads, and link activity. | |
| Recommendation — Limit SharePoint access and sharing to the minimum required audience. Review SharePoint audit events for unusual sharing, uploads, and redirect chains. | ||
| NIST SP 800-63 | 5.2.8 — Phishing Resistance | SharePoint phishing often aims to harvest credentials through fake login pages. |
| Recommendation — Prefer phishing-resistant authentication for users exposed to SharePoint-delivered lures. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfigured sharing and access settings can let hostile SharePoint content spread more widely. |
| Recommendation — Harden sharing and access settings that let untrusted content reach users. | ||
Practitioner Guidance
What to prioritise: Prioritise the sharing paths that most often bypass user suspicion, especially externally shared documents, public links, and sites with broad write permissions. The most useful review is usually not “is SharePoint allowed?” but “which SharePoint content can reach users without strong review or provenance checks?”
What to verify: Verify whether suspicious content was merely hosted in SharePoint or whether it also led to credential capture, token theft, or downstream login abuse. If the lure included a fake sign-in or consent flow, treat the incident as identity compromise risk, not just a phishing click. For Microsoft-centric phishing, NIST SP 800-63 Digital Identity Guidelines is the most relevant external anchor for phishing-resistant authentication expectations.
Common mistake: Do not assume a trusted platform means a trusted file or link. The attacker’s advantage is that the hosting location looks routine, so teams that only score external domains will miss abuse that originates inside a legitimate collaboration tenant.
Practitioner takeaway: The decisive control is provenance and sharing hygiene, because SharePoint phishing works by borrowing trust from the platform itself, not by making the lure obviously malicious.