SharePoint ransomware exploits make public-facing farms harder to justify

Microsoft observed Storm-2603 use the SharePoint exploit chain to deploy ransomware after gaining access to internet-facing servers. For each SharePoint Server 2016 or 2019 farm, confirm whether it is reachable from the internet; whether the July 2025 security updates, AMSI Full Mode, machine-key rotation and IIS restart were completed; whether logs and endpoints show signs of web-shell activity or credential theft; and whether the service has a funded end state: Subscription Edition, Microsoft 365 migration or retirement.

This isn’t mainly a story about one overdue patch. It is a test of whether an organisation still has a defensible reason to run a public-facing collaboration platform that can provide a route into the wider Windows estate.

The timing is awkward. SharePoint Server 2016 and SharePoint Server 2019 reached end of support on 14 July 2026. A farm on either product is now outside normal security support, even if it was diligently patched during the ToolShell incident in July 2025. First establish what is exposed and whether it needs to be exposed at all. Migration matters, but it isn’t an excuse to leave the risk in place while a multi-year programme takes shape.

1. The ransomware warning applies to a chain, not one neat CVE story

Precision matters here. CISA’s Known Exploited Vulnerabilities catalogue says CVE-2025-49704, a SharePoint code-injection vulnerability, is known to have been used in ransomware campaigns. Microsoft’s later analysis linked active exploitation involving CVE-2025-49704, CVE-2025-49706 and the more robustly addressed follow-on flaws CVE-2025-53770 and CVE-2025-53771 to ransomware deployment.

The operational conclusion is broader than the status of any one identifier. An internet-facing SharePoint server was used for initial access; Microsoft described web-shell deployment, theft of ASP.NET machine-key material, command execution through the IIS worker process, credential theft and lateral movement before ransomware activity. It’s a familiar and deeply unhelpful sequence: a specialist collaboration service becomes the foothold for a domain-wide incident.

SharePoint Online was not affected by these particular on-premises server vulnerabilities. That doesn’t make Microsoft 365 magically safe, nor does it settle every data-residency, sovereignty or integration question. It does remove this specific self-hosted SharePoint attack surface from the customer’s perimeter.

2. Remove public exposure before debating the perfect target architecture

For a public-facing farm, start with a blunt question: who genuinely needs anonymous or direct internet access?

If the answer is staff and regular partners, a VPN, authenticated reverse proxy or access gateway is usually a more sensible interim position than publishing the farm openly. Microsoft’s guidance for the 2025 incident said that where AMSI could not be enabled, customers should consider disconnecting the server from the internet. Where disconnection was not possible, it suggested limiting unauthenticated traffic through a VPN, proxy or authentication gateway.

That’s containment, not remediation. But it gives the organisation room to map dependencies properly: inbound publishing rules, alternate access mappings, document submission processes, federated authentication, line-of-business links and the awkward external users usually discovered only after the firewall change.

A public site that exists only because “it has always been there” should come off the internet now. A site supporting a real external service needs an owner, a documented access model and a decision on whether SharePoint remains the right publishing platform. Those are not the same thing.

3. Supported-version verification is now a board-level risk decision

SharePoint Server 2016 and 2019 have been unsupported since 14 July 2026. CISA explicitly recommends disconnecting public-facing SharePoint Server releases that have reached end of life or end of service. An organisation cannot reasonably describe a publicly exposed 2016 or 2019 farm as patch-managed when future fixes are no longer part of the product lifecycle.

SharePoint Server Subscription Edition remains the supported on-premises route; Microsoft says it will remain supported until at least 31 December 2035. For estates with difficult local integrations, constrained connectivity or genuinely specific regulatory requirements, moving to Subscription Edition may be the least risky short-to-medium-term answer.

It is not a free pass. Subscription Edition still means operating Windows servers, SQL Server dependencies, SharePoint patching, identity integration, endpoint protection, backup, monitoring and a public attack surface if it is exposed. It buys a supported platform, not an exemption from operational discipline.

Produce a short, factual inventory: product version and build, installed security updates, server roles, internet-reachable URLs, authentication routes, AMSI state, antivirus or EDR coverage, and the service owner for each web application. Without it, a migration plan is mostly a hope document.

4. Patching does not settle the question of historic compromise

For farms exposed during the 2025 exploitation period, “install updates and move on” is not enough. Microsoft advised customers to rotate SharePoint ASP.NET machine keys and restart IIS after applying the updates or enabling AMSI. That matters because observed attacks sought machine-key data through malicious ASPX files.

The forensic review should be proportionate, but it must be real. Preserve relevant IIS, ULS, Windows and security-tool telemetry before retention periods erase it. Hunt for the indicators and suspicious process behaviour in Microsoft’s published guidance; look for unexpected ASPX files, web-shell activity, unusual IIS worker-process child processes, new scheduled tasks and suspicious assemblies. Review privileged-account use and lateral movement from the SharePoint servers, not just the servers themselves.

There is no honest universal look-back period. It depends on exposure dates, logging retention and whether there are credible indicators. A clean current vulnerability scan cannot prove that a server was not previously used to establish persistence.

Recovery planning needs the same scepticism. Fast disk-level recovery can be valuable, but it does not show that the restored application state is trustworthy. Azure managed-disk recovery runbooks should include malware-scanning, identity and application-validation steps rather than treating rapid volume restoration as the end of the incident.

5. SharePoint Online migration works for content; it may not work as a lift-and-shift application move

Microsoft’s SharePoint Migration Tool supports SharePoint Server 2010, 2013, 2016 and 2019 as source platforms, and supports incremental runs. That makes it useful for the bulk of conventional document libraries, lists, permissions, taxonomy and version history. Treat it as an assessment and transport tool, not proof that an old farm will arrive functionally intact.

Microsoft’s assessment guidance identifies the hard parts: unsupported custom solutions and features, customised pages, unsupported web parts, workflow limitations and some list or permission structures. A customised classic portal with SharePoint Designer changes, server-side code, bespoke forms and workflows tied to local systems is not an ordinary migration. It is a redevelopment programme with content migration attached.

The decision framework can be straightforward:

• Move straightforward collaboration content to SharePoint Online where the business requirement is documents, team sites, permissions and ordinary workflow.
• Rebuild business applications deliberately where custom code, forms, integrations or workflow logic are the service. Don’t conceal that work inside a “SharePoint migration” label.
• Move to SharePoint Server Subscription Edition where there is a clear reason to remain on premises, while setting a hard limit on public exposure and a lifecycle plan for the remaining estate.
• Retire low-value sites that no longer justify the operating and security burden.

Run the assessment before choosing the destination. Classify sites by business criticality, external access, customisation and data sensitivity; migrate a representative pilot; then test permissions, search, links, workflows, records controls and third-party integrations with real users. Matching content counts at the end is necessary. It is nowhere near sufficient.

Bottom line

CISA’s ransomware designation is a reminder that exposed SharePoint Server is not merely an ageing collaboration tool. It can be an entry point to a much larger compromise. For SharePoint 2016 and 2019, now out of support, the rational default is to remove public exposure and move decisively towards retirement, migration or replacement.

SharePoint Online is often the better destination for ordinary collaboration content, but not every on-premises SharePoint workload can simply be copied there. Where on-premises operation remains justified, Subscription Edition is the supported choice. Keeping an end-of-support farm public while waiting for the ideal migration plan is no longer credible.