asp[.]net

Sitecore zero-day vulnerability exploited by attackers (CVE-2025-53690) A threat actor is leveraging a zero-day vulnerability (CVE-2025-53690) and an exposed sample ASP.NET machine key to breach internet-facing, on-premises deployments of several Sitecore solutions, Mandiant has revealed. About CVE-2025-53690 CVE-2025-53690 is a ViewState deserialization vulnerability that affects any version of Sitecore Experience Manager (XM), Experience Platform (XP), Experience Commerce (XC), and Managed Cloud. Deployed instances are affected by this vulnerability if they have been deployed by using a sample machine key that has been provided with deployment instructions for XP 9.0 or earlier and Active Directory 1.4. It may also impact “all versions XM, XP, XC topologies for all releases if deployed in a multi-instance mode with customer-managed static machine keys, and may impact Managed Cloud Standard with Containers environments if deployed in a multi-instance mode,” according to Sitecore. A successful exploitation of the flaw may allow – and apparently did allow – attackers to achieve remote code execution on vulnerable internet-facing instances. The spotted ViewState deserialization attack Mandiant’s incident responders have been called in and disrupted the attack before it could be concluded, so they don’t have a complete view of the entire attack lifecycle. What they know is that the threat actor first probed the victim’s web server with HTTP requests to various endpoints, and ultimately concentrated on the /sitecore/blocked.aspx page, which uses a hidden ViewState form. “ViewStates are an ASP.NET feature designed to persist the state of webpages by storing it in a hidden HTML field named __VIEWSTATE,” the responders explained. “ViewState deserialization attacks exploit the server’s willingness to deserialize ViewState messages when validation mechanisms are either absent or circumvented. When machine keys (which protect ViewState integrity and confidentiality) are compromised, the application effectively loses its ability to differentiate between legitimate and malicious ViewState payloads sent to the server.” Armed with the right machine key and a publicly available tool, the attackers managed to create malicious ViewState requests that allowed them to achieve remote code execution. Once they got in, they installed software tools and malware that would help them: Gather and exfiltrate system, network, and user information from the compromised system via __VIEWSTATE responses Exfiltrated critical Sitecore configuration files, which contain sensitive information about the application’s backend and its dependencies List processes, services, active network connections running on the vulnerable host, discover user accounts and TCP/IP configurations Download additional tools that would allow them to establish covert C2 communication and archive files Create local administrator accounts and obtain access to domain administrator accounts Install the DWAGENT open-source remote access tool and establish a remote session Steal tokens and compromise credentials Identify Domain Controllers within the target network and perform extensive Active Directory reconnaissance Use compromised administrator accounts to RDP to other hosts on the network What to do? “The attacker’s deep understanding of the compromised product and the exploited vulnerability was evident in their progression from initial server compromise to privilege escalation,” Mandiant’s responders opined. They have shared indicators of compromise and a YARA rule for detecting the presence of the WeepSteel reconnaissance tool used by the attackers. Organizations that have deployed any of the vulnerable Sitecore solutions and exposed them to the internet should look for evidence of compromise. According to Mandiant, Sitecore has confirmed that its updated deployments automatically generate a unique machine key, and that affected customers have been notified. Sitecore has also provided guidance on what potentially affected customers should do and pointed to advice on how to protect the ASP.NET machineKey from unauthorized access. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

Threat actors have been using an exposed ASP.NET machine key for remote code execution (RCE) on vulnerable Sitecore deployments, Google warns. Adversaries used a sample machine key that was included in Sitecore deployment guides from 2017 and earlier and executed a ViewState deserialization attack against internet-accessible Sitecore instances. The issue, tracked as CVE-2025-53690 (CVSS score of 9.0), is described as a deserialization of untrusted data bug affecting Sitecore Experience Manager (XM) and Experience Platform (XP) prior to version 9.0 that were deployed using the sample key exposed in the guides. Sitecore has addressed the security defect and released an advisory to provide organizations with recommended mitigation guidance and indicators-of-compromise (IoCs). “Sitecore has confirmed that its updated deployments automatically generate a unique machine key and that affected customers have been notified,” Google notes. As part of the observed attacks, which were quickly disrupted, the hackers used a ViewState payload containing the WeepSteel malware, which enables internal reconnaissance. Furthermore, Google observed the threat actor archiving the root directory of the web application (likely to obtain sensitive files), performed host and network reconnaissance, deployed open source tools for network tunnelling and remote access, and created local administrator accounts. The attacks started with HTTP requests, for probing purposes, followed by ViewState deserialization attacks on the /sitecore/blocked.aspx page, which uses a hidden ViewState form and can be accessed without authentication. An ASP.NET feature, ViewState stores the state of a webpage in a hidden HTML field, for persistence. Attackers can target the server to deserialize ViewState messages if validation mechanisms are missing or can be bypassed, and the exposed machine key opens the door for the fresh attack. WeepSteel, the .NET assembly deployed in this attack, can harvest system, network, and user information, encrypt the data, and send it to the attackers as a ViewState response. After initial compromise, the attackers exfiltrated critical configuration files by archiving the web root directory, fingerprinted the server, and deployed in public directories open source tools such as the EarthWorm tunneler, the DWagent remote access tool, and the SharpHound AD reconnaissance tool. They then created a local administrator account mimicking the name of an ASP.NET service account, established a remote session, created a second local admin account, and executed a binary named GoToken, which appears to be GoTokenTheft, a token-stealing tool written in Golang. The hackers then established Remote Desktop Protocol access using the newly created accounts and dumped the SYSTEM and SAM registry hives, to extract the password hashes for local users. “The threat actor maintained persistence through a combination of methods, leveraging both created and compromised administrator credentials for RDP access. Additionally, the threat actor issued commands to maintain long-term access to accounts. This included modifying settings to disable password expiration for administrative accounts of interest,” Google notes. The attackers were also seen deleting the created accounts after compromising other admin users, performing internal reconnaissance, and moving laterally using the compromised accounts. Related: Two Exploited Vulnerabilities Patched in Android Related: Google Patches High-Severity Chrome Vulnerability in Latest Update