KnowledgeDeliver Shared One ASP.NET machineKey Across Customers (CVE-2026-5426)

1 One copied secret converted customer isolation into shared trust

CVE-2026-5426 is a critical KnowledgeDeliver deployment failure in which an unauthenticated holder of the reused ASP.NET machine key could make one customer installation accept malicious ViewState as locally authorized and proceed to operating-system-level code execution.

1.1 The incident exposed the boundary failure before the advisory named it

In late 2025, Mandiant responded to a compromised web server running Digital Knowledge’s KnowledgeDeliver learning-management system. The initial execution did not remain a narrow server-side event. The unknown actor placed the BLUEBEAM, or Godzilla, in-memory web shell inside the IIS worker process, changed web-directory permissions, altered application JavaScript, and used the trusted learning portal to present visitors with a false security prompt. Mandiant traced the unauthenticated entry back to identical ASP.NET machine keys distributed in standardized deployment configuration.

The public incident report and MNDT-2026-0009 establish the decisive facts. KnowledgeDeliver installations deployed before February 24, 2026 relied on a vendor-provided standardized web.config containing hard-coded validationKey and decryptionKey values. The same values appeared in independent customer environments. An actor who obtained the pair from one deployment could therefore target another reachable installation that still used the pair, craft protected ViewState for its Web Forms context, and cause the server to deserialize the attacker-controlled state.

This is not simply “a weak key” or “ViewState enabled.” The defect is reuse of a credential whose intended scope is a single application security boundary. Cryptographic strength does not help when the same strong value is deliberately copied into unrelated customers: possession remains authorization. The exposure also persists after an application binary update if the effective inherited configuration still contains the old pair. Resolution begins with revoking the shared credential, not merely changing a version label or blocking one observed payload.

Mandiant reported the issue to Digital Knowledge on January 19, 2026. The vendor implemented an updated deployment procedure on February 24; Mandiant and the vendor discussed disclosure on March 18, and MNDT-2026-0009 was published on April 16. The later incident report, dated May 25, supplied the exploitation, BLUEBEAM, file-tampering, learner-lure, and hunting detail. Those dates separate a process change for new deployments from the continuing duty to inspect and rotate secrets in installations created earlier.

The timeline also explains why there is no conventional “upgrade to fixed version X” answer in the public record. The affected object is deployment state, not a named binary range: the CVE record describes KnowledgeDeliver deployments before the procedure change, and the advisory makes unchanged pre-shared keys the deciding condition. A replacement package can carry a safer template for future installs while leaving an existing effective configuration untouched. Asset owners therefore need a configuration attestation for each instance, not a purchase-order or patch-console screenshot.

The CVE and advisory also describe weakness from complementary angles. MNDT-2026-0009 lists deserialization of untrusted data and hard-coded credentials; the CVE record describes the pre-February 24 hard-coded ASP.NET/IIS key and malicious ViewState outcome. The credential defect explains how untrusted bytes acquire authorization, while the deserialization defect explains why accepting those bytes can become execution. Treating either label alone as the entire cause leads to an incomplete fix: serializer filtering cannot revoke a copied signer, and key rotation does not erase post-exploitation.

The public report does not say how the actor first obtained the shared values. Cross-customer reuse makes several routes conceivable—a legitimately administered installation, a readable configuration backup, or prior server access—but none is established for this incident. The defensible statement begins after possession: because independent deployments used the same explicit material, compromise of confidentiality at any one copy could export authorization to the others. Investigators should trace local reads and handling without inventing a key-acquisition story that Mandiant did not publish.

The Mandiant advisory assigns CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. Its High attack-complexity component matters: the key is essential but a usable request also has to fit the receiving application and page context. Its network, no-privilege, and no-user-interaction components capture the entry condition once that context is known. The incident then shows why the scope change is operationally real: code running in an IIS worker was used to alter content later delivered to a different population of learner endpoints.

1.2 machineKey was the signer, not a product serial number

ASP.NET Web Forms sends page and control state to the browser and receives it back on a later postback. Because the client can modify that hidden field, the server uses machine-key material to authenticate it and, when configured, to protect its confidentiality. The resulting decision is local and powerful: state with an acceptable message-authentication code is treated as having been produced by a holder of the application’s validation secret. The framework does not know whether deployment automation copied that secret beyond the intended boundary.

A web farm illustrates the legitimate reason to configure explicit keys. A browser may receive a page from node A and post it back to node B. Microsoft’s troubleshooting guidance therefore requires farm members serving the same logical application to use compatible fixed validation material; Microsoft’s machine-key response guidance likewise says a replacement must be rolled to every server in that farm. Sharing within that one application preserves availability. Sharing the same pair with an unrelated customer turns the interoperability feature into cross-customer trust.

The boundary should consequently be drawn around a logical application, not around every process and not around an entire vendor ecosystem. Nodes that must accept one another’s state share one newly generated pair. A production customer, another customer, a test environment, a disaster-recovery copy that is not intended to accept production state, and a separately administered tenant require independent decisions. Operators must document the few intentional equivalence groups rather than assume that “same product” is a valid reason for identical secrets.

The pair also has two distinct security jobs. Validation material lets the application decide whether protected state is authentic; decryption material lets it recover confidential state where encryption is active. Reuse can therefore export both signing authority and the ability to open protected data, subject to context and format. Rotation planning must consider every System.Web feature in that installation that consumes machine-key material, not only the one hidden field named in the CVE, and testing must verify the resulting authentication and state lifecycle without assuming all ordinary server-side session data uses the pair.

The affected application source, deployment package, shared values, receiving page, and functional exploit graph are not public. SOSEC therefore separates three layers throughout this report. Product and incident facts come from Mandiant’s response and pinned advisory. Framework behavior comes from Microsoft documentation and the .NET Framework Reference Source fixed at commit ec9fa9ae770d522a5b5f0607898044b7478574a3. Advice about inventory, evidence joins, rollout, and acceptance tests is repository-derived defensive analysis; it does not claim knowledge of closed KnowledgeDeliver internals.

That evidence boundary prevents two common errors. First, the public facts do not justify naming a particular KnowledgeDeliver page, gadget chain, framework compatibility mode, or custom handler. Second, the absence of those exploit details does not weaken the remediation: the advisory directly identifies the reused credential and says that a unique, cryptographically strong machine key is required for each KnowledgeDeliver instance. A defender can prove that boundary without recreating the malicious object graph or exposing the original secret.

2 Exposure is a configuration state, not a simple version range

The affected set is determined by the key that actually takes effect, the application context around it, and whether an adversary can reach a receiving page, so a deployment date is a starting filter rather than a final verdict.

2.1 The public advisory defines two necessary conditions

MNDT-2026-0009 names two impacted-configuration conditions: the organization has not changed the default pre-shared ASP.NET machine key, and the application is accessible to the threat actor, described in the advisory as open to the internet. The incident report narrows the historical source of that condition to standardized web.config used for deployments before February 24, 2026. These statements support a date-bounded search, but they do not say every older installation remains vulnerable or every newer installation is automatically clean.

An older customer may already have generated unique values, moved the application behind effective access controls, or replaced the configuration during a later migration. Conversely, a copied backup, standby server, cloned test environment, or redeployed image can reintroduce the old pair after the vendor changed its procedure. The defensible classification uses effective configuration on every live and recoverable node, configuration history, deployment provenance, and reachable entry points. Purchase records and displayed product versions cannot answer those questions by themselves.

Digital Knowledge’s product page describes KnowledgeDeliver as an integrated platform for creating learning material, delivering courses, and administering learners, with ASP, on-premises, and cloud deployment options. That breadth is relevant to inventory, not proof of exposure. A hosted environment, customer-managed server, or cloud image may have different ownership, ingress, and secret-delivery paths. The team that can see the application version may not control the inherited ASP.NET configuration, while a hosting provider may operate several logical boundaries on shared infrastructure.

Reachability is time-dependent. A maintenance bypass, temporary vendor rule, direct origin address, alternate port, or failover VIP may expose a path only during part of the key-valid interval. Review firewall and proxy configuration history, certificate transparency and DNS history where appropriate, load-balancer changes, and support access records rather than testing only today’s route. For each interval, record what was reachable and from which network position, then state the evidence coverage and any unknown span. A route denied today neither erases a historical opportunity nor replaces examination of the workers and effective configuration that accepted requests at the time.

“Accessible to the threat actor” is broader than a public DNS record. A reverse proxy can publish only selected routes; a VPN or identity-aware gateway can constrain the entry; a compromised partner host can reach an internal application; and an old disaster-recovery URL can remain reachable even when the primary is restricted. Inventory must record the path from potential client to application, including CDN, WAF, proxy, load balancer, alternate host names, management networks, and any stale publishing rule, then test the policy from an appropriate external vantage point.

Access restriction is useful containment and appears in Mandiant’s mitigation advice, but it does not revoke the credential. A copied key remains useful to anyone who later gains a network path, and it may protect more System.Web data than the single request currently under investigation. Organizations should therefore restrict exposure while preparing a coordinated rotation, not declare the instance fixed because a firewall rule reduced immediate reachability.

2.2 Effective configuration can differ from the file beside the application

ASP.NET configuration is hierarchical. A visible web.config in the application directory can inherit a machineKey section from a parent application or machine-level configuration, while deployment tooling may transform the file at release time. A correct inventory records the effective system.web/machineKey after inheritance and transformation, the physical source that supplied it, and the configuration revision delivered to each node. Merely searching one repository or opening one file can miss the value actually consumed by the worker process.

The two attributes must be treated as one credential set but assessed separately. The validation key underpins the authenticity decision; the decryption key supports confidentiality when ViewState encryption is used and participates in the modern protected-data format. A site with one old attribute and one new attribute is not a completed rotation. A comparison system should fingerprint the decoded values independently and as a pair, so it detects full reuse, partial reuse, formatting differences, and a rollout that changed only one side.

Raw secrets should never be collected into a spreadsheet, support ticket, chat transcript, or central log. A safer comparison runs inside an approved secret-handling boundary, canonicalizes the hex representation, and emits an organization-keyed digest plus an instance identifier, key role, source layer, and secret version. The comparison key for that digest is itself protected. This method lets investigators find equivalence groups without constructing a new database from which the vulnerable material could be recovered.

Every farm node, passive node, blue-green slot, scale image, backup image, and disaster-recovery template belongs in the review because an old member can undo a correct change. The node may not currently receive traffic, yet an autoscaling action or failover can return it with stale keys. Recovery media also matters: restoring a pre-rotation image should fail a deployment guard until the secret is injected again. The acceptance record needs both the active population and the mechanisms capable of creating future members.

After collecting a configuration value, verify that the running application actually reloaded the intended revision. ASP.NET configuration changes can recycle the application domain, but deployment races, locked files, transformations, container layers, or a node excluded from the job can leave observed state different from desired state. Capture the effective value after restart, tie it to the new worker lifetime, and exercise a protected page on that node. Desired-state dashboards are useful evidence of delivery; runtime fingerprints and behavior are evidence of activation.

Configuration encryption changes storage exposure but not cryptographic scope. Microsoft Protected Configuration can prevent the machine-key section from sitting as readable plaintext on disk, and access controls can limit who may decrypt it, but encrypting the same shared value at three customers still leaves one shared signer after each application loads it. Protection at rest, uniqueness across boundaries, secure delivery, and auditable access are separate controls; all four are required for a durable repair.

2.3 A known key still has to match the receiving Web Forms context

The machine-key pair is necessary for this vulnerability, but it is not a universal master key for every ASP.NET application. The receiving request must reach a page that processes client-side ViewState, and the protected value must match the algorithms, framework behavior, application and page context, encryption state, and other modifiers used by that page. The modern Reference Source path incorporates a primary purpose plus the page template source directory, page type name, and an optional ViewStateUserKey into subkey derivation.

Legacy compatibility paths bind state differently, including a page-derived MAC modifier and optional user key. The public KnowledgeDeliver material does not state which compatibility mode or exact .NET Framework configuration ran on the victim. This report therefore traces both the normal hidden-field lifecycle and the modern cryptographic implementation without asserting that the observed payload used one unpublished branch. Local assessment must record the installed framework, application pool settings, effective machineKey algorithms and compatibility mode, and representative page behavior.

ViewStateUserKey, when an application sets it to an unpredictable per-user value early enough in the page lifecycle, adds context that can impede transferring one state value across users. It is not a substitute for a unique secret: implementation can vary by page, the value may be absent or predictable, and the advisory confirms unauthenticated exploitation of the affected product. Defenders should measure it as one prerequisite rather than assume its presence from general ASP.NET guidance or treat it as a reason to postpone rotation.

The endpoint is likewise part of the proof. A scanner that finds __VIEWSTATE only establishes ordinary Web Forms behavior. A large Base64 field, an Event 1316 record, or a 500 response can arise from normal expiration, a farm-key mismatch, truncation, proxy rewriting, or hostile input. Exposure assessment should use benign requests and configuration evidence, while compromise assessment joins the receiving URI and event reason to process, assembly, file, and network effects. A functional malicious payload is neither necessary nor appropriate for routine validation.

Safe validation stops short of constructing hostile state. Browse representative pages through the supported user journey, record whether ViewState is present and chunked, and confirm which nodes receive the resulting benign postbacks. Review effective configuration and source available to the owner for user binding and encryption settings. These observations establish the receiving surface and test plan. They do not require guessing an undisclosed URL, extracting a gadget list, or sending abnormal serialized objects to production.

The resulting scope statement has three levels. “Historical candidate” means deployment provenance predates February 24. “Cryptographically exposed” means the effective key fingerprints match the known reused group and a relevant application path is reachable. “Compromised” requires evidence that hostile state crossed validation and produced execution or post-exploitation effects. Keeping those labels separate prevents both false reassurance from a clean disk scan and needless incident declarations from a single malformed postback.

3 The request crosses collection, purpose binding, cryptography, and object interpretation

The public System.Web source shows where a copied deployment secret becomes a trusted object stream, while the undisclosed KnowledgeDeliver page and gadget remain outside the evidence.

3.1 Page state is reconstructed before ordinary postback processing

SOSEC fixed the .NET Framework Reference Source at commit ec9fa9ae770d522a5b5f0607898044b7478574a3 so function names and behavior do not drift with a branch. In Page.ProcessRequestMain(), an actual postback enters LoadAllState() after initialization and before ProcessPostData() and page-load events. LoadAllState() asks LoadPageStateFromPersistenceMedium() for saved state; that method obtains the configured PageStatePersister and invokes its Load().

The default client-side implementation is HiddenFieldPageStatePersister. Its Load() reads Page.RequestViewStateString, then calls Util.DeserializeWithAssert() with the page’s state formatter and the primary purpose WebForms.HiddenFieldPageStatePersister.ClientState. The result is expected to be a Pair containing ViewState and control state. An application can override persistence behavior, so this is the documented default framework route rather than a claim about unpublished KnowledgeDeliver customization.

RequestViewStateString explains how an HTTP field becomes one serialized value. If chunking is disabled or __VIEWSTATEFIELDCOUNT is absent, it returns __VIEWSTATE. If a count is present, it converts the count, rejects a negative value, then concatenates __VIEWSTATE, __VIEWSTATE1, __VIEWSTATE2, and later chunks in order. A missing declared chunk raises an error. Detection and evidence collection must therefore retain the field count and every chunk, not just the first field.

Chunk reconstruction is not cryptographic acceptance. It merely produces the text handed to the formatter. A proxy size limit, truncation, duplicate parameter handling, form parser difference, or missing chunk can fail before any MAC decision. That distinction matters when interpreting a 500 response or an “invalid viewstate” symptom: request capture, framework event detail, and source behavior must establish the stage. Treating every parser error as a wrong-key exploit attempt erodes the signal needed for the real sequence.

The source also preserves an important extension point: LoadPageStateFromPersistenceMedium() is virtual and the page can select a different persister. A product could store state server-side or wrap the default behavior. Nothing public shows that the affected KnowledgeDeliver page did so, and Mandiant explicitly identifies malicious __VIEWSTATE. The review therefore uses the default hidden-field lifecycle as the supported explanation while requiring runtime evidence before applying every default-source detail to a specific customer.

Ordinary IIS logging usually records time, method, URI, status, duration, and User-Agent but not the POST body containing the state. If a WAF or reverse proxy lawfully retains request bodies, the team should preserve the complete parameter set under restricted evidence handling and record any normalization it performs. Without body evidence, investigators can still join the IIS request to Event 1316, worker PID, application pool, and endpoint telemetry; they should state that the exact submitted bytes were unavailable rather than reconstruct them from assumptions.

3.2 Explicit configuration remains the master key at the root

The page constructs an ObjectStateFormatter associated with itself. In the newer cryptographic path, the formatter appends specific purposes to the persister’s primary purpose: the uppercase page TemplateSourceDirectory, the uppercase page type name, and ViewStateUserKey when present. AspNetCryptoServiceProvider.GetCryptoService() then obtains services whose encryption and validation keys are derived for that purpose. The purpose limits transferability, but derivation begins from the application’s configured master material.

MachineKeyMasterKeyProvider.GenerateCryptographicKey() contains the branch that makes configuration reuse decisive. It parses the configured attribute as hex; if valid nonempty bytes result, the function returns a CryptographicKey built from those bytes verbatim. If the attribute instead specifies AutoGenerate, the provider takes a segment of runtime auto-generated material and can derive application-specific keys using IsolateApps and IsolateByAppId. The source therefore supports a narrow conclusion: copied explicit values remain copied at the master-key layer.

Purpose derivation narrows where one master can authorize data but does not make customers independent. The same root plus the same purpose inputs produces the same application-purpose keys. Standardized virtual paths and page types increase the chance of that alignment, while a different path or user key may cause rejection. A true tenant boundary should not rely on incidental differences in those strings: changing a route can erase the difference, and any other System.Web purpose rooted in the same copied master remains part of the credential’s exposure surface.

Auto-generated material has its own operational constraints. Microsoft describes it as stored under the relevant machine or application-pool identity, and the Reference Source derives optional application isolation from runtime identifiers. Moving an application, changing an identity profile, or restoring a machine can therefore change availability even while improving uniqueness. Operators should not switch storage modes during an emergency without testing that topology; the immediate invariant is simpler—no unrelated boundary may retain the disclosed explicit pair.

It would be incorrect to turn that source observation into a universal recommendation to delete machineKey. Microsoft explains that a single-server application can revert to auto-generated values, but a web farm needs compatible fixed values across its members so state issued by one node works on another. The correct KnowledgeDeliver action follows the advisory: generate a unique strong pair for each instance boundary, then use the same pair on all nodes that intentionally serve that logical instance. Topology determines whether explicit or auto-generated storage is appropriate.

Algorithms and compatibility mode also belong in the inventory. The attributes select validation and decryption behavior, and framework versions include both newer purpose-derived providers and legacy protection paths. A rotation that changes key bytes but silently changes algorithms can cause an outage or make an acceptance test exercise a different route. Record the old effective settings, choose supported new settings with the vendor and platform owner, test in a representative non-production boundary, and deploy the pair and algorithm configuration as one controlled change.

Machine-key impact extends beyond one serializer because System.Web uses the material as a general protection root for features selected by application configuration. That is why the rollout test includes login, representative postbacks, and any locally identified protected-data consumers, and why a support symptom after rotation should be traced to a feature rather than “fixed” by restoring the old value. The inventory should derive that consumer list from the application and framework settings; the closed product source does not permit this report to declare an exhaustive KnowledgeDeliver-specific list.

Key equality is a statement about authorization, not proof that ciphertext from customer A can be copied unchanged into customer B. Purpose-derived keys, page names, virtual paths, optional user binding, and serialization expectations can differ. The vulnerability arises because standardized deployments make enough of that context repeatable and a shared-key holder can construct state for the target context. The defensive conclusion is still to eliminate cross-customer root-key equivalence, while the evidentiary conclusion remains limited to what the public advisory and source actually show.

3.3 Authentication precedes decryption in the modern protected-data path

ObjectStateFormatter.Deserialize(string, Purpose) first rejects an empty string and Base64-decodes the input. When the default newer provider is active and the page requires encryption or a ViewState MAC, it appends the page-specific purposes, gets a cryptographic service, and calls Unprotect(). Only the returned clear bytes become the input to stream deserialization. If the application forces legacy cryptography, different functions perform decrypt-and-verify or MAC decoding; the same core security question remains whether the supplied state is accepted under the application’s secret and context.

NetFXCryptoService.Unprotect() documents its expected envelope as an initialization vector, encrypted payload, and signature over the first two components. It checks that all components can fit, calculates the validation signature, and compares it with the supplied signature. A mismatch returns failure before decryption. After a match, it extracts the IV, configures the symmetric algorithm with the derived encryption key, decrypts the payload, and returns clear data. This order is why the validation key is an authorization boundary rather than a decorative checksum.

The legacy branch reinforces the need to record runtime conditions. When encrypted ViewState is present, legacy code calls the machine-key decrypt-or-verify routine with a page MAC modifier; when only MAC protection is used, it decodes and validates before the formatter consumes the remaining bytes. The implementation details and envelope differ from NetFXCryptoService, but both reject state that lacks acceptable key-derived evidence. The report uses the newer routine to show an explicit authenticate-then-decrypt sequence, not to claim Mandiant observed that exact class on the victim.

Possession of the shared pair changes the meaning of that comparison. Without the pair, attacker-chosen bytes normally fail the outer integrity decision. With the pair and matching purpose, the actor can produce the same cryptographic evidence the framework expects from the application. The service correctly concludes that the payload came from an authorized key holder; deployment has made that conclusion false at the customer boundary. No cryptographic primitive has to be broken, and the repair is not a new filter for one serialized class.

Encryption does not neutralize a signer who also possesses the decryption-side material. Its purpose is to hide state from parties without the key, while the MAC prevents unauthorized modification. Because the standardized configuration exposed both values across independent deployments, an actor with the pair could prepare an envelope that the target can authenticate and open. Disabling ViewState encryption would not restore authenticity, and enabling it while preserving the shared pair would not revoke the actor. Unique protected credentials are the controlling change.

Error handling at this stage is diagnostically useful but not sufficient on its own. A signature failure, minimum-length failure, malformed Base64 value, or decryption exception can all surface as state errors with different details. Investigators should retain the full ASP.NET event message and inner reason where available, correlate the request time, and avoid reducing the record to “Event 1316 occurred.” The later formatter stage can also reject authenticated bytes, creating the higher-priority but still non-conclusive “Viewstate was invalid” case described by Mandiant.

3.4 Cryptographic acceptance hands authorized bytes to a rich formatter

After protection is removed, ObjectStateFormatter checks its serialized-stream header and format version, creates a reader, and enters DeserializeValue(). The formatter recognizes compact tokens for common Web Forms state such as strings, integers, arrays, lists, pairs, triplets, dictionaries, indexed strings, and types. This breadth exists to reconstruct control state efficiently. The security assumption is that an untrusted browser cannot authorize arbitrary token streams because it lacks the validation secret.

The pinned source also includes Token_BinarySerialized. When that token is encountered, the formatter reads a length and nested byte buffer, creates a BinaryFormatter, and calls Deserialize() on the nested stream. That is a concrete source location where an authenticated state format can transition into general object deserialization. It explains why signer compromise is dangerous; it does not prove that the unpublished KnowledgeDeliver exploit used this exact token, gadget, or object graph.

A formatter exception is therefore evidence about progress, not a binary safety verdict. It can occur before any dangerous object is created, during type resolution, after a constructor or converter has run, or after a nested deserializer has produced partial effects. That is why Mandiant’s wording says execution may or may not have occurred. Process and host telemetry must resolve the consequence; an HTTP error page cannot roll the application back to the state that existed before deserialization began.

Mandiant’s advisory supplies the product-specific result that the malicious ViewState path can lead to OS-level remote code execution, and the incident response observed actual unauthenticated execution. The Reference Source supplies a public framework mechanism connecting hidden-field input, cryptographic acceptance, and object interpretation. Combining those two layers is justified. Naming an internal KnowledgeDeliver handler, a specific gadget assembly, or a payload construction command would be speculation and would unnecessarily publish operational exploit detail.

The same separation guides testing. A defensive acceptance test can submit a benign state produced before rotation and confirm rejection, then use new legitimate pages to confirm farm interoperability. It need not invoke a dangerous formatter token. A security team may separately test controls in an isolated authorized laboratory, but production closure should not depend on reproducing remote code execution. The key property to prove is that the old signer no longer authorizes any protected application state.

The mechanism also explains why blocking one User-Agent, payload hash, or serialized marker is incomplete. A shared signer can authorize different state encodings that the target accepts, and post-exploitation can change independently. Network signatures are useful for known activity, but the primary prevention is boundary-unique secret material; the primary compromise decision is a joined evidence chain after the state crossed validation. Those controls address the cause and the observed consequence rather than one sample.

4 Evidence must follow the transition from rejected state to server and learner impact

The investigation becomes reliable when it distinguishes a failed outer check, an authenticated deserialization attempt, execution inside w3wp.exe, persistence or file change, and delivery to visiting learners.

4.1 Event 1316 has two materially different meanings

Mandiant directs defenders to Windows Application Event ID 1316 from a source such as ASP.NET 4.0.30319.0, commonly carrying event code 4009. Microsoft defines 4009 as AuditInvalidViewStateFailure, the major health-monitoring code for ViewState verification failure. The event identifier is therefore a family label. Its reason text and detail distinguish where processing failed, and the full message may retain request state useful for reconstruction.

“The viewstate supplied failed integrity check” means the submitted value did not authenticate under the effective key and context. It can represent an attacker using the wrong key, ordinary corruption, a truncated field, a farm node with inconsistent keys, or a stale page after rotation. Processing stops before the authenticated formatter path. The event is a useful hunt lead and deployment-health signal, but it neither confirms possession of the shared credential nor proves code execution.

“Viewstate was invalid” carries more weight in the Mandiant case. Their report says integrity checks passed, deserialization was attempted, and the payload may or may not have executed. The formatter can reject a malformed stream after authentication, an object graph can throw after partial effects, or a requested type may be unavailable. The correct label is “integrity-passing deserialization attempt,” not automatically “successful exploit.” Adjacent process and file evidence determines what happened next.

Health-monitoring configuration affects visibility. ASP.NET can route web events through configured providers, and local Windows Application logs can roll over or be filtered before central collection. Verify that the relevant provider and channel were active on every node, whether forwarded events retained the full message, and whether application restarts changed source names. A node with no 1316 records but a disabled or lossy collection path has an evidence gap; a node with complete event retention and no joined activity offers a materially stronger negative observation.

Mandiant used the server’s machine keys to decrypt payload strings recorded inside event-log messages and recovered content related to BLUEBEAM. That finding makes the complete message a sensitive evidentiary object: it may contain protected state, executable content, credential material, or indicators unavailable elsewhere. Export the original event with timestamps, provider metadata, record ID, host, and message into access-controlled evidence storage; do not paste the state into ordinary incident tickets or send it to unapproved decoding services.

The concatenated browser User-Agent strings in Mandiant’s report can connect requests to the observed activity, but the pattern is neither a cryptographic prerequisite nor a stable actor identity. Preserve the exact original header, proxy-added values, and source interpretation, then compare it with the receiving event and worker behavior. A match without a validation-passing event remains a lead; a different header does not clear a request whose state passed integrity. This hierarchy keeps a convenient network string from outweighing the framework’s own processing evidence.

4.2 BLUEBEAM shifts the search from web-root files to worker memory

After initial code execution, the observed actor deployed BLUEBEAM, also known as Godzilla, as a .NET in-memory web shell within w3wp.exe. It received encrypted data in HTTP POST bodies and enabled further command or payload execution. That residence model defeats a narrow file-only check: a web root can contain no new shell page while the compromised application pool continues to host malicious assemblies and command capability in memory.

Volatile evidence should therefore be collected before an emergency recycle when circumstances allow. Relevant material includes the worker PID and start time, loaded .NET assemblies and modules, executable memory regions, active connections, command lines, handles, app-domain information, and parent-child process relationships. Collection must follow the organization’s forensic procedure because arbitrary inspection can destabilize production or alter evidence. If immediate safety requires termination, record the reason, exact time, and lost evidence before acting.

Mandiant’s hunting guidance names unusual children of w3wp.exe and observed commands including cmd.exe /c, whoami, and powershell.exe. Those strings are not unique to this actor; administration and application features can produce some of them. Confidence rises when an integrity-passing ViewState event on the same host and application pool is followed closely by a new assembly, a rare child process, suspicious command content, outbound traffic, or a change the web application identity does not ordinarily make.

Scope follows the worker’s security context. Record the application-pool account, assigned Windows privileges, writable directories, database connection permissions, accessible network shares, outbound policy, and secrets the process could read. Those capabilities define the maximum plausible reach of arbitrary code, but they are not themselves proof the actor used every permission. Join access logs, database audits, credential-use events, and network telemetry to the execution window before converting possible reach into a confirmed confidentiality or integrity statement.

Application-pool recycling complicates correlation because several w3wp.exe lifetimes can serve the same site in one hour, and an overlapped recycle can briefly keep old and new workers alive together. Preserve process start and stop events, PID-to-pool mapping, configuration revision, and listener handoff. Associate an Event 1316 with the worker that handled it rather than every process sharing the executable name. Memory from the wrong PID can be clean while the relevant worker has already exited.

The public IOC LoadLibrary.dll with SHA-256 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2 is a strong match for the documented BLUEBEAM-related sample, but absence is not clearance. The shell can operate in memory, names can change, and later stages can differ. Hash matching should be paired with assembly metadata, memory scans, process ancestry, HTTP behavior, and known-good comparison rather than used as the sole close condition.

The actor also used icacls to grant Everyone full access to the web application directory. Investigators should reconstruct the prior and current ACLs, the principal and process that changed them, and the files written during the permissive interval. Restoring a clean JavaScript file without repairing inherited permissions leaves the server vulnerable to later modification; restoring permissions without identifying what executed under them can leave persistence or stolen credentials unaddressed.

4.3 The trusted learning portal became a delivery channel to users

Mandiant observed the actor modify an application JavaScript file. The injected logic displayed a false security alert asking visitors to install a “security authentication plugin” and silently loaded a remote malicious script. Users who followed the lure received a fake installer that led to a Cobalt Strike BEACON. The payload encryption key incorporated the victim organization’s name, evidence of preparation for that organization rather than a generic, untargeted download chain.

This sequence expands the impact boundary from the IIS host to every browser that received the modified asset during its serving interval. The server was a trusted origin for learning content, so users did not need to browse to an unrelated malicious site. Investigation must identify the first and last known bad file versions, pages that referenced the script, CDN or proxy caches, response hashes and ETags, sessions that loaded those pages, remote-script requests, installer downloads, and endpoint executions.

Caches can lengthen or fragment that window. A corrected origin file does not prove that every CDN edge, reverse proxy, browser cache, or service worker stopped serving the changed bytes at the same moment. Purge and verify each cache layer, preserve cache logs and object versions, and test the affected routes from representative regions or networks. The learner ledger should use the content version actually returned to a session, not assume that all requests before restoration were malicious or all requests after the origin repair were clean.

Remote-resource evidence can refine the cohorts even when the modified response body is gone. DNS resolver logs, secure-web-gateway records, TLS metadata, browser history, download provenance, file hashes, and EDR process trees may show whether a device only resolved the actor domain, fetched script content, saved an installer, or executed it. Each transition needs its own timestamp and device identity. A shared NAT address or user account is a join candidate, not enough by itself to assign endpoint infection.

Different user groups require different actions. A visitor whose browser fetched only a clean page needs no malware response. A session that received the modified JavaScript but was blocked from the remote domain needs evidence preservation and targeted review. A machine that fetched the remote script or installer requires endpoint isolation and investigation, while execution of the fake installer or BEACON invokes full endpoint and identity response. Notifications should state the observed window and action instead of issuing one vague password-reset message to everyone.

The public reporting supports high confidentiality and integrity concern and an OS-level execution path, but it does not publish a complete database-access or credential-theft ledger for every affected installation. Local teams must determine what the application-pool identity, service accounts, file ACLs, database roles, and network position could reach, then compare that capability with actual telemetry. Worst-case access guides containment; observed evidence guides confirmed-impact statements. The two should not be collapsed into an unsupported claim.

No public source attributes the late-2025 KnowledgeDeliver operation to a named threat group. Godzilla, unusual User-Agents, ViewState technique, and victim-tailored Cobalt Strike material support campaign-oriented hunting, but tools are shared and can be imitated. Attribution requires independent infrastructure, development, targeting, and operational evidence. Response does not need an actor name: revoke the trust root, preserve the chain, eradicate persistence, and handle exposed learners on the evidence already available.

5 Detection works as an evidence ladder, not a list of magic strings

Teams need one workflow that inventories the credential boundary, preserves the vulnerable interval, and escalates findings according to the deepest confirmed stage.

5.1 Build the exposure and evidence ledger before changing state

Start with every production, standby, disaster-recovery, test, migration, and externally published KnowledgeDeliver instance whose lineage may predate February 24. For each, record owner, environment, logical application boundary, farm members, virtual path, app-pool identity, framework and compatibility configuration, ingress paths, deployment source, effective key source, protected fingerprints, last change, and available log retention. This ledger connects configuration exposure to evidence custody and prevents one forgotten node or clone from reintroducing the old signer.

Preserve the longest defensible exploitation window before rotation and rebuild truncate evidence. At minimum it should include locally retained data back through the late-2025 incident period and continue through containment. Collect complete Event 1316/4009 records, IIS and reverse-proxy logs, WAF alerts or bodies where lawfully retained, app-pool recycle and crash history, EDR process events, .NET assembly or module telemetry, DNS and network egress, file-integrity records, deployment logs, backups, and authentication or database audit evidence relevant to the app-pool’s reach.

Normalize all sources to UTC while retaining original timestamps and zones. Build joins on host, application pool, worker PID and lifetime, client address after trusted-proxy interpretation, URI, request or correlation ID, User-Agent, session where legally appropriate, and file path. NAT, load balancers, pool recycling, and clock skew can otherwise connect one request to the wrong worker. Record the transformation rules so another analyst can reproduce why two artifacts were treated as one sequence.

Request bodies, memory, application databases, and learner records can contain personal or regulated data. Before broad collection, document incident authority, purpose, access group, storage region, retention, and deletion or legal-hold requirements. Minimize routine analyst views and separate identity lookup from technical correlation when possible. Privacy control does not mean discarding decisive evidence; it means collecting the necessary object with accountable custody instead of copying it across unrestricted workspaces. If a field must be unsealed or joined to a real identity, record who performed that step, when, and for what purpose; exports and derived copies inherit the same restrictions.

Establish known-good baselines from signed releases, deployment artifacts, and backups whose time and custody precede the event, not from the currently running server. Compare .js, .aspx, .config, binaries, scheduled tasks, services, startup paths, IIS modules, handler mappings, and ACLs. For in-memory risk, a clean file comparison is one component only; process-memory and assembly evidence, or a rebuild from trusted media, carries the conclusion beyond the web root.

5.2 Escalate on sequences that cross successive trust stages

The lowest rung is exposure without activity: the protected fingerprint confirms cross-instance reuse, but no relevant requests or events are found in retained data. Rotate immediately, document the evidence gap, and keep a hunt open for the period the key was valid. Absence of events is meaningful only if logging was enabled, the full interval was retained, and collection covered every node; otherwise it is an unknown, not a negative finding.

The next rung is rejected input: integrity-failure events, malformed chunks, or suspicious POSTs that do not authenticate. Volume, source distribution, repeated target URIs, concatenated browser User-Agent strings described by Mandiant, and attempts across multiple nodes can raise priority, but the outer boundary held. After rotation, a temporary rise in wrong-key events may be expected as browsers submit old pages; classify it by time, reason, and client behavior rather than suppressing all 4009 records.

An integrity-passing “Viewstate was invalid” event is the first high-confidence sign that a holder of acceptable context and key material reached deserialization. Triage it immediately against the same worker lifetime. Look for rare assembly loads, w3wp.exe children, command interpreters, identity discovery, network connections, permission changes, application-file writes, and crashes. If body evidence exists, preserve and analyze it only in an isolated authorized environment; the production team does not need to execute it to escalate.

Execution evidence moves the case to confirmed server compromise. A matching BLUEBEAM artifact, suspicious in-memory assembly, child command, or unauthorized modification tied to the event justifies containment, volatile collection, credential scoping, and rebuild planning. A changed learner-facing asset adds a downstream branch: derive its serving interval, affected requests, remote-loader traffic, downloads, and endpoint results. The case record should show which stage is confirmed for each server and user, rather than assigning one status to the entire organization.

Closure uses the inverse ladder. New cross-customer key equivalence must be absent; old state must fail; new state must work across intended farm peers; no stale node may return; the rebuilt server must match trusted release and ACL baselines; suspicious process and network chains must cease; and every learner cohort must receive the action appropriate to its observed stage. A single green vulnerability scan cannot substitute for these independent proofs.

6 Rotation revokes the signer; recovery removes what the signer enabled

Credential repair and compromise recovery are connected but different workstreams, and neither is complete merely because a new web.config exists.

6.1 Contain reachability and rotate one logical farm at a time

Begin with reversible containment suited to business needs: restrict the LMS to known organizational address ranges or an authenticated gateway, remove stale publishing rules, and block confirmed malicious infrastructure while preserving logs. If evidence indicates active compromise, isolate the affected server or farm according to the incident plan. Do not recycle a suspected w3wp.exe before volatile collection unless continued operation presents greater harm; document that risk decision and the exact containment time.

Generate new validation and decryption values locally through supported IIS or cryptographic tooling, never through an online generator and never by copying documentation. Mandiant requires a unique, cryptographically strong machine key for each KnowledgeDeliver instance. Microsoft provides IIS Manager and PowerShell generation approaches and explains the topology choice: one standalone application may use protected auto-generated material, while every node of one web farm needs the same newly generated explicit pair. Confirm the chosen model with the vendor and platform owner.

Treat the farm rollout as a coordinated application change. Inventory every node and traffic path, back up configuration without exporting raw secrets to the change ticket, stage the new secret through a protected channel, drain traffic or use a maintenance window, apply the pair and algorithm settings to all members, and recycle the application pools in a controlled order. A mixed-key farm will reject state issued by its peers, so traffic must not alternate between old and new signers during ordinary user journeys.

Rollback design must not make the compromised key the easiest recovery path. Keep a tested application and configuration rollback that references the new secret version; block automated restoration of the old pair; and require incident authority for any exception. If functionality fails, diagnose algorithm, inheritance, node, and application-state differences before reverting cryptographic trust. A rollback that restores the shared signer may recover availability while silently reopening cross-customer authorization, so its security consequence must be explicit in the change decision.

Rotation is intentionally disruptive to artifacts protected by the former machine key. Existing ViewState posted from old pages must fail; depending on application configuration, forms-authentication tickets or other System.Web protected data may also be invalidated. Plan for reauthentication and fresh page loads, communicate the maintenance effect, and monitor the reason text of 4009 events so expected old-state rejection is not confused with continuing exploitation or a node that missed the change.

Remove the old pair from every configuration source, deployment variable, image, backup workflow, secret store version exposed to automation, and break-glass document that could restore it. Disable or retire stale nodes before reopening traffic. Record the new secret version and protected fingerprint, not the raw value, against the intended farm group. An application-package upgrade without this revocation does not meet the advisory’s resolution; an updated primary with an old disaster-recovery image does not meet it either.

6.2 A compromised server and exposed learners need separate recovery

If evidence supports exploitation, rotation stops future state signed with the old key but cannot remove BLUEBEAM, reverse unauthorized ACL changes, restore modified JavaScript, or revoke credentials obtained after code execution. Microsoft’s machine-key response guidance explicitly warns that rotation is insufficient after successful exploitation and says internet-facing servers with disclosed keys should be fully investigated and strongly considered for offline reformatting and reinstallation. The recovery plan should favor rebuilding from trusted media over attempting to declare a changed host clean.

Before rebuild, preserve the evidence needed to understand reach and protect legal or regulatory obligations. Then replace the operating-system and application layers from verified sources, apply supported KnowledgeDeliver and .NET updates, restore only reviewed data, recreate IIS configuration and ACLs from approved baselines, deploy the new boundary-unique pair, and rotate credentials accessible to the application-pool identity or found in memory. Service accounts, database secrets, API tokens, signing material, deployment credentials, and administrative sessions are scoped by actual access and evidence, not automatically all enterprise credentials.

Sequence those changes so restored systems never authenticate with credentials already present on the compromised host. Create or rotate secrets through a clean administration path, rebuild the server while isolated, inject the new values, invalidate old sessions and tokens, and only then reconnect dependencies and traffic. Review backup content before restoration because a trusted timestamp does not guarantee a clean configuration or script. Retain an evidence copy separately from operational backups so later analysis does not require putting a suspect image back into service.

Compare the rebuilt application with the trusted release at file, configuration, module, handler, scheduled-task, service, and permission levels. Validate that the application pool cannot write broadly where it need not, and confirm remote-script additions and unauthorized redirects are absent. If an existing database is restored, review administrative changes and data access during the window before reconnecting it. A clean server image cannot undo a malicious database account or a stolen credential that remains valid elsewhere.

Handle the learner branch from its own evidence ledger. Preserve the compromised JavaScript and delivery logs, define the serving window, identify pages and caches that returned it, and group users by page receipt, remote-script fetch, installer download, and execution. Proxy, DNS, browser, EDR, and email or support records can refine those groups. Isolate and investigate endpoints that executed the lure or show BEACON behavior; give the broader cohorts specific browser, endpoint, and credential instructions tied to what was observed.

Recovery communications should distinguish exposure, confirmed server compromise, and confirmed endpoint infection. State what period was reviewed, which artifacts support the conclusion, what remains unavailable, and what users must do. Password or token resets are appropriate where the lure, endpoint evidence, or server access makes credential loss plausible; they are not a substitute for endpoint containment. The server and learner workstreams close only when their independent acceptance evidence is recorded and an accountable owner signs each residual risk.

7 Closure is a set of negative and positive proofs

The investigation ends only when teams can demonstrate a restored cryptographic boundary, a trustworthy application and server, resolved learner cohorts, and controls that prevent the shared value from returning.

7.1 Verify interoperability, revocation, uniqueness, and recovery

First prove intended interoperability. On every load-balanced node, start a fresh login and exercise representative pages that emit and consume ViewState. Pin requests to each node and then cross nodes so state issued by one peer is accepted by the others in the same logical farm. Record node identity, application-pool start time, configuration revision, secret version, test URI, time, and outcome. A health endpoint alone does not exercise the protected state path that the change affects.

Next prove revocation with benign material captured from the organization’s own application before rotation. Submit an archived ordinary page state in a controlled test and confirm it is rejected under the new pair. Check that the reason is consistent with old-key failure and that no stale node accepts it. Do not use the vulnerable shared key or a malicious object graph in routine production verification. The test asks whether former authorization was revoked, not whether code execution can be reproduced.

Then prove uniqueness. Inside the approved comparison system, calculate protected fingerprints for validation and decryption material on every node. All nodes inside one declared farm group should match the group; unrelated customers, environments, and standalone instances should not. Investigate partial matches as well as full-pair matches. Repeat the comparison against dormant images, disaster-recovery automation, and provisioning templates, and make the deployment fail if a future clone receives an existing boundary’s fingerprint unintentionally.

For a rebuilt compromised environment, verification continues beyond cryptography. Confirm the operating system and application came from trusted artifacts, file and configuration hashes match the approved release, ACLs match least-privilege baselines, no unapproved module or handler remains, application-pool memory starts from the rebuilt image, and outbound behavior fits the documented application. Validate database and identity changes separately. Preserve the before-and-after evidence so the result can be reviewed without trusting the same host that was compromised.

Finally, replay the detection workflow. Expected old-state failures should decline after the maintenance window; integrity-passing invalid-state sequences should not continue; w3wp.exe should not launch unexplained children or load unapproved assemblies; application files and permissions should remain stable; and no learner endpoint should continue contacting the documented delivery chain. Set an observation period based on traffic and retention rather than an arbitrary universal number, and identify who reviews alerts after the incident team stands down.

7.2 Durable controls keep deployment convenience from recreating trust

Provisioning should create the secret only after a new security boundary has a unique identity. Store it in a managed secret system or protected deployment channel, restrict retrieval to the service and operators that require it, and inject it without printing values to build logs. Infrastructure templates carry a reference, not reusable key bytes. The pipeline records the secret version and protected fingerprint, checks uniqueness, and refuses to publish a clone whose boundary has not received its own credential.

At-rest protection and access monitoring reduce the chance that one server becomes the source for another attack. Microsoft documents Protected Configuration for encrypting sensitive web.config sections, and its machine-key threat guidance recommends monitoring configuration access, including Windows Event 4663 where the audit policy and file SACL are configured appropriately. Tune the expected readers for each application pool and administration process; an event from an unfamiliar identity or executable becomes a hunt lead, not automatic proof of theft.

Treat confirmed or suspected key disclosure as an incident about signing authority, even when no payload has been found. Record which boundaries used the value, when each copy was valid, who and what could read it, and which protected artifacts remain active. Revoke it everywhere in that equivalence group, not only on the first server that raised an alert. The response owner may close exploitation as unobserved when evidence supports that statement, but cannot close the credential exposure until every copy and restoration path is accounted for.

Rotation needs a rehearsed runbook rather than a value-expiry checkbox. The runbook names farm membership, traffic-drain method, expected authentication and ViewState effects, rollback authority, secret-delivery path, stale-node controls, benign old-state test, fingerprint comparison, monitoring owner, and evidence record. A scheduled exercise should prove that a boundary can rotate without copying another customer’s secret and that rollback cannot restore the revoked pair. The organization chooses cadence based on policy and exposure; suspected disclosure triggers immediate rotation and investigation.

Governance should also track boundary changes. Merging farms, splitting tenants, moving between hosted and customer-managed service, adding a disaster-recovery region, or cloning production into test can change which nodes may legitimately share state. Make secret-scope review a required part of those architecture decisions. The rule is simple enough to automate—declared peers may match, undeclared boundaries must not—but the declaration itself needs a business and security owner so convenience cannot silently enlarge the trust group.

Platform hardening adds defense in depth but does not replace the boundary repair. Apply vendor-supported KnowledgeDeliver and .NET updates, reduce public reach, run the application pool with least privilege, restrict write access to web assets, monitor file integrity and child processes, and evaluate ASP.NET 4.8 AMSI and server attack-surface controls where compatible. These controls can detect or impede post-exploitation. None makes a known shared validation key safe, and none justifies retaining it for deployment convenience.

The final record must preserve the remaining unknowns. Public reporting does not name the KnowledgeDeliver page, the observed framework compatibility branch, the exact serialized token or gadget, the complete affected-customer set, or a threat actor. Those are not gaps to fill with inference. What can be concluded is sufficient and measurable: pre-February 24 standardized deployments may share a signer; a reachable unchanged instance can accept malicious ViewState and reach OS-level execution; the observed operation extended through server memory and trusted learner content; unique keys, evidence-led recovery, and explicit acceptance tests restore the boundary. Each future topology or credential change must preserve that proof.