Understanding ViewState Deserialization Vulnerabilities in KnowledgeDeliver

By: Takahiro Sugiyama, Peter Revelant, Mathew Potaczek

Understanding the Incident

In late 2025, Mandiant was called to handle a serious security breach linked to a compromised web server operating the KnowledgeDeliver, a Learning Management System widely used in Japan. Analysts uncovered a significant security flaw that enabled unauthenticated Remote Code Execution (RCE). An unidentified attacker exploited this vulnerability to inject malicious code into the platform, threatening users accessing the LMS.

At the heart of this vulnerability was the reliance on the same pre-shared ASP.NET machine keys across various customer installations. Initially identified as a zero-day exploit, the issue is now classified under CVE-2026-5426.

Details of the Vulnerability

Prior to February 24, 2026, KnowledgeDeliver installations utilized a standard web.config configuration file from the vendor. This file contained hardcoded machineKey values essential for the ASP.NET framework's data encryption and signing, including ViewState payloads.

The uniformity of these machine keys across separate customer environments meant that if an attacker acquired the key from one instance, they could jeopardize any other instance of KnowledgeDeliver accessible over the internet. This configuration flaw laid the groundwork for a vulnerable ecosystem.

For instance, the critical segment of the web.config file might include lines such as:

<machineKey decryptionKey="<REDACTED>" validationKey="<REDACTED>" />

The ASP.NET ViewState mechanism is integral to maintaining page states across session interactions. If an attacker knows the machine key, they can create a harmful ViewState payload. By delivering this malicious payload through an HTTP request via the __VIEWSTATE parameter, they can leverage server-side deserialization vulnerabilities.

This method resembles previous incidents, such as the ViewState Deserialization Zero-Day Vulnerability affecting Sitecore and the code injection attacks leveraging publicly disclosed ASP.NET machine keys as outlined by Microsoft. This reinforces the need for unique and secure machine keys across installations.

Insights into Post-Exploitation Activities

After breaching the system, the attackers focused on solidifying their presence and amplifying the damage from the compromise.

Deployment of the BLUEBEAM Web Shell

The attackers unleashed a .NET-based in-memory web shell known as BLUEBEAM, which has also been dubbed Godzilla. This tool aligns with Microsoft’s findings. Operating entirely within the IIS worker process (specifically w3wp.exe), BLUEBEAM escapes detection from conventional file-based scanning methods. It empowers the attackers to execute further commands and deliver additional payloads by transmitting encrypted information through HTTP POST request bodies.

File Tampering Tactics

Commands executed by the attackers demonstrated their quest to strengthen control over the server's file system:

1. Modification of Permissions: The attackers used icacls to grant "Everyone" unrestricted access to the web application directory.

2. JavaScript Manipulation: They tampered with an application JavaScript file to:

• Show a misleading security alert, urging users to install a "security authentication plugin".

• Silently execute a remote malicious script hosted on an attacker-controlled domain.

Cobalt Strike Backdoor Deployment

The remote script convinced users to download a counterfeit installer, infecting their workstations with a Cobalt Strike BEACON backdoor. This payload was notably encrypted with a key that included the name of the hacked organization, suggesting that the attackers tailored this specifically for their chosen target.

Detecting and Addressing This Activity

To combat such attacks, organizations need to monitor specific indicators linked to ViewState exploitation and subsequent malicious activities.

1. Application Event Logs (Event ID 1316)

Keep an eye on the Windows Application log, specifically for Event ID 1316 generated by ASP.NET 4.0.30319.0 (or its variants).

• Failed Attempt (Integrity Failure): Event code: 4009-++-Viewstate verification failed. Reason: The viewstate supplied failed integrity check. This may indicate an attack attempt using an incorrect key.

• Successful Execution (Invalid ViewState): Event code: 4009-++-Viewstate verification failed. Reason: Viewstate was invalid. Confirms that integrity checks passed. The server likely attempted deserialization of the payload.

Mandiant was able to decrypt payload strings logged in the event messages using the server’s machine keys, recovering a payload linked to the BLUEBEAM web shell.

2. Suspicious Process Activity

Watch for unusual child processes arising from w3wp.exe. Notable commands may include:

• cmd.exe /c ...

• whoami

• powershell.exe

3. File Integrity Monitoring

Monitor for unauthorized alterations to .js, .aspx, and .config files in the web root directory. Key indicators include the addition of remote script loaders or unexpected code in commonly used libraries.

4. Anomalous User-Agent Strings

Mandiant reported spotting User-Agent strings that combined two identifiable elements, consistent with those noted in the ViewState Deserialization Zero-Day vulnerability. Cybersecurity teams should examine web request logs for such unusual User-Agent string combinations, which may resemble these examples:

• Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

• Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw) Presto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

• Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) chromeframe/10.0.648.205 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Strategies for Remediation

• Rotate Machine Keys: Organizations should urgently generate unique, cryptographically strong machine keys for each KnowledgeDeliver instance to invalidate any shared secrets.

• Restrict Access: Limit access to the LMS from known organizational IP ranges whenever feasible.

• Conduct Investigations: It’s crucial to hunt for signs of exploitation and perform in-depth investigations where necessary.

Potential Implications

The KnowledgeDeliver incident underscores the grave risks that come from using shared secrets across server deployments. A single exposed key can jeopardize an entire network of installations. Organizations must adopt unique secrets alongside vigilant endpoint monitoring to defend against such deserialization vulnerabilities.

Indicators of Compromise (IOCs)

To aid in identifying the activities described in this report, relevant indicators of compromise (IOCs) are available in a free GTI Collection for registered users.