Cybersecurity & Data Protection Blog | CyberGrant

#10 Cold Case SharePoint: the patch did not close the incident

Written by CyberGrant Team | Sep 4, 2026, 8:52:25 AM

SharePoint on-premise: patched servers, open document archives. How CyberGrant would have handled it

July 18, 2025. No stolen credentials. No malicious attachment opened by mistake. No malware delivered by email. Just an HTTP request sent to a SharePoint server reachable from the internet. Microsoft had shipped the patch ten days earlier. It was not enough.

What to take away in 30 seconds
  • SharePoint Server on-premise deployments (2016, 2019, Subscription Edition, plus out-of-support versions) were hit by two zero-days, CVE-2025-53770 (CVSS 9.8) and CVE-2025-53771, in a campaign researchers named ToolShell. Both flaws bypassed the updates Microsoft had released on July 8, 2025 for earlier vulnerabilities.

  • Confirmed victims include the National Nuclear Security Administration, the agency that maintains the US nuclear stockpile, along with other parts of the Department of Energy, European and Middle Eastern government bodies, universities, and energy companies.

  • The attacker did not need to authenticate. A POST to the ToolPane endpoint and deserialization of the __VIEWSTATE field were enough to run code on the server. No password was stolen, so there was no multi-factor prompt to defeat.

  • The real damage is not the access. It is the web shell that extracts the ASP.NET machine keys: with those keys, access survives the patch.

  • The Verizon DBIR 2026 puts vulnerability exploitation in first place among initial access vectors, at 31% against 20% the year before. Only 26% of critical vulnerabilities in the CISA KEV catalog were fully remediated in 2025, down from 38%.

  • Inside those document libraries, the files sat in cleartext. A collaboration platform protects a document for as long as the document stays on the platform. When the platform falls, nothing stays attached to the file.



What actually happened on SharePoint on-premise servers

The exploit chain was not a surprise. It had been demonstrated in public on May 16, 2025 at Pwn2Own Berlin, where a Viettel Cyber Security researcher chained two SharePoint flaws into remote code execution and collected a hundred thousand dollars for it. On July 8 Microsoft closed those two flaws, CVE-2025-49706 (spoofing) and CVE-2025-49704 (remote code execution). The fix existed, it was documented, it needed to be installed.

On July 14 a German research firm published a working reproduction of the exploit. By July 17 the patch was already obsolete: two new vulnerabilities, CVE-2025-53770 and CVE-2025-53771, walked around the updates that had just gone out. From July 18 exploitation went wide. Two months from the competition stage to attacks in the wild. Nine days from patch to bypass.

The mechanics are brutally simple. The attacker sends a POST to the ToolPane.aspx endpoint with a spoofed Referer header, slips past the IIS authentication check, and forces deserialization of a malicious .NET payload in the __VIEWSTATE field. No username, no password, no human in the loop. Italy's National Cybersecurity Agency (ACN) summarized it this way in the bulletin issued by the national CSIRT: deserialization of untrusted data, arbitrary code execution by an unauthenticated remote attacker, CVSS 9.8.

Then comes the step that turns an exploit into a long-term problem. A web shell is written to the server, in most cases a file named spinstall0.aspx, whose only job is to read and return the ASP.NET machine keys, meaning the ViewState validation and decryption keys.

Microsoft Threat Intelligence attributed the campaign to three China-linked actors: Linen Typhoon, active since 2012 against government, defense, and strategic planning targets for intellectual property theft; Violet Typhoon, running espionage since 2015 against former government officials, NGOs, think tanks, universities, media, healthcare, and finance; and Storm-2603, which from July 18 used the same vulnerabilities to deploy Warlock ransomware through Group Policy changes.

Only on-premise installations were affected. SharePoint Online in Microsoft 365 was not. That still left a wide field. Eye Security, the Dutch firm that spotted the campaign first through an EDR alert on a customer's legacy SharePoint server, counted more than 400 compromised systems out of over 23,000 scanned, revising its estimate of affected organizations upward from around a hundred to more than four hundred within days.

On July 18 the exploitation reached the US Department of Energy. Among the affected components was the National Nuclear Security Administration, the agency that designs and maintains the American nuclear arsenal and coordinates response to radiological emergencies. European and Middle Eastern government institutions, universities, and energy companies appear on the same list. The CVEs went into CISA's Known Exploited Vulnerabilities catalog.

On July 22 the European Commission, ENISA, CERT-EU, and the network of national CSIRTs published a joint statement asking every organization, and NIS2 entities explicitly, to assess their exposure without delay.

 

Why the patch did not close the incident

This is the part that makes the case a template rather than one more critical CVE.

Machine keys are not ordinary data. They are the cryptographic material the server uses to sign and encrypt the ViewState. Anyone holding them can forge perfectly valid __VIEWSTATE payloads and keep executing commands on the server after the update is installed. The patch shuts the front door while the attacker already has a copy of the keys.

That is why ACN's bulletin does not stop at "apply the update" and adds three actions: monitor and block POST requests to ToolPane.aspx carrying anomalous __VIEWSTATE values, confirm AMSI is enabled, and rotate the ASP.NET machine keys. Microsoft prescribes the same path and adds an IIS restart across all servers.

Organizations that only patched closed a vulnerability and left an access path open.

Now add time. According to IBM's Cost of a Data Breach 2025, the average time to identify and contain a breach fell to 241 days, a nine-year low. Breaches involving data held on-premise resolve fastest of any category and still take 217 days. Seven months. Inside that window, espionage actors read and remove documents while ransomware actors stage encryption.

Where the data protection architecture gave way

The technical break is a software vulnerability, and patch management handles that. The structural break is something else, and no update closes it. Four failures are visible.

The document repository was published to the internet as a web application. SharePoint on-premise exists to centralize document management and collaboration. Exposing it externally means exposing the container of an organization's entire documentary knowledge to anyone who can send an HTTP request. The attack surface was not a server. It was the archive.

Documents were protected by the platform, not by themselves. Permissions, groups, library inheritance: every one of those controls lives in the application layer. Compromise that layer with SYSTEM privileges and the controls are not bypassed, they simply stop applying. Underneath, the file is a readable file.

The authorization perimeter had no useful segmentation. One compromised server gave visibility across entire site collections. As in the Generali España case, the blast radius was set by the reach of the access obtained, not by the sensitivity of the data.

Nobody had a picture of what was inside. After an incident like this the board, legal counsel, and the regulator all ask the same question: which documents were exposed, which held personal data, which held trade secrets, which were under NDA. Without automatic classification, that answer gets assembled by hand over the following weeks, and it stays an estimate.

The Italian context makes the question concrete. The 2026 Clusit report, published by Italy's association for information security, ranks vulnerability exploitation second among attack techniques observed in 2025, at 16.5% of the sample and up 65% year over year.

Was isolating servers and moving to the cloud the right answer?

Most affected organizations responded quickly and sensibly: pull on-premise SharePoint servers off the public network, accelerate migration to the cloud, make multi-factor authentication mandatory.

Three reasonable measures, solving three problems other than the one that matters.

Isolation reduces exposure, not access already obtained. Anyone who copied the machine keys before the disconnect keeps the ability to sign valid requests. On a server brought back online after cleanup without key rotation, that material still works.

Cloud migration moves responsibility for patching, not the protection model. On SharePoint Online, Microsoft handles the update, and that is a real advantage. The document is still protected by platform permissions rather than by itself, and it still leaves in cleartext the moment someone downloads it. What changes is who holds the key to the building, not what sits in the rooms.

Multi-factor authentication, in this specific case, is beside the point. The exploit was pre-authentication. No credential theft, no session hijack, no second factor to defeat: an HTTP request to a public endpoint. MFA is a necessary control, and it would have mattered against the lateral movement that followed, but presenting it as the answer to this vector means reading the incident at the wrong layer.

All three measures work on access. None works on the data. And encrypting the content, worth saying, does not require moving anything: as we set out in how to encrypt SharePoint files without migration, documents can stay exactly where they sit today.

Why perimeter DLP would not have changed the outcome

No firewall fires on a legitimate HTTP request to a port that has to stay open. No network DLP blocks exfiltration when the process reading the files is w3wp.exe, the IIS worker serving SharePoint. No egress control intervenes when the attacker holds SYSTEM privileges on the server hosting the documents.

Traditional DLP watches the exits. Here there was no exit. There was a change of ownership of the container. It is the same mechanism we described in Booking, Eataly, Trenitalia: why the stolen data was readable, applied to a document archive instead of a customer database.

The right question is not how to prevent access to the server. It is what remains in the hands of whoever gets the server. You do not protect the exit. You protect the file at birth.

The CyberGrant platform sits alongside an existing Microsoft estate rather than replacing it, and works at that second layer.

The CyberGrant Connector for SharePoint: protection stays inside the library

The CyberGrant Connector for SharePoint is not an alternative archive. It is an encryption layer that lives inside the SharePoint and OneDrive libraries an organization already has: no migration, no changes to permission policies built up over years, no change in how people work with documents. Rules are set per site or per folder, and from that point files uploaded into those areas are encrypted with CRYSTALS-Kyber, the algorithm NIST recognized as its post-quantum standard (FIPS 203, ML-KEM, August 2024).

Applied to this scenario: the attacker still gets SYSTEM privileges on the server, but what sits in the library is encrypted blocks. The architectural point is sharper than that. The Connector is designed to lock out the Azure tenant administrator as well, so anyone who seizes administrative privileges on the platform ends up exactly where the admin sits: outside. That is not a setting to enable. It is the threat model the product starts from.

Three details matter specifically here.

Every format, not just Office. The victims were government bodies, universities, and energy companies. Those libraries held project PDFs, images, CAD files, source code. Microsoft Purview encrypts Office files and, for other formats, changes the extension, turning a JPEG into a PJPEG that native applications will not open. The Connector encrypts any format while keeping the original extension, so it does not leave the non-Office half of the archive uncovered. The full comparison between the two protection models, covering formats, extensions, and administrator access, is in SharePoint does not encrypt your files, and Purview does not do what you think.

No cleartext copy on disk. Opening an encrypted file locally goes through RemoteGrant: the document is decrypted in memory and leaves no temporary copy on the filesystem. On a compromised server, temporary copies are the first thing an attacker goes looking for.

Copilot does not read what is encrypted either. Copilot and other AI assistants index SharePoint libraries to answer user questions: they read documents the way anyone with platform access would. On a file protected by the Connector they find ciphertext and metadata, never the content. Protection does not stop at the tenant boundary either: with FileGrant, the file stays encrypted wherever it is copied, forwarded, or uploaded, so no AI system, whether Copilot, ChatGPT, or a third-party model, reads what is inside. A document that leaves encrypted does not enter any model as readable text. That is a governance choice rather than a side effect: coverage is set per site or per folder, so you decide which libraries stay legible to your enterprise AI and which stay opaque.

Worth pausing here, because it is the same principle that holds up against ToolShell. An authorized indexer and an attacker with SYSTEM privileges do exactly the same thing: they read the library. If the content is encrypted inside the file, neither one gets text. Protection against AI ingestion and protection against exfiltration are not two measures. They are the same measure seen from two sides.

Outside the library, FileGrant logic applies. A shared file leaves in Lock&Go format, encrypted beyond the platform, with download blocking, screen capture blocking, and access revocation after sharing. Sharing with an external party starts with a right click from SharePoint, with no Azure user to create. Master keys stay inside the customer's infrastructure in a zero-knowledge configuration, not on the exposed server.

An archive exfiltrated in cleartext is an incident with no closing date, because those documents stay readable forever. An archive exfiltrated encrypted is an availability problem, not a confidentiality one. The same logic covers "harvest now, decrypt later": anyone stockpiling encrypted material today, betting on tomorrow's compute, runs into an algorithm designed for exactly that scenario. We covered the European obligations on this in post-quantum security and EU member state duties.

AIGrant: knowing what is in the libraries before you need to

The blind spot for the organizations that lived through this was inventory. Thousands of documents, dozens of site collections, no reliable classification of content.

AIGrant is CyberGrant's private on-premise AI: it indexes, analyzes, and automatically classifies documents by content, applies confidentiality tags, segregates by department into sealed compartments, tracks who accesses what, and flags anomalous access patterns by volume, hour, or origin. Data never leaves the organization's infrastructure, and every interaction is logged.

Two concrete effects. Segmentation first: even with the server compromised, useful visibility shrinks to the classified perimeter instead of matching the whole archive. Reconstruction second: notification under GDPR Article 33 and incident reporting under NIS2 rest on a list of classified documents rather than an estimate assembled after the fact. We wrote about how this fits into a governance framework in EU AI Act compliance for CISOs.

The endpoint layer belongs here too. In the Storm-2603 chain the compromised server was only the starting point: Mimikatz against LSASS for credentials, PsExec and Impacket for lateral movement, Defender disabled through the registry. RemoteGrant operates at exactly that level, with transparent encryption on local files, clipboard and removable media control, screen capture protection, and IP range access rules.

 

The alternative scenario with CyberGrant in place

  • The SharePoint exploit still succeeds. The vulnerability is in the Microsoft product, and no additional layer removes it. What changes is what the attacker finds on disk.

  • Documents in libraries covered by the Connector are encrypted with CRYSTALS-Kyber, in any format. Mass exfiltration produces unreadable material, not an archive ready for industrial espionage.

  • Administrative privileges on the platform do not open the files: the Connector locks out the tenant administrator too, and master keys stay on-premise, off the exposed server.

  • No cleartext temporary copies on the server filesystem, because decryption happens in memory.

  • No automated indexing system gets the content in cleartext, not Copilot inside the tenant and not a third-party model after the file has left.

  • Automatic classification tells you the same day which documents sat inside the compromised perimeter and what categories of data they held.

  • Granular audit trail turns incident notification into a list of verifiable facts rather than an approximate reconstruction weeks later.

CyberGrant does not eliminate risk. It turns risk into control and awareness.

 

What this changes for decision makers

For the CISO.

  1. Blast radius is measured in content, not hosts. Counting exposed servers is vulnerability management. Knowing which documents were readable on those servers is risk management. Two different exercises, and the second is almost never ready when it is needed.

  2. Patching is not containment. This case shows a compromise surviving remediation when the attacker walks off with cryptographic material. Key rotation, service restarts, and indicator hunting are part of the patch, not an optional follow-up.

  3. The detection window is still measured in months. At 217 days on average even in the fastest scenario, per IBM 2025, the operational question is not whether an attacker gets in. It is what they can do with your data across the seven months you cannot see them.

For the CIO and CTO.

  1. On-premise versus cloud is not the right axis for the decision. SharePoint Online was not vulnerable to this CVE, and migration remains defensible as a patch management choice. It is not a data protection argument: in both models document security is a property of the platform, and it ends the moment the file is downloaded.

  2. Add protection at the right layer without rebuilding the infrastructure. The Microsoft estate stays where it is. The CyberGrant Connector for SharePoint works inside the existing libraries: no document migration, no permission redesign, Microsoft authentication already integrated. It adds persistent encryption across every format, exclusion of the tenant admin, post-sharing revocation, and a document-level audit trail.
  3. AI governance runs on the same lever. Documents that must not end up in an index stay encrypted to Copilot as well, inside and outside the tenant, and coverage is decided per site or per folder. On the other side of the problem, AIGrant does not replace Copilot: it covers the case where you need an assistant that actually reads the documents without the data leaving the organization.


Frequently asked questions

What is the ToolShell vulnerability in SharePoint?

ToolShell is the name given to the attack campaign that in July 2025 exploited two zero-day vulnerabilities in Microsoft SharePoint Server on-premise: CVE-2025-53770, a remote code execution flaw scored CVSS 9.8 caused by deserialization of untrusted data in the ASP.NET framework, and CVE-2025-53771, which bypassed previously released fixes. The attacker could execute code on the server without any authentication by sending a POST request to the ToolPane endpoint.

How many organizations were affected by the 2025 SharePoint attack?

Eye Security, the Dutch firm that identified the campaign first, detected more than 400 compromised systems across over 23,000 servers scanned, revising its count of affected organizations upward from roughly one hundred to more than four hundred within days. Confirmed victims include the US Department of Energy and the National Nuclear Security Administration, the agency that maintains the American nuclear arsenal, along with European and Middle Eastern government institutions, universities, and energy sector companies.

Would multi-factor authentication have stopped the attack?

Not against the initial vector. The vulnerabilities allowed code execution on the server without any authentication: no stolen credentials, no session to hijack, therefore no second factor to defeat. MFA remains a necessary control and would have helped contain the lateral movement that followed, but it is not the answer to a pre-authentication vulnerability on an internet-facing service.

Did Microsoft's patch solve the problem?

Only partly. After initial exploitation, attackers installed a web shell that extracted the ASP.NET machine keys, the keys the server uses to sign and encrypt the ViewState. With those keys, access survives installation of the update. Microsoft and ACN both list the same required steps beyond patching: rotate the machine keys, restart IIS, and enable AMSI in full mode.

Was SharePoint Online in Microsoft 365 vulnerable?

No. The vulnerabilities affected on-premise installations only, meaning SharePoint Server 2016, 2019, Subscription Edition, and out-of-support releases. That removes this specific CVE for organizations on Microsoft's cloud, but it does not change the underlying protection model: in SharePoint Online as well, document security is a property of the platform rather than the file, and it does not follow the file after download.

Would traditional DLP have stopped the SharePoint attack?

No. Perimeter DLP and network controls act on egress channels, while in this scenario the attacker holds elevated privileges on the server hosting the documents and reads files through the legitimate IIS process. There is no anomalous channel to block. Effective protection is file-centric: encryption applied to the document at creation, persisting even when the infrastructure is compromised.

Would Microsoft Purview have protected the documents on SharePoint?

Only partly, and the uncovered part is the one that matters in an incident like this. Purview encrypts Office files; for other formats it either applies no protection or changes the extension, turning a JPEG into a PJPEG that native applications will not open. In an archive holding project PDFs, images, CAD files, and source code, that portion stays readable. There is a second limit: with Purview, the Azure tenant administrator can open encrypted files, while the CyberGrant Connector for SharePoint locks out the admin as well, which puts protection beyond the reach of anyone who gains administrative privileges on the platform.

Can Copilot read encrypted documents on SharePoint?

No. Copilot and other AI assistants index SharePoint libraries to answer user questions. On a file protected by the CyberGrant Connector they find ciphertext and metadata, never the content. The same holds outside the tenant, because with FileGrant the file stays encrypted wherever it is copied, forwarded, or uploaded, so no AI system, whether Copilot, ChatGPT, or a third-party model, reads what is inside. A document that leaves encrypted does not enter any model as readable text. Coverage is set per site or per folder, so which libraries stay legible to your enterprise AI remains a governance decision.

What does file-centric protection mean for a document repository?

It means the document is encrypted at origin and stays encrypted wherever it sits: in the SharePoint library, on the server disk, in an exfiltrated copy, on an external recipient's device. The key does not live on the system hosting the file. Whoever takes control of the server gets blocks of bytes, not readable content. The security measure is not preventing access, it is making what gets taken useless.

Does FileGrant replace SharePoint or OneDrive?

No, and it is not designed to. FileGrant sits alongside an existing Microsoft estate and adds the layer those platforms do not cover: persistent CRYSTALS-Kyber encryption that stays active after download, access revocation after sharing, screen capture protection, blocking of scraping by public AI tools, and a granular audit trail at the document level.

What does NIS2 require after an incident like this?

NIS2, transposed in Italy through Legislative Decree 138/2024, requires essential and important entities to report significant incidents within defined timeframes and to apply risk-proportionate security measures, encryption, access control, and traceability among them. In the SharePoint case, the joint statement from the European Commission, ENISA, and CERT-EU explicitly asked NIS2 entities to assess their exposure quickly. Being able to say which documents were involved, not only which servers, is what makes a notification factual.