EDR Killer Tool Uses Signed Kernel Driver From Forensic Software
Summary:
A critical "EDR Killer" technique utilizes a legitimate but vulnerable driver associated with OpenText’s EnCase forensic software to systematically dismantle system defenses. This "Bring Your Own Vulnerable Driver" (BYOVD) attack involves dropping a known-vulnerable, digitally-signed driver onto a target system. Because the driver carries a valid signature from a trusted vendor, it frequently bypasses standard driver signature enforcement and automated whitelisting protocols. Once the driver is loaded, the vulnerability within it is exploited to grant the attacker kernel-level privileges. From this position of total authority, the malware can forcibly terminate the processes and services of Endpoint Detection and Response (EDR) and Antivirus (AV) tools, effectively blinding security operations before the final payload, typically ransomware, is executed.
The attack is orchestrated through a specialized loader script designed to automate the exploitation process. Upon gaining initial access, the loader identifies the specific version of the operating system to ensure the EnCase driver is correctly mapped into memory. By utilizing specific IOCTL (Input/Output Control) codes to communicate with the vulnerable driver, the malware can bypass Windows Kernel Patch Protection (KPP). This allows for the direct manipulation of kernel objects, specifically targeting the process structures of security software to strip them of permissions or terminate them entirely. This depth of access ensures that malicious activity remains undetected by traditional monitoring hooks, as the tools designed to report such activity are neutralized at a layer deeper than they are capable of defending.
Security Officer Comments:
This situation underscores a critical shift in the cat-and-mouse game between attackers and security vendors. By targeting a tool like EnCase, which is ironically a staple of forensics and incident response, threat actors are turning the security industry’s own trusted ecosystem against itself. For IT-ISAC organizations, particularly those in critical infrastructure, the impact is two-fold: first, it renders high-cost EDR investments moot if the "killer" script is successful; and second, it exploits the inherent trust we place in signed software. This is not just a malware problem; it is a trust-model problem. If your security stack relies solely on "is this file signed?" without monitoring what that signed file is doing in the kernel, the environment is vulnerable to this tactic.
Furthermore, the broad range of sectors from manufacturing to finance, means that a "one-size-fits-all" security posture often leaves gaps in kernel-level visibility. Administrative rights remain the keys to the kingdom; once an attacker can load a driver, they effectively own the hardware. We should expect to see this trend continue as ransomware groups increasingly professionalize their "defense evasion" modules to ensure their encryption routines go uninterrupted. Organizations should evaluate their internal "allow lists" for forensic tools and ensure that even trusted administrative accounts are restricted from loading non-essential drivers in production environments.
Suggested Corrections:
Link(s):
https://www.bleepingcomputer.com/ne...-signed-kernel-driver-from-forensic-software/
A critical "EDR Killer" technique utilizes a legitimate but vulnerable driver associated with OpenText’s EnCase forensic software to systematically dismantle system defenses. This "Bring Your Own Vulnerable Driver" (BYOVD) attack involves dropping a known-vulnerable, digitally-signed driver onto a target system. Because the driver carries a valid signature from a trusted vendor, it frequently bypasses standard driver signature enforcement and automated whitelisting protocols. Once the driver is loaded, the vulnerability within it is exploited to grant the attacker kernel-level privileges. From this position of total authority, the malware can forcibly terminate the processes and services of Endpoint Detection and Response (EDR) and Antivirus (AV) tools, effectively blinding security operations before the final payload, typically ransomware, is executed.
The attack is orchestrated through a specialized loader script designed to automate the exploitation process. Upon gaining initial access, the loader identifies the specific version of the operating system to ensure the EnCase driver is correctly mapped into memory. By utilizing specific IOCTL (Input/Output Control) codes to communicate with the vulnerable driver, the malware can bypass Windows Kernel Patch Protection (KPP). This allows for the direct manipulation of kernel objects, specifically targeting the process structures of security software to strip them of permissions or terminate them entirely. This depth of access ensures that malicious activity remains undetected by traditional monitoring hooks, as the tools designed to report such activity are neutralized at a layer deeper than they are capable of defending.
Security Officer Comments:
This situation underscores a critical shift in the cat-and-mouse game between attackers and security vendors. By targeting a tool like EnCase, which is ironically a staple of forensics and incident response, threat actors are turning the security industry’s own trusted ecosystem against itself. For IT-ISAC organizations, particularly those in critical infrastructure, the impact is two-fold: first, it renders high-cost EDR investments moot if the "killer" script is successful; and second, it exploits the inherent trust we place in signed software. This is not just a malware problem; it is a trust-model problem. If your security stack relies solely on "is this file signed?" without monitoring what that signed file is doing in the kernel, the environment is vulnerable to this tactic.
Furthermore, the broad range of sectors from manufacturing to finance, means that a "one-size-fits-all" security posture often leaves gaps in kernel-level visibility. Administrative rights remain the keys to the kingdom; once an attacker can load a driver, they effectively own the hardware. We should expect to see this trend continue as ransomware groups increasingly professionalize their "defense evasion" modules to ensure their encryption routines go uninterrupted. Organizations should evaluate their internal "allow lists" for forensic tools and ensure that even trusted administrative accounts are restricted from loading non-essential drivers in production environments.
Suggested Corrections:
- Enable MFA on all remote access services - the initial compromise was possible because the SonicWall SSLVPN account lacked multi-factor authentication
- Review VPN authentication logs for anomalous login patterns and denied access attempts preceding successful authentication
- Enable HVCI / Memory Integrity - ensures Microsoft's Vulnerable Driver Blocklist is enforced
- Alert and monitor services with names mimicking OEM/hardware components created outside normal software deployment
- Deploy Microsoft's recommended driver block rules via WDAC to block known vulnerable drivers
- Enable ASR rule "Block abuse of exploited vulnerable signed drivers" to prevent applications from writing vulnerable drivers to disk
Link(s):
https://www.bleepingcomputer.com/ne...-signed-kernel-driver-from-forensic-software/