Thousands of ASP.NET Sites at Risk from Publicly Exposed Machine Keys

Microsoft Threat Intelligence has identified over 3,000 publicly disclosed ASP.NET machine keys that could be exploited in ViewState code injection attacks, allowing threat actors to execute malicious code on vulnerable servers.

This discovery follows a December 2024 incident where an unidentified attacker used a publicly known machine key to inject a malicious ViewState payload and deploy the Godzilla post-exploitation framework.

This attack highlights a dangerous shift—while previous ViewState attacks relied on stolen keys sold on dark web forums, attackers can now freely obtain working keys from public code repositories.

How the Attack Works

ViewState is an ASP.NET feature that preserves page state between requests. It relies on machine keys (ValidationKey and DecryptionKey) to prevent tampering and unauthorized decryption.

When developers copy machine keys from publicly available sources, such as GitHub repositories, documentation, or blog posts, and include them in production web.config files, they create a major security risk. These static keys allow attackers to forge malicious ViewState payloads, which the ASP.NET server will automatically validate and execute, leading to remote code execution (RCE).

Godzilla: A Powerful Post-Exploitation Framework

In the December attack, the threat actor reflectively loaded Godzilla (SHA-256: 19d87910d1a7ad9632161fd9dd6a54c8a059a64fc5f5a41cf5055cd37ec0499d) after exploiting a publicly disclosed machine key. Godzilla provides advanced post-exploitation capabilities, including:

• Arbitrary command execution

• Shellcode injection into running processes

• Persistence mechanisms to maintain long-term access

Microsoft has not yet attributed this attack to a specific group but is actively monitoring further exploitation.

Microsoft’s Mitigation Efforts

To reduce risk, Microsoft has removed machine key samples from its own public documentation and has released detection capabilities in Microsoft Defender for Endpoint.

Recommended Remediation Steps

Microsoft urges all ASP.NET developers and administrators to immediately audit their machine key configurations and take the following actions:

1. If your application uses fixed machine keys:

• For web farms (multiple servers sharing a key):

  • Rotate all machine keys simultaneously across all servers.

• For single-server deployments:

  • Remove the <machineKey> element from web.config to revert to secure, auto-generated keys.

• For SharePoint and Exchange:

  • Use the built-in key management system instead of manually setting fixed keys.

2. Ensure Best Practices to Prevent Future Attacks:

• Follow secure DevOps standards—generate unique machine keys securely.

• Encrypt sensitive elements in web.config (e.g., machineKey, connectionStrings).

• Upgrade to ASP.NET 4.8 to leverage Antimalware Scan Interface (AMSI) protections.

• Harden Windows Servers using Attack Surface Reduction (ASR) rules, such as blocking web shell creation.

3. Investigate for Potential Compromise

If a publicly disclosed machine key is found in your environment:

• Rotating the key alone is not enough—fully investigate for possible web shells, persistence mechanisms, or additional compromises.

• Internet-facing servers should be reformatted and reinstalled in an offline environment if exploitation is suspected.

Detection and Response

Microsoft has provided several tools and alerts to help organizations detect and respond to this threat:

Audit Your Environment Now

A full list of hash values for the 3,000+ publicly disclosed machine keys is available on Microsoft’s GitHub repository, along with a PowerShell script to check for their presence in local environments.

Microsoft continues to monitor and analyze the use of publicly disclosed machine keys and will provide updates through their Threat Intelligence blog and social media.

Godzilla is an extremely powerful post-exploitation tool. Once deployed, it allows attackers to execute arbitrary commands, inject shellcode, and maintain persistent access. The fact that it can now be delivered via public machine keys is deeply concerning.

Microsoft has taken steps to mitigate the issue, including removing key samples from their own public documentation. They've also released detection capabilities in Microsoft Defender for Endpoint to identify the use of publicly disclosed keys.

A Real-World Example: CVE-2020-0688 and the Dangers of Fixed Machine Keys

The Microsoft blog linked an old real world example of this that I wanted to dig into so I figured I’d explain what it said here too.

This attack technique showed up in 2020 with CVE-2020-0688, a remote code execution (RCE) vulnerability in Microsoft Exchange Server caused by the use of hardcoded cryptographic keys.

How the Exchange Server Vulnerability Worked

Microsoft Exchange Server’s Exchange Control Panel (ECP) component improperly used static validationKey and decryptionKey values for ViewState protection across all installations instead of generating unique keys per deployment.

This meant that every Exchange Server had the same cryptographic keys, making them vulnerable to the same type of ViewState code injection attack that Microsoft Threat Intelligence is now warning about in ASP.NET applications.

Exploitation required only a valid authenticated session—a relatively low bar in enterprise environments where most users can authenticate to the Exchange Server.

Attackers could:

1. Extract key details from the web.config file, which contained the fixed validationKey and decryptionKey.

2. Collect additional session-specific values, such as:

   • ViewStateUserKey (found in the ASP.NET SessionID cookie).

   • ViewStateGenerator (visible in the HTML source of the page).

3. Generate a malicious ViewState payload using the tool ysoserial.net, embedding arbitrary .NET code execution.

4. Send the crafted ViewState request back to the server via a simple browser request.

This resulted in remote code execution as SYSTEM, allowing attackers to completely compromise the Exchange Server.

The Broader Lesson: Static Keys Are a Disaster Waiting to Happen

CVE-2020-0688 demonstrated how hardcoded machine keys open the door for trivial, authenticated RCE attacks. The same underlying issue—developers reusing fixed cryptographic keys—is now surfacing in thousands of ASP.NET applications through publicly disclosed machine keys.

In contrast to the Exchange Server vulnerability, where the static keys were built into the software itself, the new ASP.NET machine key issue stems from developers copying keys from public sources like GitHub and documentation. However, the attack path remains nearly identical:

• Obtain or find a machine key (publicly disclosed or hardcoded).

• Craft a malicious ViewState payload using that key.

• Send the payload to the target web application and gain RCE.

Just as Microsoft patched CVE-2020-0688 by ensuring unique machine keys are generated during Exchange Server installation, organizations must immediately rotate and secure their ASP.NET machine keys to prevent similar attacks.

Key Takeaway for ASP.NET Developers and Admins

The fixed cryptographic key flaw in Exchange Server was patched in February 2020, but it remains a relevant warning for modern ASP.NET applications. The mass exposure of machine keys in public repositories represents an even more scalable threat, as attackers can now:

• Harvest thousands of publicly disclosed machine keys with minimal effort.

• Use off-the-shelf tooling like ysoserial.net to generate payloads.

• Exploit ViewState code injection on vulnerable servers without needing stolen credentials.