SharePoint, Structurally Quiet

Scope note

This is a pattern-level analysis of on-premises Microsoft SharePoint Server as a product platform, drawn from its documented architecture and from general experience assessing document-management estates in regulated Indian sectors. No specific incident, organisation or dataset is referenced, implied or discoverable from this page. Where concrete events are cited, they are public vendor and regulator publications (MSRC, CISA, NVD).

The chain, and where the product is silent

Every bulk exfiltration from a document farm follows the same six links. The striking property of on-prem SharePoint is how many of them the product simply does not see:

Link in the chain	On-prem SharePoint, out of the box	Cloud estate (SharePoint Online)
Credential	AD username + password; NTLM/Kerberos/Forms auth. MFA is not a product capability — it requires bolting an AD FS / third-party MFA adapter onto every auth path.	Entra ID; MFA enforcement rolling out platform-wide since 2025–2026.
Authentication anomaly	None consumed. IIS/ULS logs record sign-ins; nothing flags impossible travel, new ASN or odd user-agents.	Entra ID Protection (P2 licence) evaluates sign-in risk.
Enumeration	Search, tree-walk and list views are normal user behaviour. No bulk-read heuristic exists in the product.	Same gap for API/Graph paths; cloud analytics help only if consumed.
Read / download	Read = download. The permission model has no separate egress dimension. Opening a file and copying the entire library use the same permission bit.	Conditional Access app controls can block download to unmanaged devices — configurable, not default.
Exfiltration	No native egress monitoring. On-box DLP (2016+) inspects stored content, not bulk download behaviour.	Purview DLP with sensitive-info types; again, a purchase and a configuration project.
Hosting / monetisation	Outside the product's world entirely.	Same.

Read = download: the missing dimension

The deepest of these gaps is structural: SharePoint's permission model answers one question — "who may open this item?" — and has no native notion of "is this identity behaving like a crawler?" The same grant that lets an employee do their job lets any holder of that grant walk every folder they can see, at network speed, indefinitely. There is no rate concept, no volume concept, and no permission that distinguishes "view" from "acquire".

To make it concrete: a farm holding a couple of hundred thousand files can be walked in roughly 2–4 thousand requests a day — a rounding error in IIS logs, invisible unless someone has built a volumetric baseline in an external SIEM. The logging to notice it exists; the noticing is a separate purchase, integration and staffing decision that most on-prem document farms never receive.

One grant, whole estate

SharePoint's web-application policy model allows a single grant to apply across every site collection in the farm — this is exactly how search crawlers and service accounts are meant to work. It is a legitimate administrative pattern with an uncomfortable property: one credential with one broad grant is, by design, sufficient to read the entire estate. And out of the box, the product offers no effective-permissions report that answers "who, realistically, can read what across this farm?" — answering that question is its own consulting engagement.

"Hasn't Microsoft been told all this?"

Yes — repeatedly, for over a decade. The reason nothing changes is not ignorance or neglect. It is that this genre of weakness is, by MSRC's own servicing criteria, not a vulnerability. Missing MFA on an authentication path is a configuration choice. Read-equals-download is the permission model working as designed. Silent bulk behaviour is the absence of a feature, not the presence of a defect. Vendor taxonomies across the industry draw this line the same way — Kerberoasting, LLMNR poisoning and ESXi's complete lack of MFA are all "architectural boundaries", documented as hardening guidance, never CVEs.

What does get filed and fixed is code-level failure — and that channel demonstrably works. In July 2025, the ToolShell chain (CVE-2025-53770 / CVE-2025-53771, hardening the days-earlier CVE-2025-49704 / -49706) gave unauthenticated remote code execution on on-prem SharePoint Server and was exploited at scale, including against government agencies. Microsoft shipped emergency patches for 2016 / 2019 / Subscription Edition within days; CISA added the flaws to the Known Exploited Vulnerabilities catalog and published malware-analysis reports. SharePoint Online was not affected. Notably, Microsoft's own protection guidance for that episode leaned on posture: enable AMSI integration (made default in September 2023 updates only, after years of being optional) and deploy Defender — i.e. the code fix rides on top of the same hardening defaults that were never there.

The rest of the loop is commercial. Every structural gap has a Microsoft product as its remedy — Entra P2 for identity risk, Purview for DLP, Defender for Cloud Apps for download blocking, Sentinel for the SIEM baseline — or the strategic answer: migrate to SharePoint Online, where Conditional Access and session controls exist natively. Meanwhile SharePoint Server 2016 exits support in July 2026, and NVD's own remediation guidance for the ToolShell era tells operators of end-of-life farms to disconnect them from the internet entirely. A whole market — permission-auditing vendors (AvePoint, SysKit, Rencore and peers) — exists precisely because the platform's defaults don't answer its own "who can read what" question. The gap is known, reported, monetised — and, by taxonomy, unfixable as a bug.

None of this reduces the blast radius. Call it a design property, call it a business strategy — a farm holding identity documents, loan files and KYC archives remains one leaked password away from a silent, complete, lawful-looking copy. CVE-or-not is a filing question. The harm is an architecture question.

What a defensible on-prem SharePoint posture looks like

Put MFA in front of every auth path — AD FS with an MFA adapter or a third-party identity provider; verify each protocol (NTLM, Kerberos, Forms) is covered, not just the browser login page.
Contain the network. A document farm holding customer records has no business being internet-reachable; gate access behind VPN/zero-trust broker, and treat an exception list as a board-level liability.
Patch on calendar and keep AMSI on — the ToolShell episode showed the on-prem exploit window is measured in days.
Answer "who can read what" annually. Run effective-permission audits across site collections; review web-application policies and crawl/service accounts; kill orphaned grants.
Build the volumetric baseline. Ship IIS/ULS to a SIEM and alarm on per-identity request volume and unusual user-agents — the crawl that copies a farm is invisible without it.
Classify the crown jewels. Identity documents and KYC archives deserve DLP and, honestly, a migration plan — the on-prem platform's trajectory is end-of-support, not endowment.