There is a class of vulnerability that is more unsettling than the typical remote code execution flaw or authentication bypass not because it is technically novel, but because it reveals a design assumption so fundamental that every installation of the affected software inherited the same weakness simultaneously.
CVE-2026-5426 in KnowledgeDeliver is that kind of vulnerability. Digital Knowledge, the developer of the LMS platform, shipped deployments with a standardized web configuration file containing hardcoded machineKey values. Those keys are used by the ASP.NET framework to encrypt and sign data. They are supposed to be secret unique to each installation, generated during deployment, and never shared with anyone outside the organization running the system.
Organizations are increasingly recognizing that enterprise platforms are no longer just operational systems they are critical components of the broader attack surface. As security teams reassess application trust models, identity controls, and configuration hygiene, AI-driven contract lifecycle management is emerging as a strategic capability for improving governance, visibility, and operational resilience across business workflows. Explore how AI is transforming CLM from static repositories into actionable intelligence in this comprehensive research guide. Download the guide
Instead, every KnowledgeDeliver installation before February 24, 2026, was running with the same keys. An attacker who obtained those keys and obtaining them required either reverse engineering the configuration file or accessing any one of the installations where the keys were already present had the cryptographic material to compromise every other installation running the same hardcoded values.
Mandiant has documented what a sophisticated threat actor did with that discovery. The attack chain ends with a Cobalt Strike backdoor encrypted with a key containing the specific victim organization’s name evidence that the threat actors did not stumble into this compromise opportunistically. They prepared for it.
Why Hardcoded MachineKeys Are a Systemic Vulnerability, Not an Individual One
The machineKey in an ASP.NET application is the foundation of the framework’s data security model. It is used to encrypt and sign ViewState the mechanism ASP.NET uses to persist page state across HTTP requests as well as forms authentication tickets, session state, and other data that the application needs to protect from tampering.
The security model depends entirely on the machineKey being secret and unique. If an attacker knows the machineKey for an application, they can forge any data that the application trusts as legitimate including ViewState payloads that the application will deserialise on receipt, executing whatever code the attacker has crafted into the payload.
The ViewState deserialization attack that CVE-2026-5426 enables works through the following sequence: the attacker crafts a malicious ViewState payload a serialised .NET object containing code they want to execute on the server. They sign and encrypt it with the known machineKey. They send it to the target application in a standard HTTP POST request. The application receives the request, validates the signature using its machineKey, finds it valid because the attacker used the correct key, and deserialises the payload executing the attacker’s code with the application’s permissions.
The server has no way to distinguish a legitimate ViewState payload from a malicious one if both are signed with the correct key. The validation mechanism that is supposed to prevent tampering becomes the mechanism that legitimises the attack.
What makes the KnowledgeDeliver case systematically dangerous rather than individually unfortunate is the hardcoding across installations. A single organisation running ASP.NET with a known machineKey has a serious vulnerability. Every organisation running KnowledgeDeliver before the patch date has the same vulnerability simultaneously and an attacker who discovers the hardcoded key has not found one target. They have found every installation of the platform that has not been individually reconfigured.
Mandiant notes that this attack pattern is not new. ViewState deserialization attacks exploiting known machineKeys have previously been used against Sitecore instances and CentreStack deployments, and appear in attacks involving the Godzilla post-exploitation framework. The technique is documented, understood, and apparently being applied systematically against enterprise platforms whose deployments share the same key material.
The Attack Chain From Configuration File to Cobalt Strike
Mandiant’s documentation of the KnowledgeDeliver exploitation provides a detailed attack chain that is worth tracing specifically, because each stage reveals deliberate, sophisticated threat actor behaviour rather than opportunistic exploitation.
Stage one: ViewState deserialization to initial execution. The attacker sends a crafted ViewState payload signed with the hardcoded machineKey to a vulnerable KnowledgeDeliver installation. The server deserialises it, executing the attacker’s initial code. This gives the attacker code execution on the server with the web application’s process permissions not necessarily the highest privilege level, but enough to proceed to the next stage.
Stage two: Godzilla web shell deployment. The attackers used the initial execution to deploy Godzilla web shells also known as Bluebeam in memory. Godzilla is a sophisticated post-exploitation framework that provides attackers with an interactive shell on the compromised server, the ability to execute additional commands and payloads, and persistence mechanisms that survive server restarts. The in-memory deployment is specifically designed to reduce forensic visibility a web shell that exists only in memory leaves fewer artefacts than one written to disk and is harder to detect through file system monitoring.
Stage three: Permission modification and JavaScript injection. With Godzilla established, the attackers modified access permissions to the web application directory expanding their ability to write files and make configuration changes. They then modified an application JavaScript file to load a malicious script. That script displays a fake security alert to users of the KnowledgeDeliver platform, instructing them to install what appears to be a legitimate security plugin. The social engineering layer mirrors the ClickFix technique that has been appearing across other recent campaigns using a trusted application context to deliver a malicious installation prompt that users are likely to trust and act on.
Stage four: Cobalt Strike backdoor installation. The fake plugin installation delivers a Cobalt Strike backdoor the commercially developed penetration testing framework that has become one of the most widely deployed tools in sophisticated threat actor arsenals. The specific detail that distinguishes this stage as targeted rather than opportunistic is the encryption key. Mandiant found that the Cobalt Strike payload was encrypted with a key that contained the victim organisation’s name. Generating that payload required knowing the target in advance and preparing a customised deployment specifically for that organisation. This was not a generic backdoor dropped indiscriminately across every compromised installation. It was a targeted implant prepared for a specific victim.
Who KnowledgeDeliver Serves And Why the Targeting Profile Matters
KnowledgeDeliver is built by Digital Knowledge and is widely used for enterprise and educational e-learning primarily in Japan. That geographic and sector concentration is relevant to understanding both the threat actor profile and the potential scope of impact from this campaign.
Enterprise LMS deployments in Japan serve major corporations, educational institutions, and government-adjacent organisations that use the platform for employee training, compliance education, and institutional learning programs. These environments hold employee data, training records, assessment results, and potentially sensitive corporate information about the organisations using them. They are also connected, as enterprise software typically is, to the broader IT infrastructure of the organisations running them making them potential pivot points for lateral movement into other systems.
The preparation of a victim-specific Cobalt Strike payload suggests that the attacker selected specific targets rather than exploiting the vulnerability opportunistically across every reachable installation. An attacker running a mass exploitation campaign would typically deploy a generic backdoor payload that connects back to command and control infrastructure regardless of which organisation was compromised. The victim-specific encryption key indicates pre-operation reconnaissance the attacker knew which organisation they were targeting and prepared their implant accordingly before executing the attack.
That targeting sophistication, combined with the use of Godzilla and Cobalt Strike tools associated with advanced threat actors including state-sponsored groups positions this campaign outside the typical financially motivated ransomware or credential theft operation. The objective appears to be persistent access and post-compromise capability rather than immediate financial return.
What Every KnowledgeDeliver Administrator Needs to Do
Mandiant’s advisory provides specific remediation guidance that KnowledgeDeliver administrators need to act on without waiting for a broader assessment of whether their specific installation was targeted.
Rotate the machineKey for every installation. This is the foundational remediation step the action that closes the specific attack vector that CVE-2026-5426 exploits. Rotating the machineKey generates new, unique key material for the specific installation, eliminating the hardcoded value that all installations previously shared. After rotation, the cryptographic material that attackers obtained from the hardcoded configuration file no longer signs valid requests to that installation. New machineKeys should be generated using a cryptographically secure random generator and stored securely rather than being copied from documentation or other sources that could replicate the original hardcoded value problem.
Apply the February 24, 2026 patch if it has not been applied. All KnowledgeDeliver deployments before that date are affected by the zero-day. The patch date provides the clear dividing line: any installation that was running before February 24 and has not been updated since is potentially impacted regardless of whether active exploitation has been detected.
Audit web application directory contents and JavaScript files. The attack chain documented by Mandiant includes modification of application JavaScript files to inject malicious loaders. Administrators should review JavaScript files in their KnowledgeDeliver deployments against known-good versions to identify any additions or modifications. Specifically, look for script tags or external resource loads that were not present in the original deployment, and for any files that have modification timestamps inconsistent with legitimate update activity.
Search for Godzilla/Bluebeam web shell indicators. Mandiant has published indicators of compromise associated with this campaign. Because Godzilla is deployed in memory, file system scans alone are insufficient process memory analysis and network traffic monitoring for Godzilla command and control patterns are required to detect active infections. Memory-resident web shells that have persisted across server restarts may have been written to disk at some point in the attack chain despite the initial in-memory deployment preference.
Review network logs for anomalous outbound connections. Cobalt Strike establishes command and control connectivity through techniques designed to blend with legitimate traffic. Reviewing outbound network connections from KnowledgeDeliver servers for connections to unusual external infrastructure particularly domains or IP addresses not associated with legitimate KnowledgeDeliver functionality may reveal active backdoor communication that indicates a compromised installation.
Restrict access to the LMS as an immediate containment measure if compromise is suspected. Limiting the application’s network exposure while investigation and remediation proceed reduces the risk of further attacker activity and limits the attack surface for follow-on exploitation if other vulnerabilities exist in the deployment.
The Pattern That Connects This to Sitecore, CentreStack, and the Broader Threat
Mandiant’s observation that ViewState deserialization attacks using known machineKeys have previously been used against Sitecore and CentreStack is not a footnote. It is a meaningful data point about how this attack technique is being operationalised across the enterprise software landscape.
The pattern suggests that threat actors are systematically identifying enterprise platforms that ship with shared or default cryptographic key material, extracting that material from publicly available sources or through reverse engineering, and weaponising it against the installed base of organisations running the platform. The attack does not require finding a new vulnerability in each target. It requires finding one platform with the shared key problem and then having a reliable exploitation technique ViewState deserialization that works against any installation running those keys.
The Godzilla framework’s appearance in multiple campaigns exploiting this pattern suggests either a common threat actor using consistent tooling across different targets, or that the combination of machineKey exploitation and Godzilla post-exploitation has become a standardised campaign playbook that multiple groups are following. Either interpretation indicates that the technique is established, reliable from the attacker’s perspective, and likely to continue being applied against any enterprise platform where shared cryptographic material can be identified.
For security teams responsible for enterprise software deployments, the practical implication extends beyond KnowledgeDeliver specifically. Any ASP.NET application in the environment that shipped with documentation specifying machineKey values, that uses default or example key values, or that was deployed from a common template without individual key generation, is potentially vulnerable to the same attack pattern. Auditing ASP.NET machineKey uniqueness across the enterprise application estate is not a KnowledgeDeliver-specific remediation. It is an ASP.NET security hygiene requirement that the KnowledgeDeliver campaign has made urgent rather than theoretical.
What the Victim-Specific Cobalt Strike Payload Tells Us
The detail that the Cobalt Strike payload was encrypted with a key containing the victim organisation’s name is the finding that elevates this campaign from opportunistic exploitation to targeted intrusion and the implications deserve examination beyond the immediate incident context.
Preparing a victim-specific backdoor payload requires knowing who you are going to attack before you attack them. It requires the discipline to customise your tooling for each target rather than deploying a generic implant. It reflects a threat actor operating with pre-operation intelligence about specific targets and the tradecraft sophistication to incorporate that intelligence into their attack preparation.
Those characteristics are associated with advanced persistent threat actors groups operating with the resources, patience, and organisational discipline to conduct targeted intrusion campaigns against specific high-value organisations rather than opportunistic mass exploitation campaigns against any reachable vulnerable system.
The combination of targeted payload preparation, Godzilla memory-resident web shells, Cobalt Strike command and control infrastructure, and exploitation of a zero-day in enterprise learning management software used primarily by major Japanese corporations and institutions suggests a threat actor profile consistent with state-sponsored or highly sophisticated criminal groups targeting Japanese enterprise and institutional infrastructure.
Organisations running KnowledgeDeliver that have not yet investigated their deployments for indicators of compromise should treat the victim-specific payload evidence as a signal that targeted intrusion is a realistic scenario for their installation not just opportunistic exploitation that would have been satisfied with a generic backdoor deployment.
The investigation scope appropriate for that scenario is different from the investigation scope appropriate for a mass exploitation campaign. Targeted intrusion involves pre-operation reconnaissance, customised tooling, and potentially extended persistence objectives that mass exploitation does not. Finding and removing the Cobalt Strike implant is necessary. Confirming that the attacker did not establish additional persistence mechanisms, did not move laterally to other systems, and did not exfiltrate data during the compromise window is equally necessary and requires the kind of thorough incident response investigation that the victim-specific payload evidence warrants.
Research and Intelligence Sources: Google Cloud
To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com
🔒 Login or Register to continue reading




