KnowledgeDeliver CVE-2026-5426: detecting ViewState deserialisation and Godzilla web shells

Contribution

This post examines the KnowledgeDeliver CVE-2026-5426 exploitation lifecycle beyond the CVE summary. It gives defenders practical detection patterns for anomalous dual User-Agent strings, failed ViewState validation, and BLUEBEAM (Godzilla) activity inside the IIS worker process (w3wp.exe). It also explains the configuration pattern that made the incident more than a one-site compromise: vendor-supplied ASP.NET machineKey values reused across customer deployments.

The pattern

KnowledgeDeliver is a specialist Learning Management System (LMS) developed by Digital Knowledge, a Tokyo-based software vendor. Public reporting describes use across Japanese corporate and educational environments. In early 2026, a critical vulnerability was disclosed, now tracked as CVE-2026-5426. The vulnerability is not a flaw in the application's business logic, but a systemic failure in the platform's security configuration: identical, hard-coded ASP.NET machineKey values across customer deployments.

The ASP.NET machineKey is the fundamental cryptographic secret for the framework's security subsystem. It is responsible for providing the data integrity and encryption for several key features, including the ViewState, Forms Authentication cookies, and Membership tokens. The ViewState specifically is a hidden field (__VIEWSTATE) used by ASP.NET Web Forms to maintain the state of UI controls across successive requests. To make sure that a client cannot modify the server-side state, ASP.NET uses the machineKey to create an HMAC signature and, in many cases, to encrypt the payload.

Because KnowledgeDeliver provided a standardised web.config file that included a fixed validationKey and decryptionKey, exposed instances that retained those keys shared the same cryptographic root of trust. Once the keys were public or otherwise recovered, an unauthenticated attacker could forge a valid, signed ViewState payload containing a malicious object.

This is a classic 'Insecure Deserialisation' attack. When the KnowledgeDeliver server receives the POST request, the ASP.NET framework attempts to restore the page state by deserialising the __VIEWSTATE parameter. During this process, the framework instantiates the objects contained within the payload. By using well-known gadgets within the .NET Framework, such as those targeting the ObjectStateFormatter, the attacker can achieve arbitrary Remote Code Execution (RCE) in the security context of the IIS worker process. The attacker advantage is reliability: as long as the hard-coded key remains in use, application-level patches may not remove the condition that makes forged ViewState payloads valid.

The campaign observed by Mandiant did not stop at initial access. Once RCE was achieved, the threat actors focused on surgical persistence. They deployed a .NET-based in-memory web shell known as BLUEBEAM (or Godzilla). This malware resides entirely within the w3wp.exe process, providing a sophisticated terminal that uses the web server's existing HTTP communication channel to receive encrypted commands. The primary goal of this particular campaign appeared to be supply-chain pivot: attackers modified the front-end JavaScript files of the LMS to prompt legitimate users with fake alerts, tricking them into downloading Cobalt Strike loaders disguised as "security plugins."

Why it matters to cloud defenders

For security engineers operating Windows-based workloads in AWS, Azure, or Google Cloud, the KnowledgeDeliver incident shows how even 'niche' application vulnerabilities can represent high-impact entry points into a cloud environment. The move toward automated cloud deployments has introduced a specific class of risk: the 'standardised configuration anti-pattern.'

In a typical cloud-native deployment, infrastructure is provisioned through Terraform or ARM templates, and applications are installed via automated scripts or container images. If a vendor provides a standardised 'template' configuration, as Digital Knowledge did with the KnowledgeDeliver web.config, they are inadvertently creating a uniform attack surface. In a cloud environment where scaling is horizontal and identities are often tied to the compute instance, a single compromised web server can become a launchpad for credential theft and lateral movement across the VPC or VNet.

The post-exploitation TTPs observed in this campaign, specifically the use of BLUEBEAM/Godzilla, highlight a gap in many cloud endpoint detection strategies. Traditional File Integrity Monitoring (FIM) and AV solutions are designed to catch new .aspx or .php files being written to the web root. However, a shell that lives entirely in-memory within the IIS process leaves no disk-based footprints for these tools to find. Defenders must pivot their detection logic away from the file system and toward process execution and memory-resident telemetry.

Defenders also need to account for the 'authentication trap.' Because this vulnerability resides in the ASP.NET ViewState handler, the exploitation occurs before the application's own authentication or authorisation filters are even invoked. A WAF that is not specifically tuned to inspect the entropy and structure of ViewState payloads will likely see the malicious request as a standard, albeit large, postback. For cloud defenders, this means that protection must be applied at the ingress, through deeply-inspected WAF rules, and at the endpoint, through behavioural monitoring of the web service account.

ATT&CK mapping

The KnowledgeDeliver exploitation chain spans initial access, a web shell foothold, Windows permission changes and compromised-site delivery to users. The mappings below match the techniques declared in this article's metadata.

Initial Access: Exploit Public-Facing Application (T1190) The compromise begins with an unauthenticated POST request to a KnowledgeDeliver endpoint. The vulnerability exists within the logic that parses the __VIEWSTATE parameter. This is a framework-level exploit of a public application, making it a clear instance of T1190.

Persistence: Server Software Component: Web Shell (T1505.003) Unlike older web shells that required a physical file to be present in the web root, the BLUEBEAM/Godzilla shell resides in memory inside the IIS worker process. That makes it resistant to file-based cleanup and web-root scanning, but it does not survive an application pool recycle or server reboot unless the attacker has another way to reload it.

Defence Evasion: File and Directory Permissions Modification: Windows Permissions (T1222.001) Attackers were observed using icacls, a standard Windows utility, to modify the permissions of the web application directory. By granting "Everyone" full access, the attacker reduces the chance that later file-tampering operations, such as modifying existing .js files to include malicious script tags, are blocked by OS-level permissions. MITRE maps this Windows ACL manipulation to T1222.001 rather than indicator removal.

Initial Access: Drive-by Compromise (T1189) The final stage of the attack involved a pivot from the server to users. By injecting remote script loaders into the LMS front-end code, the attackers served fake "security authentication plugin" banners to legitimate users already visiting the trusted site. That is closer to a compromised-site or watering-hole delivery pattern than spearphishing, because the link was not delivered through a targeted phishing message.

Detection guidance

Detecting the KnowledgeDeliver campaign requires a combination of network-layer inspection, framework-level logging, and behavioural endpoint analysis. Individual signals may be weak, but their correlation provides a high-confidence alert.

1. Dual User-Agent Detection Logic

Mandiant observed anomalous 'concatenated' or recursive User-Agent strings in ViewState exploitation activity. This occurs when the exploitation script appends its own browser string to the one it is already using, or when multiple layers of proxies and automated handlers are involved in the forge-and-send process.

The Signal: Create a rule in your WAF or SIEM to identify User-Agent headers that contain a high density of keywords such as AppleWebKit, Mozilla/5.0, or Safari/ repeated more than once. Specifically, look for cases where two full, valid Chrome or Firefox strings are joined without standard separators.

Example Logic (pseudo-Regex): (?i)(Mozilla/5.0.*){2,}

2. Monitoring ASP.NET Event ID 1316 and Event Code 4009

The Windows Application Log is useful for failed ViewState validation, but the field names matter. Event ID 1316 is the Windows event record emitted by ASP.NET. Event code 4009 appears inside the ASP.NET event details and represents a ViewState verification failure, including messages such as "The viewstate supplied failed integrity check" or "Viewstate was invalid."

Treat 4009 as evidence of failed probing, malformed payloads, or attempts made with the wrong machineKey. High-frequency 4009 events from a single source are worth investigating, especially when paired with large __VIEWSTATE POST bodies or anomalous User-Agent strings. Do not treat 4009 as proof that the attacker has the correct key. If an attacker forges a valid ViewState payload with the hard-coded machineKey, ASP.NET may accept the postback and no 4009 event is emitted.

The dangerous case is therefore a correlation problem: suspicious ViewState traffic with no matching validation failure, followed by downstream signs of code execution such as w3wp.exe spawning command shells, icacls changing directory ACLs, or JavaScript files changing under the LMS web root.

3. Behavioural Hunting for BLUEBEAM (Godzilla)

Because the BLUEBEAM shell resides in memory, defenders must hunt for its interaction with the operating system. The most common signal is the IIS worker process (w3wp.exe) spawning child processes that are fundamentally inconsistent with a web server's role.

Hunting Query (Process Telemetry): Identify any occurrences where w3wp.exe is the parent process for:

• cmd.exe /c ... (especially if accompanied by recon commands like whoami, dir, or net user)
• powershell.exe (with -EncodedCommand or unusual network activity)
• icacls.exe (specifically look for arguments like Everyone:F or Everyone:(OI)(CI)F, mapped to T1222.001)
• net.exe or nltest.exe (used for domain reconnaissance)

4. Semantic Log Matching (IIS WAF Context)

Correlate the POST requests to endpoints like /KnowledgeDeliver/Default.aspx or other LMS entry points with the size of the __VIEWSTATE parameter. While ViewState is often large, a sudden spike in size accompanied by anomalous User-Agent strings is a useful indicator of a possible multi-stage deserialisation payload.

What to do now

If your organisation uses KnowledgeDeliver or any similar ASP.NET-based Learning Management System, the following remediation steps are the practical starting point.

1. Immediate MachineKey Rotation: Inspect your web.config file. If you see a hard-coded machineKey that was provided as part of a vendor template, it must be rotated immediately. Every production instance must have its own, unique, cryptographically strong key. Microsoft provides built-in utilities for generating these.
2. Audit for File Tampering: Perform a recursive hash check of the web root (C:\inetpub\wwwroot\...). Compare the current state against a known-clean backup. Pay specific attention to common JavaScript files (e.g., jquery.js, main.js) used across all pages of the application.
3. Implement WAF Geofencing and Rate Limiting: If KnowledgeDeliver is only intended for use by your regional staff, apply strict geofencing at the WAF layer. Additionally, implement rate limiting on the POST method for any page where ViewState is used, as exploitation involves a level of trial-and-error that generates significant noise.
4. Harden ViewState Globally: Across your entire ASP.NET estate, make sure that EnableViewStateMac is set to true (this is mandated in modern versions) and that ViewStateEncryptionMode is set to Always. While these do not prevent an attack if the key is already compromised, they increase the complexity of the exploitation and improve the visibility of failure events.

The KnowledgeDeliver CVE-2026-5426 incident shows that security is a property of the whole deployment, not only the application code. When standardised configurations become a shared point of failure, defenders need telemetry that reaches the framework, the web server process, and the files served back to users.

Sources

• Mandiant Threat Intelligence: "Exploitation of KnowledgeDeliver via ViewState Deserialization Vulnerability" (May 2026)
• Rescana Vulnerability Research: "Active Exploitation of CVE-2026-5426 in KnowledgeDeliver LMS" (May 2026)