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.
