In February 2025, Microsoft Threat Intelligence warned that developers had been copying ASP.NET machine keys from public code samples, documentation and repositories into their own web applications, and that attackers were using those same public keys to take over servers. Machine keys sign and encrypt ASP.NET ViewState data. Anyone who knows an application's keys can craft a malicious ViewState that the server accepts and runs. In December 2024, Microsoft saw an unattributed actor do exactly that with one publicly known key, loading the Godzilla post-exploitation framework onto an IIS web server. Microsoft said it had identified more than 3,000 publicly disclosed keys that could be used this way, published their hashes and a checking script, and removed sample keys from its own documentation. It urged organisations never to copy keys from public sources and to rotate them regularly.
Key takeaways
- ASP.NET machine keys (ValidationKey and DecryptionKey) protect ViewState; if an attacker knows them, a forged ViewState gives remote code execution on the IIS server.
- Developers had copied machine keys from public documentation and repositories, so many applications shared keys that anyone could look up.
- In December 2024 Microsoft observed an attacker using one such public key to deliver the Godzilla post-exploitation framework.
- Microsoft identified more than 3,000 publicly disclosed keys, published hashes to help find them, and removed samples from its own documentation.
- The identity lesson: a cryptographic key copied from the internet is not a secret, and it turns every application that uses it into a shared, open door.
At a glance
| Organisations | Organisations running ASP.NET web applications on IIS with publicly disclosed machine keys; Microsoft (discovery and guidance) |
|---|---|
| When | Attack observed December 2024; disclosed by Microsoft 6 February 2025 |
| Attacker | Unattributed, according to Microsoft |
| Entry point | A malicious ViewState sent in a POST request, signed with a publicly known ASP.NET machine key |
| Identities abused | Static ASP.NET machine keys (ValidationKey and DecryptionKey) copied from public sources into web.config files |
| Impact | Remote code execution on at least one IIS server and deployment of the Godzilla framework; more than 3,000 public keys identified as usable for similar attacks |
| Category | NHI. Incident class: confirmed NHI breach (publicly disclosed cryptographic key used for code execution) |
What happened
ViewState is how ASP.NET Web Forms preserve page state between requests. It sits in a hidden field and is protected by two machine keys: a ValidationKey that signs it and a DecryptionKey that can encrypt it. The keys are either generated automatically per machine or fixed in the application's configuration, often so that servers in a web farm share them. "If these keys are stolen or made accessible to threat actors, these threat actors can craft a malicious ViewState using the stolen keys and send it to the website via a POST request," Microsoft explained. The server then validates and runs it, "providing the threat actor remote code execution capabilities on the target IIS web server."
"In December 2024, Microsoft Threat Intelligence observed limited activity by an unattributed threat actor using a publicly available, static ASP.NET machine key to inject malicious code and deliver the Godzilla post-exploitation framework," Microsoft wrote. The malicious ViewState loaded an assembly that ran Godzilla, whose functions include "executing malicious commands, injecting shellcode into processes, and more."
While investigating, Microsoft found the root cause was not theft: developers "have incorporated various publicly disclosed ASP.NET machine keys from publicly accessible resources, such as code documentation and repositories." It identified "over 3,000 publicly disclosed keys that could be used for these types of attacks." Microsoft noted that earlier ViewState attacks typically used keys stolen and sold on dark web forums, but "these publicly disclosed keys could pose a higher risk because they are available in multiple code repositories and could have been pushed into development code without modification." It added Defender for Endpoint alerts for publicly disclosed keys, published hashes of the known keys and a checking script on GitHub, and "removed key samples from limited instances where they were included in our own public documentation."
Timeline
| Date | Event |
|---|---|
| December 2024 | Microsoft observes an attacker using a publicly disclosed machine key to deploy Godzilla on an IIS server. |
| 6 February 2025 | Microsoft publishes its warning, the 3,000-key finding and remediation guidance. |
| 10 February 2025 | Coverage continues, including Petri's summary for administrators. |
How it happened: the identity attack path
- Keys copied from public sources. Developers pasted machine keys from documentation or repositories into web.config.
- Keys shared across the internet. The same keys ended up in many applications, and anyone could find them.
- Forged ViewState. The attacker signed a malicious ViewState with a known key and sent it in a POST request.
- Code execution. The server validated the payload and executed it in the IIS worker process.
- Post-exploitation. Godzilla was loaded, enabling command execution and shellcode injection.
Impact
- Confirmed: remote code execution and Godzilla deployment on at least one IIS server in December 2024.
- Exposure: more than 3,000 publicly disclosed keys usable for similar attacks on any application that adopted them.
- Remediation burden: key rotation across web farms, and investigation of servers that may already be compromised.
What this means for NHI governance
A machine key is a non-human credential: it lets the server trust data as if it came from itself. Copying one from a code sample makes it public by definition, so every application using that key trusts anyone who has read the same sample. No leak, theft or phishing is needed. The same key class was later abused in a very different way in the ToolShell SharePoint attacks, where attackers stole machine keys from compromised servers to keep access after patching.
Keys used by applications need an inventory like any other secret: where they are configured, whether they are unique, when they were last rotated. Generating keys per deployment, keeping them out of configuration committed to source control and rotating them after any suspected exposure removes this whole class of attack. See our Cryptographic Key Management Guide and Secrets Management Guide.
Recommendations
- Never copy keys from public sources. Generate unique machine keys for each application or web farm. See the Cryptographic Key Management Guide.
- Check your keys against Microsoft's list. Use Microsoft's published hashes and script to find publicly disclosed keys in your environment.
- Rotate machine keys regularly and after any exposure. Rotate across all servers in a farm together.
- Keep keys out of source control. Store configuration secrets in a vault or protected configuration. See our Secrets Management Guide.
- Investigate servers that used public keys. Rotation does not remove implants already installed; check for signs of compromise. See the Leaked Credential Response Playbook.
Frequently asked questions
What is a ViewState code injection attack?
An attacker who knows an ASP.NET application's machine keys crafts a malicious ViewState and sends it to the server. Because it is correctly signed, the server accepts and runs it, giving the attacker remote code execution.
How did attackers get the ASP.NET machine keys?
In the case Microsoft observed, they did not need to steal them. Developers had copied keys from public documentation and repositories, so the keys were already public. Microsoft found more than 3,000 such keys.
What should organisations do?
Check machine keys against Microsoft's list of publicly disclosed keys, generate unique keys, rotate them regularly and investigate any server that used a public key for signs of compromise.
Related NHI Mgmt Group resources
ToolShell SharePoint Exploitation 2025 · Gladinet Hard-Coded Keys Exploited · Cryptographic Key Management Guide · Secrets Management Guide · Leaked Credential Response Playbook
How NHI Mgmt Group can help
Application keys are often the least visible credentials in an estate. We help teams inventory them, replace shared or copied keys and set rotation that works across server farms. See our NHI and AI agent security training.
References
- Microsoft Threat Intelligence: Code injection attacks using publicly disclosed ASP.NET machine keys (6 February 2025)
- BleepingComputer: Microsoft says attackers use exposed ASP.NET keys to deploy malware (6 February 2025)
- Petri: Hackers Exploit Publicly Leaked ASP.NET Keys for Code Injection Attacks (10 February 2025)
