Security researchers have disclosed a now-remediated flaw that could have allowed specially crafted notifications from common messaging an...
Last month, cybersecurity researchers announced that they had successfully located and analyzed the project. Their investigation uncovered malware dating back to 2005 that was reportedly designed to manipulate software believed to be used by Iranian nuclear scientists, demonstrating that the Shadow Brokers leak continues to reveal new chapters in cyber espionage history.
Hackers found the stolen machine key and used it in ViewState deserialization campaigns to sign infected ViewState payloads and launch remote code execution (RCE) at the OS level.
In 2025, Mandiant responded to a campaign on a KnowledgeDeliver server and said that in the beginning, the bug was abused as a zero-day to deploy a compromised script into the web platform.
The compromise was also possible as threat actors used “identical pre-shared ASP.NET machine keys across multiple customer deployments,” the experts said.
According to Mandiant, “KnowledgeDeliver installations deployed before Feb. 24, 2026 relied on a standardized web.config file provided by the vendor. This configuration file contained hardcoded machineKey values used by the ASP.NET framework to encrypt and sign data, including ViewState payloads.”
Experts said that the code on the platform lured users to download a malicious installer, which compromised the machine with a Cobalt Strike beacon by deploying a backdoor.
The encrypted payload used a key “that used the name of the compromised organization, which indicated that the threat actor prepared this payload specifically for the targeted organization,” Mandiant report said.
In August last year, experts from ASEC also disclosed that Godzilla was planted in ASP.NET environments in ViewState deserialization attacks against firms in the finance industry.
Threat actors could modify a JavaScript file with code that asked users to run a ‘security authentication plugin’ and install a malicious script from a domain that hackers used.
In recent years, threat actors are increasingly exploiting unsafe machine keys in Viewstate deserialization attacks against web platforms for a few products.
Threat actors utilized a hardcoded machine key in March of last year to create a malicious payload that gave them access to Gladinet CenterStack's secure file-sharing servers.
After obtaining the machine key to generate signed malicious ViewState payloads, hackers gained access to 85 Microsoft SharePoint systems in July 2025.
Additionally, state-sponsored actors utilized ViewState deserialization assaults to install WeepSteel, a spying tool that revealed the ASP.NET machine key on Sitecore servers.
A security researcher has uncovered a weakness in a Lenovo-signed Windows driver that could allow attackers to disable antivirus and endpoint security tools, potentially weakening a system's defenses before carrying out additional malicious activity.
The finding involves BootRepair.sys, a driver linked to Lenovo PC Manager. According to research conducted by security researcher Jehad Abudagga, the driver contains functionality that can be exploited to terminate processes directly from the Windows kernel. Because the file is legitimately signed by Lenovo, it may appear trustworthy to operating systems and security products that rely on digital signatures when evaluating software.
At the time of the analysis, the driver, identified by the SHA-256 hash 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946, reportedly had no detections on VirusTotal. Security researchers note that attackers often favor signed and seemingly legitimate software components because they can help malicious activity blend into normal system operations.
The research surfaces the growing nature of this particular attack technique known as Bring Your Own Vulnerable Driver, or BYOVD. In these attacks, threat actors deliberately use trusted but flawed drivers to gain elevated capabilities inside a system. Rather than exploiting security software directly, attackers abuse weaknesses in legitimate drivers to bypass protections and interfere with defensive tools.
A detailed examination of BootRepair.sys revealed several security weaknesses. The driver creates a device object called "\Device\::BootRepair" without applying a secure discretionary access control list (DACL). In practical terms, this means users with limited privileges may still be able to communicate with the driver.
The driver also creates a symbolic link named "\DosDevices\BootRepair," making the functionality accessible from user-mode applications. Researchers further found that the driver does not perform access-control validation when processing IRP_MJ_CREATE requests. As a result, any user can potentially obtain a handle to the driver without undergoing meaningful permission checks.
Analysis of the driver's input and output control functionality identified a single exposed IOCTL code, 0x222014. This control code accepts a four-byte input buffer that contains a process identifier, commonly referred to as a PID. Once received, the PID is passed to an internal routine responsible for terminating the specified process.
The underlying mechanism relies on the Windows kernel function ZwTerminateProcess. Because the operation is performed in kernel mode, the driver can terminate processes that would ordinarily be protected from interference. This includes security-sensitive services and endpoint protection products that are designed to prevent unauthorized shutdown attempts.
According to the research, these weaknesses create two primary attack opportunities. If the driver is already installed on a target system, an attacker with limited privileges could interact with it directly and terminate antivirus or endpoint detection and response (EDR) processes. If the driver is not present, an attacker could deploy the signed driver as part of a BYOVD operation, load it into the kernel, disable security controls, and then proceed with post-compromise activities.
In a proof-of-concept demonstration, the researcher showed that even protected processes could be terminated once the driver had been loaded. The test used standard Windows APIs to communicate with the driver. The process involved opening a handle to "\\.\BootRepair," sending a target process identifier through IOCTL code 0x222014, and allowing the driver to terminate the selected process from kernel mode.
The simplicity of the proof-of-concept demonstrates how little effort may be required to exploit the functionality once access to the driver is available. Researchers warn that after security products are disabled, attackers may be able to run credential theft tools, information stealers, or other post-exploitation utilities with a lower likelihood of detection.
The findings also reinforce concerns surrounding BYOVD attacks, which have become increasingly common in ransomware operations and advanced intrusion campaigns. Because vulnerable drivers often carry legitimate digital signatures, they can sometimes evade security controls that place significant trust in signed software.
To reduce exposure, organizations are encouraged to implement Microsoft's vulnerable driver blocklist, monitor systems for unusual driver-loading activity, restrict the installation of unauthorized drivers, and watch for suspicious kernel-level behavior. Security teams should also ensure that endpoint protection platforms are configured to detect attempts to abuse legitimate drivers.
The research serves as another example of how trusted software components can become security liabilities when design weaknesses are present. As attackers continue searching for legitimate tools that can be repurposed for malicious activity, organizations will need stronger controls around driver management, behavioral monitoring, and endpoint visibility to prevent security products from being disabled before an attack fully unfolds.