Critical Lenovo Driver Vulnerability Lets Attackers Disable EDR

Key Takeaways

• A critical vulnerability exists in a legitimate Lenovo driver (BootRepair.sys) that allows for the termination of arbitrary processes, including EDR solutions.
• The flaw facilitates “Bring Your Own Vulnerable Driver” (BYOVD) attacks, enabling attackers to bypass endpoint security.
• The driver is digitally signed by Lenovo, making it a stealthy tool for adversaries as it initially evades detection by traditional security software.
• Researcher Jehad Abudagga identified the vulnerability, demonstrating its potential to disable prominent EDRs like CrowdStrike Falcon.
• Organizations must implement robust driver control and behavioral monitoring to mitigate this advanced threat.

Lenovo Driver Flaw Allows EDR Disabling

A significant security vulnerability has been uncovered within a digitally signed Lenovo driver, BootRepair.sys, originally part of the Lenovo PC Manager utility. This flaw permits attackers to exploit the driver to terminate any process at the kernel level, including critical Endpoint Detection and Response (EDR) solutions, thereby paving the way for advanced “Bring Your Own Vulnerable Driver” (BYOVD) attacks.

Security researcher Jehad Abudagga conducted an in-depth analysis of the driver (SHA-256: 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946). He found that despite being a legitimate, signed component, it could be weaponized. At the time of Abudagga’s investigation, the driver showed no detections on VirusTotal, making it a highly attractive option for threat actors seeking to operate covertly.

Technical Deep Dive into the Vulnerability

Abudagga’s reverse engineering efforts revealed several critical security weaknesses within the BootRepair.sys driver that facilitate unauthorized access and process termination:

• The driver initializes a device object named Device::BootRepair without implementing a secure Discretionary Access Control List (DACL). This oversight allows users with low privileges to interact with the device.
• A symbolic link, DosDevicesBootRepair, further exposes this device to user-mode applications, widening the attack surface.
• Crucially, the driver lacks access control checks when processing IRP_MJ_CREATE requests. This means any user on the system can obtain a handle to the driver, bypassing intended security restrictions.

Further examination of the driver’s I/O Control (IOCTL) handler exposed a specific control code, 0x222014. This control code is designed to accept a 4-byte input buffer, which contains a Process ID (PID). This PID is then fed into an internal routine responsible for process termination. The underlying function leverages the Windows kernel API ZwTerminateProcess, effectively granting any user the capability to terminate arbitrary processes, including those deemed protected or critical for system security.

Attack Scenarios and EDR Bypass

The identified vulnerabilities open two primary avenues for exploitation:

• If the vulnerable driver is already installed on a system, a low-privileged attacker can directly interact with it to terminate antivirus or EDR processes, clearing the path for malicious activities.
• In scenarios where the driver is not present, attackers can deploy the signed BootRepair.sys as part of a BYOVD attack. By loading this legitimate, yet vulnerable, driver into the kernel, they can disable endpoint defenses before executing post-exploitation tools, such as credential dumpers.

In a compelling proof-of-concept, Jehad Abudagga demonstrated the severity of this flaw by successfully terminating even highly protected processes, including CrowdStrike’s Falcon sensor, after loading the vulnerable driver. Once security mechanisms are disabled, offensive tools like Mimikatz can be executed without interference, allowing attackers to dump credentials and escalate privileges.

Researcher Jehad Abudagga highlighted the simplicity of weaponizing this flaw in his report shared with Cyber Security News, stating that the PoC interacts with the driver using standard Windows APIs:

• It opens a handle to .BootRepair.
• It sends a target PID via IOCTL 0x222014.
• The driver then terminates the specified process in kernel mode.

This straightforward interaction underscores how minimal effort is required for adversaries to exploit this vulnerability once the driver is accessible.

Security Implications

This discovery highlights the increasing sophistication of BYOVD attacks, where adversaries exploit trusted, digitally signed drivers to circumvent endpoint protection mechanisms. The legitimate signature of the BootRepair.sys driver, coupled with its initial undetectability by many security solutions, makes it a potent tool for evading traditional security controls that rely on signature-based trust.

What You Should Do

• Implement a Driver Blocklist: Organizations should leverage Microsoft’s recommended driver blocklist to prevent the loading of known vulnerable drivers, including BootRepair.sys.
• Monitor for Suspicious Driver Loads: Deploy and configure EDR and XDR solutions to actively monitor for suspicious driver loading activities and unusual kernel-level behavior.
• Restrict Driver Installation: Enforce strict policies to restrict the ability of users and non-administrative processes from installing unsigned or unapproved drivers.
• Enhance Behavioral Detection: Utilize EDR and other security tools that offer advanced behavioral detection capabilities to identify and flag the abuse of legitimate drivers, even if they are signed.
• Regularly Update Systems: Ensure all systems are regularly updated with the latest security patches and driver updates provided by vendors.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.