Signed Lenovo driver can be abused to kill EDR processes on Windows

A legitimately signed Lenovo driver can be abused to terminate security tools at the kernel level, giving attackers a new path to disable endpoint defenses before running malware or post-exploitation tools.

Security researcher Jehad Abudagga analyzed BootRepair.sys, a Lenovo driver associated with Lenovo PC Manager. In a technical write-up, he said the driver exposes process-killing functionality that can be reached from user mode without proper access checks.

The finding highlights a Bring Your Own Vulnerable Driver attack risk. In these attacks, adversaries abuse a trusted but flawed kernel driver to perform actions that normal user-mode malware cannot easily perform.

BootRepair.sys exposes dangerous process termination behavior

The driver analyzed by Abudagga is named BootRepair.sys and has the SHA-256 hash 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946. The researcher said the file was digitally signed by Lenovo and had no VirusTotal detections at the time of analysis.

The problem sits in how the driver exposes its device interface. The driver creates a device object and symbolic link that user-mode applications can reach, but the researcher found no meaningful access control checks before a process receives a handle to the driver.

The driver then accepts a process ID and uses a Windows kernel routine to terminate the target process. In the proof of concept, this behavior allowed the researcher to terminate CrowdStrike Falcon’s sensor process after loading the driver.

Item	Details
Driver name	BootRepair.sys
Associated software	Lenovo PC Manager
Driver signer	Lenovo
Hash	5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946
Main risk	Security process termination at the kernel level
Attack category	Bring Your Own Vulnerable Driver

Why signed drivers create a security problem

Windows kernel drivers run with high privileges because they need deep access to hardware and operating system functions. That makes a vulnerable driver far more dangerous than a normal application bug.

CrowdStrike explains that BYOVD attacks involve loading a legitimate vulnerable driver, then abusing it to perform privileged actions such as disabling EDR, dumping protected processes, or bypassing normal operating system controls.

The danger comes from trust. A driver can be signed by a real vendor and still contain behavior that attackers can misuse. If a system allows that driver to load, malware can try to turn the trusted driver into a defense-disabling tool.

How attackers could abuse the Lenovo driver

The researcher described two realistic attack paths. If BootRepair.sys already exists and runs on a system, a low-privileged attacker may be able to interact with it and terminate sensitive processes.

If the driver is not already present, an attacker with enough access may bring the signed driver to the target and load it as part of a BYOVD chain. Once loaded, the driver can help shut down endpoint protection before credential theft, lateral movement, or ransomware staging.

The researcher’s analysis also showed that the vulnerable behavior does not require a complex exploit chain once the driver is accessible. That simplicity makes driver control and monitoring important for enterprise defenders.

• Terminate antivirus or EDR processes before malware execution.
• Reduce visibility before running credential theft tools.
• Bypass user-mode tamper protection through kernel-level access.
• Use a legitimate vendor signature to avoid simple trust-based blocks.
• Prepare the environment for ransomware or hands-on-keyboard activity.

This is a BYOVD risk, not a normal malware infection

BootRepair.sys does not automatically infect machines by itself. The risk comes from the way attackers can misuse it after they already have enough access to load or reach the driver.

That distinction matters for defenders. A normal antivirus signature may not flag the driver because the file can be legitimate and signed. Security teams need controls that inspect driver behavior, driver load events, and vulnerable driver lists.

Microsoft says its recommended driver block rules help harden systems against non-Microsoft drivers with known vulnerabilities, malicious behavior, or behavior that can bypass the Windows security model.

Scenario	Risk	Defensive focus
Driver already present	A local attacker may interact with it to terminate protected processes.	Inventory Lenovo components and watch driver access events.
Driver brought by attacker	Malware may load the signed driver to disable defenses.	Block unapproved driver loads and enforce driver control policies.
EDR process targeted	Security telemetry may drop before later attack stages.	Alert on sudden sensor shutdowns and suspicious kernel driver activity.

Microsoft’s driver blocklist can reduce exposure

Microsoft recommends using vulnerable driver blocking, HVCI, Smart App Control, S mode, or App Control for Business policies to reduce the risk from known vulnerable drivers.

The Microsoft guidance also notes that the vulnerable driver blocklist does not guarantee every vulnerable driver will be blocked. Organizations that need stronger control can apply more current recommended block rules through App Control for Business.

Microsoft also recommends an Attack Surface Reduction rule that blocks abuse of exploited vulnerable signed drivers. The Microsoft Security Experts blog says defenders should combine prevention, monitoring, and investigation because driver-based attacks can bypass user-mode security controls.

What security teams should check now

Organizations should first identify whether BootRepair.sys exists on managed endpoints. Lenovo systems, especially those using Lenovo PC Manager or related support utilities, should receive priority review.

Teams should also verify whether the Microsoft vulnerable driver blocklist, HVCI, and driver application control policies are enabled. Where possible, administrators should allow only approved drivers and block unknown or unnecessary kernel drivers.

Lenovo users should keep device software, drivers, and BIOS packages current through official support channels. Lenovo Support provides official driver, BIOS, and application update guidance for its devices.

• Search endpoints for BootRepair.sys and the published hash.
• Review recent driver load events and unusual kernel service creation.
• Enable or validate Microsoft’s vulnerable driver blocklist.
• Use App Control for Business or equivalent allowlisting for drivers.
• Monitor for sudden EDR or antivirus process termination.
• Update Lenovo software and drivers through official Lenovo tools.
• Rotate credentials if endpoint defenses were disabled before other suspicious activity.

Key indicators and detection points

Defenders should treat the published hash, driver name, and suspicious driver load behavior as investigation leads. The presence of the file alone does not prove compromise, but unusual loading, process termination, or security tool shutdowns deserve immediate review.

The CrowdStrike analysis of BYOVD intrusions also shows why defenders should monitor for attackers writing kernel drivers to disk and loading them during intrusions. These events often happen before credential dumping or ransomware activity.

Enterprises should combine endpoint telemetry with Windows Code Integrity logs, driver inventory, application control events, and EDR tamper alerts. Microsoft’s prevention guidance also recommends strong monitoring for vulnerable driver abuse across Windows environments.

Type	Indicator or behavior
Driver file	BootRepair.sys
SHA-256	5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946
Device interface	BootRepair driver interface exposed to user-mode access
Behavior	Unexpected antivirus or EDR process termination
Behavior	Suspicious kernel driver service creation or loading

Driver control is now a core endpoint defense

The Lenovo BootRepair.sys research shows why signed code cannot receive automatic trust. A signed driver can still contain unsafe functionality, and attackers can turn that functionality against endpoint defenses.

Organizations should treat vulnerable drivers as part of their attack surface. That means tracking driver inventory, testing block policies, monitoring driver loads, and keeping OEM tools updated.

For Lenovo systems, administrators should use official update channels such as Lenovo’s driver and BIOS update guidance while also enforcing Microsoft driver controls. This layered approach can reduce the chance that a trusted driver becomes the tool that disables endpoint protection.

FAQ