COPY-PASTING KEYS TO THE KINGDOM:HOW A DEVELOPMENT OVERSIGHT LET A HACKER IN, AND HOW A RAPID AFTER-HOURS RESPONSE STOPPED THEM

Executive Summary

During routine security monitoring, NetCyberOps detected and successfully neutralized an active cyberattack targeting the company's public-facing website. An attacker attempted to seize control of the web server but was blocked before any damage could be done.

The vulnerability came from a common mistake made during website development. Instead of creating unique, private encryption keys for the website, developers used standard sample keys copied directly from public internet documentation and code repositories.

Because these keys are public knowledge, the hacker used them to create a malicious data package. When submitted to the website, the server recognized the public key, assumed the package was safe, and executed the hacker's hidden code, granting remote control over the server.

The security team immediately alerted the client after hours on the weekend and quickly executed a containment strategy using Endpoint Detection and Response (EDR) software. The team developed a custom rule that was able to detect the malicious activity and kill the process, preventing it from launching administrative tools. This effectively handcuffed the attack. Even though they were "inside" the system, they were blocked from running any commands.

The attacker then tried to use Discord to bypass security and establish a permanent backdoor into the network, but automated security rules blocked the connection entirely as well.

Following official Microsoft guidance, the client took two steps to permanently secure their environment. They deleted the compromised public keys and generated brand-new, unique, secure keys. They also updated their cloud setup templates (Azure golden images) so that any new servers deployed in the future will automatically use secure keys, preventing this vulnerability from ever returning.

This incident highlights the critical need for secure coding standards, automated endpoint defenses, and 24/7 security monitoring to catch threats before they turn into major breaches.

Incident Timeline

3 a.m.

The NCO security team detected a PowerShell process spawned as a child of the IIS worker process (w3wp.exe), an abnormal and inherently suspicious behavior, as the IIS worker process has no legitimate operational reason to launch a command interpreter.

This anomalous process relationship served as the primary indicator of compromise. Further analysis revealed that the spawned PowerShell process issued a DNS request to canarytokens.com, a well-known service used to generate trackable tokens that alert their owner when accessed.

This indicates the attacker was leveraging a canary token as a reconnaissance and callback mechanism, likely to confirm successful code execution on the target system and verify outbound connectivity from the compromised server.

The combination of an IIS worker process spawning PowerShell and that process reaching out to an external callback domain provided clear and high confidence evidence that the ViewState code injection attack had achieved remote code execution and that the attacker was actively probing the environment.

3:30 a.m.

After confirming the anomalous behavior, the on-call team began investigating the root cause of how the IIS worker process was able to spawn PowerShell. Recognizing that the activity originated from the web server process, the team conducted targeted research to understand what attack techniques could result in w3wp.exe launching a child process.

This research led the team to the Microsoft Threat Intelligence blog post published in February 2025 documenting ViewState code injection attacks leveraging publicly disclosed ASP.NET machine keys.

Cross-referencing the observed behavior, an IIS worker process spawning a command interpreter followed by an external DNS callback, against the attack chain described in Microsoft's documentation, the team was able to conclusively identify the attack technique and confirm that the customer's environment was likely running ASP.NET machine keys sourced from a public resource.

Customer Response and Mitigation

With the attack technique confirmed, the on-call team immediately developed and deployed a rule to contain the threat and prevent further attacker action. The rule was specifically designed to detect any instance of a command interpreter, including PowerShell and Command Prompt, being spawned as a child process of w3wp.exe, and upon detection, would automatically kill the offending process and quarantine it, neutralizing any further attempts by the attacker to execute commands through the compromised web server in real time.

This containment measure proved immediately effective, as subsequent exploitation attempts by the attacker, including efforts to establish command and control through alternative channels such as Discord webhooks, were detected and terminated before any further impact could occur.

With active containment in place, the team turned its attention to permanent remediation and engaged the customer with the recommendations outlined in the Microsoft Threat Intelligence advisory. The customer responded promptly, working through the guidance to identify and rotate the publicly disclosed ASP.NET machine keys across their affected systems.

Recognizing that the misconfiguration had been baked into their standard server build process, the customer took the additional and critical step of updating their Azure golden images, the virtualized IIS server templates used to provision new infrastructure, ensuring that all future server deployments would be built with securely generated, environment-specific machine keys rather than publicly known values, permanently closing the vulnerability at the source.

Threat Overview: What Are ASP.NET Machine Keys?

ASP.NET web applications running on the .NET Framework use a feature called ViewState to preserve the state of web pages and controls between user interactions. ViewState data is serialized, Base64-encoded, and stored in a hidden field within the HTML of each page, traveling back and forth between the browser and the web server with each request. Because this data is processed server-side and can influence application behavior, it must be protected against tampering and unauthorized inspection.

To provide this protection, the ASP.NET page framework relies on two cryptographic secrets stored in the application's configuration: the ValidationKey, which is used to generate a message authentication code (MAC) attached to the ViewState to verify its integrity, and the DecryptionKey, which is used to encrypt ViewState contents when encryption is enabled. These keys are either auto-generated by the framework and stored in the system registry, or specified manually by administrators in the application's web.config file.

When machine keys are manually specified, a common requirement in web farm environments where multiple servers must consistently encrypt and validate the same ViewState data, they become a static secret upon which the security of the entire ViewState mechanism depends.

Publicly Known Keys

The vulnerability exploited in this incident did not require the attacker to steal keys through a prior breach or purchase them on criminal forums. Instead, the affected environment had incorporated ASP.NET machine keys sourced from publicly accessible resources, such as code documentation, tutorials, and public code repositories, and deployed those keys into production without modification.

This is an insecure but not uncommon practice, as developers may copy configuration examples directly from reference material without recognizing that the keys embedded in those examples are permanently and publicly known.

This creates a configuration-based vulnerability rather than a software flaw. No patch exists to remediate it because ASP.NET is functioning exactly as designed. The risk lies entirely in the secrecy, or lack thereof, of the keys in use.

How the Attack Achieves Remote Code Execution

The attack exploits the trust the ASP.NET runtime places in ViewState data that has been successfully validated and decrypted using the correct machine keys. The attack chain proceeds as follows:

Key Identification: The attacker determines that the target web application is using a publicly known machine key through reconnaissance or by testing against lists of known-public keys.

Malicious Payload Crafting: Using the known ValidationKey and DecryptionKey, the attacker constructs a malicious ViewState payload. Rather than containing legitimate page state data, this payload contains serialized .NET objects designed to execute arbitrary code upon deserialization. The payload is cryptographically signed and optionally encrypted using the stolen keys, making it appear completely authentic to the server.

Payload Delivery: The attacker submits the malicious ViewState to the target application via a standard HTTP POST request, the same mechanism used by ordinary browser interactions. No authentication, vulnerability chaining, or network exploit is required. The request is visually and structurally identical to legitimate application traffic.

Server-Side Execution: When the ASP.NET runtime receives the request, it decrypts and validates the ViewState using the configured machine keys. Because the attacker crafted the payload with the correct keys, validation succeeds, and the runtime proceeds to deserialize the payload. This deserialization triggers the embedded malicious code, which is loaded into the IIS worker process (w3wp.exe) and executed under the identity and privileges of the IIS application pool, granting the attacker remote code execution on the server.

Post-Exploitation: With remote code execution established, the attacker is positioned to perform any action available to the IIS application pool account, including spawning processes, executing commands, establishing persistence, conducting internal reconnaissance, and attempting lateral movement within the environment.

Attack Impact

Several characteristics make this attack vector especially difficult to defend against through conventional means:

No software patch applies: This is not a bug in ASP.NET, it is the framework operating as intended. Remediation requires a configuration change, not a software update, making it easy to overlook in standard patch management processes.

Malicious requests are indistinguishable from legitimate traffic at the network layer: The HTTP POST carrying the payload has no anomalous structure, exploit shellcode, or unusual headers that network-based controls would flag.

No authentication is required: Any publicly reachable ASP.NET application using a known key is fully exposed, regardless of whether the attacker possesses valid credentials.

Execution occurs within a trusted process: The code runs inside w3wp.exe, the standard IIS worker process, which is expected to be active and processing web requests at all times. Without specific behavioral monitoring of this process, initial compromise may go undetected.

In-memory execution is possible: Attackers can load malicious code entirely within the worker process memory, leaving few or no artifacts on disk and significantly complicating forensic analysis and detection.

Action Items

Remediating this vulnerability requires identifying and replacing any publicly disclosed machine keys, then adopting practices to prevent their reintroduction. Microsoft has published a repository of known publicly disclosed key hashes along with a script to compare those values against keys configured in your environment. Any matches should be treated as urgent and acted upon immediately.

Exposed keys must be rotated by generating new cryptographically strong values through the IIS Manager console or PowerShell and applying them to all affected systems. In single-server environments where fixed keys are unnecessary, the preferred approach is to remove the machineKey element from web.config entirely, reverting the application to ASP.NET's auto-generated keys stored securely in the system registry. In web farm environments, newly generated keys must be applied consistently across all nodes simultaneously.

Beyond key rotation, Microsoft recommends encrypting sensitive web.config sections to prevent key values from existing in plaintext on the filesystem, and enabling Attack Surface Reduction rules, particularly Block Webshell Creation for Servers, to limit post-exploitation options available to an attacker.

Organizations should also implement EDR behavioral rules to detect and block command interpreters spawned as child processes of w3wp.exe, as this parent-child process relationship has no legitimate use case and is a reliable indicator of exploitation. SIEM platforms should be configured to monitor Windows Event ID 4663 to alert on unauthorized access to web.config and machine.config files, providing early warning of potential key theft or configuration tampering.

Finally, and most importantly, machine keys must never be sourced from public documentation, repositories, or any publicly accessible resource. Each environment should use independently generated keys, and this requirement should be enforced as part of standard deployment and code review processes.

Incident Timeline

CURIOUS WHAT IT TAKES TO GET SECURE?