KnowledgeDeliver Zero-Day Exploited to Drop Web Shells

Attackers exploited a critical zero-day vulnerability in KnowledgeDeliver, a learning management system used across multiple enterprise deployments, to install the Godzilla web shell on compromised servers. The flaw, tracked as CVE-2026-5426, requires no authentication to exploit. The root cause is a hardcoded ASP.NET machine key shipped in the vendor's default web.config file, shared identically across all customer installations.

Mandiant responded to one such incident in late 2025 and published their full analysis this week.

How the ViewState Deserialization Attack Works

ASP.NET uses a machine key to sign and encrypt ViewState payloads. These are the serialized state objects that web forms use to persist data between requests. If an attacker knows the machine key, they can craft a malicious signed payload and submit it to the server. The server trusts it, deserializes it, and executes whatever code is embedded inside.

KnowledgeDeliver installations deployed before February 24, 2026 used a standardized web.config with hardcoded machineKey values. Every deployment had the same key. Once attackers obtained it, they had a valid signing credential for any unpatched KnowledgeDeliver instance on the internet. No login required.

Godzilla Web Shell Delivery and Post-Exploitation

After gaining remote code execution through the deserialization attack, the threat actor deployed Godzilla, a .NET-based in-memory web shell also known as BlueBeam. Godzilla runs entirely in memory, which makes it harder to detect through traditional file-based scanning. Microsoft observed similar Godzilla deployments in late 2024. ASEC reported Godzilla being used in ViewState attacks against financial sector companies back in August 2024.

Post-exploitation was methodical. The attacker modified a JavaScript file in the application to push a fake "security authentication plugin" prompt to active users. Clicking through that prompt fetched and executed a malicious script from an attacker-controlled domain. Machines that ran it were infected with a Cobalt Strike beacon, giving the attacker persistent remote access.

The Cobalt Strike payload was encrypted using the name of the targeted organization as part of the key. That detail matters. It means this was not opportunistic mass exploitation. The attacker prepared custom payloads for specific targets.

What Developers and Platform Teams Are Exposed To

Any organization running KnowledgeDeliver on a pre-February 2026 deployment is exposed if they have not rotated their machine keys. But the broader risk extends to any ASP.NET application where the machineKey values in web.config were generated once and never changed, or worse, copied from documentation or shared templates.

This is the third major hardcoded machine key incident in roughly 12 months. Gladinet CentreStack was hit in March 2025. Microsoft SharePoint servers were compromised in July 2025 after machine key theft. Sitecore servers were targeted by state-sponsored actors using the same technique to deploy reconnaissance tooling. The pattern is consistent and accelerating.

How to Protect Your ASP.NET Applications

Rotate your machine keys immediately if you are running KnowledgeDeliver or any ASP.NET application that has not had its keys changed since initial deployment. Each environment (dev, staging, production) should have a unique key. Never ship a web.config with static machineKey values.

Steps to take now:

• Generate new machineKey values using a cryptographically secure method and deploy them per environment.
• Audit your web.config files across all deployments for hardcoded or duplicated keys.
• Review IIS and application logs for unusual ViewState submissions or unexpected deserialization errors.
• Check for in-memory processes and unexpected JavaScript modifications in your web root.
• Block outbound connections from your web servers to unknown external domains.

For ongoing exposure detection, you can scan your application with VibeWShield to identify misconfigured ASP.NET settings and other deserialization risks before attackers do.

Why is a shared machine key so dangerous? The machine key is essentially a signing secret. If two deployments share the same key, a payload crafted and tested against one installation works against every other installation using that key. Attackers only need to extract it once.

Does rotating the machine key break anything? Active user sessions will be invalidated because existing ViewState and session tokens were signed with the old key. Plan the rotation during a maintenance window and communicate the expected session reset to users.

How do I check if my application was already compromised? Look for unexpected files in your web root, especially .aspx files you did not deploy. Check IIS logs for POST requests to unusual endpoints. Review application JavaScript files for injected code and monitor for outbound DNS or HTTP requests to unfamiliar domains from the web server process.

Run a free scan on your web application at VibeWShield to check for deserialization vulnerabilities and misconfigured ASP.NET settings.