I’m thrilled to sit down with Malik Haidar, a renowned cybersecurity expert with years of experience safeguarding multinational corporations from sophisticated cyber threats. With a unique blend of analytics, intelligence, and a business-driven approach to security, Malik has been at the forefront of tackling vulnerabilities and hacker tactics in complex environments. Today, we’re diving into the recent exploitation of a critical Sitecore zero-day vulnerability, exploring how attackers leveraged this flaw for malware delivery, their methods for maintaining access, and the broader implications for organizations. Our conversation will unpack the technical intricacies of the attack, the malware involved, and the strategies used by threat actors to infiltrate and persist within compromised systems.
Can you walk us through what the Sitecore zero-day vulnerability, tracked as CVE-2025-53690, entails and why it’s such a big deal?
Absolutely. This vulnerability is a deserialization of untrusted data flaw affecting older versions of Sitecore Experience Manager and Experience Platform, specifically prior to version 9.0, when deployed with a sample ASP.NET machine key that was exposed in deployment guides from 2017 and earlier. It’s a critical issue with a CVSS score of 9.0, which signals just how severe it is—think near-total compromise potential. This flaw allows attackers to execute remote code on internet-facing Sitecore instances, essentially giving them a direct path to infiltrate systems without much resistance.
How did attackers exploit this vulnerability to gain access to Sitecore deployments?
The attackers capitalized on the exposed ASP.NET machine key, which was meant to be unique but was instead a static sample in those old guides. They crafted a ViewState deserialization attack, targeting pages like /sitecore/blocked.aspx that don’t require authentication. ViewState, an ASP.NET feature for storing webpage state, can be manipulated if validation is weak or bypassed. With the machine key in hand, they could deserialize malicious payloads, effectively running their code on the server and opening the door to further compromise.
What can you tell us about the malware dropped in these attacks and its primary functions?
The key malware here is called WeepSteel, a .NET assembly designed for reconnaissance. Once deployed via the ViewState payload, it harvests detailed information about the system, network, and users. It then encrypts this data and sends it back to the attackers as a ViewState response, which is a clever way to blend in with legitimate traffic. Essentially, it’s a spy tool that maps out the environment for the attackers to plan their next moves.
After gaining that initial foothold, what steps did the attackers take to deepen their control over the compromised systems?
Once inside, they went after sensitive data by archiving the web root directory, likely to grab critical configuration files. They also conducted host and network reconnaissance to understand the environment better. Beyond that, they deployed open-source tools like EarthWorm for tunneling and DWagent for remote access, alongside SharpHound for Active Directory reconnaissance. They created local administrator accounts, often mimicking legitimate ASP.NET service accounts, to blend in and maintain control.
How did these threat actors ensure they could keep coming back to the compromised systems over time?
Persistence was a priority for them. They used a mix of tactics, including leveraging both newly created and compromised administrator credentials for Remote Desktop Protocol access. They issued commands to modify settings, like disabling password expiration on key accounts, ensuring those credentials remained usable long-term. It’s a subtle but effective way to keep a backdoor open without raising immediate red flags.
What did the attackers do with the data they managed to extract from these systems?
They focused on extracting valuable credentials by dumping the SYSTEM and SAM registry hives, which store local user password hashes. These hashes can be cracked offline or used in pass-the-hash attacks to authenticate elsewhere in the network. It’s a goldmine for escalating access or moving to other systems, turning a single breach into a broader compromise.
How did the attackers try to cover their tracks or expand their reach within the network?
They were quite methodical. After compromising other admin accounts, they deleted the ones they initially created to reduce traces of their entry. They also engaged in lateral movement, using stolen credentials to hop between systems within the network. This allowed them to explore deeper, conduct internal reconnaissance, and potentially target more valuable assets without tripping alarms early on.
What’s your forecast for the future of vulnerabilities like this in web application platforms?
I think we’re going to see more of these deserialization flaws and misconfiguration issues in web platforms as they become increasingly complex and widely adopted. Attackers are getting better at finding and exploiting obscure vectors like exposed keys or hidden endpoints. My forecast is that without proactive measures—like automated key generation, rigorous patch management, and better visibility into internet-facing assets—organizations will continue to be blindsided by zero-days. The onus is on both vendors to harden default configurations and businesses to prioritize security hygiene.
