ToolShell Reloaded: SharePoint Forensics After the Machine Key Heist
19.07.2026 sharepointtoolshellweb-shell-forensicsincident-response
In July 2025, “ToolShell” rocked the on-premises world of Microsoft SharePoint: a chain of four CVEs enabled unauthenticated remote code execution against enterprise servers worldwide. A year later, in July 2026, the name resurfaces – this time tied to a breach at the US Department of Homeland Security’s Homeland Security Information Network (HSIN). The case is a textbook example of why SharePoint compromises rank among the most forensically demanding scenarios in enterprise IR.
Anatomy of a Chain That Refuses to Die
The original ToolShell chain combined two already-patched flaws with two zero-days. These vulnerabilities impact self-hosted SharePoint Server 2016, 2019, and Subscription Edition, enabling unauthenticated remote code execution and security bypasses. What made it especially dangerous: the combination of unauthenticated remote code execution and cryptographic key theft creates a perfect storm for persistent compromise and lateral movement.
Those stolen keys are the core of the forensic problem. Attackers extract ASP.NET machine keys used to sign authentication tokens, allowing user impersonation and persistent, credential-less access that survives initial patching efforts. A server can be fully patched and still remain compromised as long as the stolen keys stay valid and unrotated.
Canada’s Centre for Cyber Security documented a variant that skipped the well-known default web shell entirely: a key indicator shared by Microsoft, the file spinstall0.aspx, was not found during the incident in question, demonstrating that the threat actor used a novel technique with custom .NET payloads to gain and maintain code execution, without a PowerShell process spawned by IIS. For forensic teams the takeaway is blunt: relying solely on published IOCs misses tailored variants.
Why Patching Alone Doesn’t Save the Evidence Trail
Agencies worldwide had to communicate an unusually strict remediation sequence after ToolShell. Singapore’s Cyber Security Agency stated plainly: patching alone is not sufficient if the SharePoint server has already been compromised – mitigation steps including rotating keys, restarting the IIS service, and removing artefacts such as web shells are critical to minimise risk. CISA added a sequence many defenders found counterintuitive: ASP.NET machine keys must be rotated, then after applying the security update rotated again, and IIS restarted – if malicious module entries aren’t manually removed from applicationHost.config and web.config before restarting, they will simply reload.
That means evidence preservation has to follow a strict order of operations: the initial goal is to detect evidence of compromise and determine the scope of the breach without prematurely altering the system state, which could destroy valuable forensic evidence – this phase must be executed immediately. In practice, that means centralizing IIS logs, SharePoint ULS logs and Windows event logs, and – for high-value systems – capturing full disk images so deleted files and timelines can be reconstructed offline.
The HSIN 2026 Case: History Repeating
In July 2026, DHS confirmed a breach at HSIN just as a new vulnerability, CVE-2026-45659, landed on CISA’s Known Exploited Vulnerabilities catalog. According to current reporting, an unknown threat actor gained unauthorized access to HSIN sometime between late May and early June 2026, going after both HSIN’s servers and a SharePoint system the platform uses for interagency collaboration. The federal response was unusually aggressive: CISA gave federal civilian agencies until July 4 to apply the fix under Binding Operational Directive 26-04, an unusually tight three-day remediation window and a strong signal that active exploitation is already underway somewhere in the federal enterprise. Technically, the bar for exploitation was low: it’s a CWE-502 deserialization of untrusted data bug, CVSS 8.8, and Microsoft’s advisory notes that an authenticated attacker needs nothing more than Site Member permissions, the lowest tier of SharePoint access, to trigger it.
For DFIR teams the lesson is unambiguous: SharePoint deserialization chains are not a one-off event but a recurring attack class. Closing the CVE without hunting for stolen keys, persistent modules, and tampered config files leaves the real back door open — ready to be exploited again the moment the next related vulnerability surfaces.
← Back to overview