ASP.NET Machine Key Exposure: Find, Contain and Rotate Leaked Keys

An exposed ASP.NET machine key lets an attacker forge ViewState that the server trusts and run code in the IIS worker process, and patching the hole the key leaked through does not take that power away. Microsoft reported in February 2025 that it had identified more than 3,000 publicly disclosed machine keys, copied from documentation and code repositories into production, and in July 2025 the ToolShell SharePoint campaign stole machine keys from on-premises servers so that access survived the patch. This guide is the incident playbook for an exposed or stolen machine key on ASP.NET Web Forms, SharePoint Server or other IIS-hosted .NET Framework applications: how it shows up, triage, containment, eradication, recovery, evidence and notification. It is written for incident responders, Windows and web platform owners. Secure configuration of .NET applications in general is covered in the .NET Security Guide.

Key takeaways

• The key is a credential. validationKey and decryptionKey sign and encrypt ViewState and forms authentication data; whoever holds them can make the server accept and execute crafted ViewState.
• Two exposure routes, one response. A key copied from a public source is exposed from day one; a key read off a compromised server (as in ToolShell) is exposed from the moment of compromise. Both require rotation and a hunt for earlier use.
• Order matters: CISA's ToolShell guidance is to apply the update, rotate the machine keys, then restart IIS, removing malicious module entries first so they do not reload.
• Rotation is not eradication. Microsoft warns that rotating keys may not remove backdoors or persistence, and recommends considering a rebuild from offline media for servers where the key was exploited.
• Inventory prevents the next one. Compare every hard-coded key against Microsoft's published hash list, prefer AutoGenerate,IsolateApps where you do not run a farm, and encrypt the machineKey section where you must keep explicit keys.

How the incident shows up

Machine key incidents rarely announce themselves as such. They usually surface through one of the signals below.

Exchange Server has a history here too: CVE-2020-0688, listed in the CISA Known Exploited Vulnerabilities catalogue as the Microsoft Exchange Server Validation Key Remote Code Execution Vulnerability with known ransomware use, came from a validation key that was the same across installations. See the Microsoft Exchange Server Security Guide.

Triage questions

1. Where is the key configured? An explicit <machineKey> with hex validationKey and decryptionKey values in the application web.config, the site root, or machine.config; or the default AutoGenerate,IsolateApps, where ASP.NET generates a random key stored in the LSA per application.
2. Is the key public? Run Microsoft's published script against the hash list of disclosed keys. A match means assume compromise of every application using it.
3. Which servers share it? Web farms must use the same explicit key on every node, and the same key is often reused across environments and applications. List every host and app pool.
4. Is the application exploitable with it? Any ASP.NET Web Forms page that processes ViewState, plus forms authentication tickets protected by the same key. SharePoint Server farms count.
5. Is there evidence of use? Defender alerts above, w3wp.exe spawning cmd.exe or powershell.exe (ATT&CK T1059.001), unexpected assemblies loaded by w3wp.exe, new .aspx files (T1505.003 Web Shell), and unusual POSTs with large __VIEWSTATE values.
6. What else did the host hold? Connection strings, service account credentials, certificates and API keys in the same web.config are exposed by the same read.
7. What is the window? For a public key, from deployment; for a stolen key, from the earliest sign of server compromise. Log retention decides how far back you can look.

Severity decision: a public or stolen key on an internet-facing server with any sign of use is a full server compromise. A public key with no sign of use, on an internal or unreachable application, is still urgent rotation but can follow change control. In small organisations with one web server the two collapse into the same action: rotate today and hunt.

Containment priorities

1. Cut exposure: if exploitation is suspected and the server cannot be fixed quickly, remove it from the internet or put it behind an authenticated VPN, proxy or gateway, as Microsoft and CISA advised for ToolShell. Take end-of-life SharePoint (2013 and earlier, per CISA) offline.
2. Patch the entry point where there is one (for ToolShell, the SharePoint updates for CVE-2025-53770, CVE-2025-53771 and related CVEs).
3. Turn on AMSI: ASP.NET 4.8 enables AMSI integration; for SharePoint, enable AMSI, preferably in Full Mode, with Defender Antivirus on every server. AMSI has been on by default for SharePoint 2016 and 2019 since the September 2023 update and for Subscription Edition since version 23H2.
4. Rotate the keys: see the table below, on every node at the same time for farms.
5. Clean and restart: remove malicious module entries from applicationHost.config and web.config, then restart IIS (iisreset.exe) on all affected servers so old keys and loaded modules are dropped.
6. Rotate co-located secrets: connection strings, service account passwords and certificates from the same configuration. Use the Secrets Rotation Runbook Template.

Rotation by platform

Generate keys with a cryptographic random generator, never copy them from a sample, and for explicit keys encrypt the machineKey and connectionStrings sections of web.config, as Microsoft recommends.

Eradication

• Hunt for persistence: web shells, malicious IIS modules and handlers, scheduled tasks, new local accounts and services. CISA highlights .dll payloads as hard to detect and able to extract machine keys again. See the Web Shell Response Playbook.
• Check for credential theft beyond the key: ToolShell actors also used Mimikatz and Impacket according to Microsoft; look for LSASS access (T1003.001) and lateral movement from the web tier.
• Rebuild where exploitation is confirmed: Microsoft recommends considering reformatting and reinstalling from offline media, because rotation does not remove backdoors. Auto-generated keys live on the host, so a host compromise also exposes them; rebuilding resets them.
• Purge the public copy: remove the key from repositories and images you control, rewrite history if needed, and treat the key as permanently burned even after deletion.

Recovery

1. Restore service on rebuilt or cleaned servers with new keys, AMSI enabled and the attack surface reduction rule "Block Webshell creation for Servers" applied.
2. Monitor with heightened logging for at least one full business cycle: IIS logs, Defender alerts, w3wp.exe child processes and file creation in web roots.
3. Confirm with the application owner that sessions, forms authentication and ViewState work across all farm nodes with the new keys.
4. Record the new keys in your inventory with an owner, storage location and rotation rule; see the IIS Hardening Guide for the wider baseline.
5. Rollback: if the new keys break the farm, the fix is to correct key distribution across nodes, never to restore the exposed key.

Choosing the key model after recovery

Avoid validation="SHA1", "MD5" or "3DES" and decryption "DES" or "3DES" except for documented legacy compatibility; the schema documentation describes HMACSHA256 and AES as the FIPS-compliant choices. Keep explicit keys out of source control, and inject them at deployment from a secrets store instead.

Measuring that it worked

• Number of explicit machine keys in the estate, and the share with a recorded owner and rotation date.
• Count of keys matching Microsoft's disclosed key list (target: zero, checked at every build).
• Time from exposure detection to rotation and IIS restart on all nodes.
• Percentage of IIS servers with AMSI enabled and the webshell ASR rule in block mode.
• Repeat detections of web shells or suspicious w3wp.exe assembly loads after recovery (target: zero).

Evidence to preserve

• Before rotation: copies of web.config, machine.config and applicationHost.config with timestamps and hashes (store them securely: they contain the compromised key).
• Memory image of w3wp.exe processes where code injection is suspected, before iisreset.exe clears it.
• IIS logs, including POST bodies if a WAF or reverse proxy captured them; HTTPERR logs.
• Windows Security, System and Application logs, Defender and AMSI detections, EDR process trees.
• Suspicious files (spinstall*.aspx, unknown DLLs, debug_dev.js) with hashes and paths.
• Disk images of servers before rebuild; see the Disk Imaging and Forensic Acquisition Guide.

Notification triggers

• Personal data: code execution on a server that processes personal data is a likely personal data breach. Under GDPR Article 33 the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals; Article 34 adds notification of individuals where the risk is high.
• Other regimes: sector and national rules differ in triggers and deadlines; see the Breach Notification Laws by Country Guide.
• Exposure without use: a public key with no evidence of exploitation is usually not notifiable on its own, but record the assessment and the evidence it rests on.
• Third parties: if a vendor product shipped the key, notify the vendor; if you host applications for customers on the affected servers, contracts may require notice.

Lessons from incidents

The ToolShell SharePoint Exploitation 2025 is the clearest case: attackers used an authentication bypass and deserialisation flaw to drop spinstall0.aspx, which returned the ValidationKey and DecryptionKey, so they could regain code execution with forged ViewState after the fix. Microsoft attributed exploitation to Linen Typhoon, Violet Typhoon and Storm-2603, the last of which deployed ransomware. Organisations that patched without rotating keys remained exposed. The broader lesson is the one Microsoft drew in February 2025: machine keys are secrets, and copying one from a sample or repository is the same as publishing a password.

Practitioner checklist

• Inventory every explicit machineKey across web.config and machine.config files, servers and environments.
• Check each key against Microsoft's published hash list of disclosed keys.
• For a confirmed exposure: patch, rotate, remove malicious modules, then restart IIS on every node.
• Rotate every other secret held in the same configuration files.
• Preserve configuration files, w3wp.exe memory and logs before rotation and restart.
• Hunt for web shells, malicious modules and credential theft; rebuild servers where exploitation is confirmed.
• Enable AMSI (ASP.NET 4.8, SharePoint Full Mode) and the webshell creation ASR rule.
• Audit object access on web.config and machine.config and alert on Event ID 4663 by unexpected processes.
• Assess notification duties and record the decision.

Standards and references

• Microsoft Security Blog: Code injection attacks using publicly disclosed ASP.NET machine keys
• Microsoft Security Blog: Disrupting active exploitation of on-premises SharePoint vulnerabilities
• CISA: Microsoft releases guidance on exploitation of SharePoint vulnerabilities
• CISA: Known Exploited Vulnerabilities Catalog
• Microsoft Learn: machineKey element (ASP.NET Settings Schema)
• MITRE ATT&CK: Server Software Component: Web Shell (T1505.003)
• EUR-Lex: Regulation (EU) 2016/679 (GDPR)

Related NHI Mgmt Group resources: .NET Security Guide · SharePoint Server Security Guide · Web Shell Response Playbook · Insecure Deserialisation Guide