Exploitation of KnowledgeDeliver via ViewState Deserialization Vulnerability

The ASP.NET ViewState persists page state across postbacks. When the machineKey is known, a threat actor can craft a malicious ViewState payload. By sending this payload in an HTTP request (via the __VIEWSTATE parameter), the threat actor can make the server deserialize it.

This technique follows the pattern of the ViewState Deserialization Zero-Day Vulnerability affecting Sitecore (previously reported by Mandiant), and Code injection attacks using publicly disclosed ASP.NET machine keys reported by Microsoft. This highlights how it is critical to keep the machine key unique and secure.

Post-Exploitation Activity

Once access was established, the threat actors focused on maintaining their presence and expanding the impact of the compromise.

BLUEBEAM Web Shell Deployment

The threat actor deployed a .NET-based in-memory web shell called BLUEBEAM (also known as Godzilla). The use of BLUEBEAM is consistent with the Microsoft reporting. This malware operates entirely in memory within the IIS worker process (w3wp.exe), making it difficult to detect through traditional file-based scanning. It allows threat actors to execute further commands and payloads by sending encrypted data via HTTP POST request bodies.

File Tampering

The threat actor was observed executing commands to escalate their control over the web server’s file system:

1. Permission Modification: The threat actor used icacls to grant “Everyone” full access to the web application directory.

2. JavaScript Tampering: The threat actor modified an application JavaScript file, adding code to perform the following:

• Display a fake security alert, prompting users to install a “security authentication plugin”.

• Silently load a remote malicious script hosted on a threat actor-controlled domain.

Cobalt Strike Infection

The remote script convinced users to download a fake installer, which led to workstations being infected with a Cobalt Strike BEACON backdoor. The payload was encrypted using a key that used the name of the compromised organization, which indicated that the threat actor prepared this payload specifically for the targeted organization.

How to Hunt for This Activity

Organizations should monitor for the following indicators to identify potential ViewState exploitation and post-exploitation activity.

1. Application Event Logs (Event ID 1316)

Monitor the Windows Application log for Event ID 1316 from the source ASP.NET 4.0.30319.0 (or similar).

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

• Successful Execution (Invalid ViewState): Event code: 4009-++-Viewstate verification failed. Reason: Viewstate was invalid. Confirms integrity checks were passed. Deserialization of the payload was attempted and may have succeeded. The payload may or may not have been executed. 

Mandiant decrypted payload strings recorded in the event log messages with the server’s machine keys and recovered a payload related to a BLUEBEAM web shell.

2. Suspicious Process Activity

Monitor for unusual child processes spawned by w3wp.exe. Commands observed include:

• cmd.exe /c ...

• whoami

• powershell.exe

3. File Integrity Monitoring

Monitor for unauthorized changes to .js, .aspx, or .config files within the web root. Specifically, look for the addition of remote script loaders or unusual logic in commonly used libraries.

4. Anomalous User-Agent Strings

Mandiant identified User-Agent strings consisting of two distinct identifiers concatenated together, which were consistent with ones reported in ViewState Deserialization Zero-Day vulnerability. Monitor for web request logs for such anomalous User-Agent strings. The following are examples of identified User-Agent strings:

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

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

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

Remediation and Mitigation

• Rotate Machine Keys: Immediately generate a unique, cryptographically strong machine key for each KnowledgeDeliver instance. This is the only way to invalidate the shared secret.

• Restrict Access: If possible, limit access to the LMS to known organizational IP address ranges.

• Investigation: Hunt for this activity, and conduct a thorough investigation if any signs of exploitation are identified.

Outlook and Implications

The exploitation of KnowledgeDeliver highlights the severe risks of using shared secrets in deployment templates. A single leaked key can compromise an entire ecosystem of installations. By implementing unique secrets and robust endpoint monitoring, organizations can defend against these deserialization attacks.

Indicators of Compromise (IOCs)