The EDR killer who takes advantage of an old driver and exposes the BYOVD threat on Windows

A recent Huntress investigation revealed a maneuver that sounds like déjà vu for anyone following security in Windows, but that continues to work in the real world: malicious actors took advantage of an old legitimate EnCase driver to create a "EDR killer" able to identify and turn off dozens of security tools in infected teams.

Before you go into details, you should remember what an EDR killer is. This is a malicious program specifically designed to disable or avoid endpoints response and detection solutions. They usually operate with kernel privileges because, from there, they can unhook protection mechanisms and finish security processes that in user mode would be inaccessible. In this particular case the researchers of Huntress they saw how the malicious piece was disguised as a firmware update utility and loaded an old driver called EnPortv.sys, belonging to EnCase (forensic research product now in OpenText).

The technique used is not new and has a name: "Bring Your Own Vulnerable Driver" or BYOVD. Instead of looking for an explosion in the current kernel, attackers introduce a legally signed but vulnerable driver - or with functions that allow abuse - and use it to execute operations in kernel mode. malware groups and samples have repeatedly exploited BYOVD; old signatures, driver signature behaviors and exceptions in Microsoft policies have made this approach still effective. To understand the technique in more depth it is worth reading analysis and background pieces on BYOVD, such as the ESET article on the subject Here..

In the intrusion described by Huntress, the initial access was obtained by committed credentials from a SonicWall SSL VPN, and the account had no multi-factor authentication. After access, the attackers carried out an intense internal survey - ICMP pings, NetBIOS surveys, SMB activity and SYN-type TCP bursts - and, according to researchers, the actor probably intended to deploy ansomware although the campaign was interrupted before releasing the final load. The case highlights an operational truth: the absence of MFA and the poor monitoring of VPN records are common entry doors for intruders. Microsoft has repeatedly documented MFA's effectiveness in reducing commitments; for example, its security blog describes how MFA blocks the vast majority of accountability attempts Here..

The central technical vector was the EnPortv.sys driver, a component of EnCase. Although its digital certificate was issued in 2006, expired in 2010 and was revoked, Windows continued to allow its load for a detailed implementation of the driver signature mechanism: the check is based on cryptographic verification and time stamps, not a real-time consultation of revocation lists (CRL) for all cases, and there is also an exception that applies to certificates issued before July 29, 2015. This exception, along with the various historical signature policies, opened the door so that the driver could be installed and registered as a false OEM hardware service, achieving persistence resistant to rebeginnings.

Once in kernel, malware used the IOCTL driver interface to order the system to complete security service processes, avoiding protections like Protected Process Light (PPL). According to Huntress the sample comes with a list of 59 target processes - between EDR agents and antivirus - and runs a completion loop every second, so that if a protected process restarts, the killer kills it again instantly. This combination of persistence at the kernel level and the ability to manipulate system processes is what makes it a critical threat to environments with traditional EDR-focused controls.

If you want to read the technical analysis, the Huntress report describes the full flow, indicators and mechanisms of persistence Here.. The public press release and additional coverage, such as BleepingComputer They help put the incident in the broader picture of signed driver abuse.

What can a security team do to reduce this type of risk? First, we have to attack the most direct cause of access: the remote access accounts. Enable MFA in all remote accesses, monitor VPN logs and limit account privileges are steps that often stop the initial progress of these campaigns. Second, it is appropriate to take advantage of the mitigation that Microsoft offers for drivers and kernel insulation: to enable HVCI / Memory Integrity (part of the "core isolation" in Windows) helps to apply the list of vulnerable drivers blocked by Microsoft; the technical documentation of Virtualization-based Security and HVCI provides context on how this isolation works. Here. and Microsoft's guide to Windows Defender Application Control (WDAC) explains how to control which binaries and drivers are allowed in a fleet Here..

In addition to HVCI and WDAC, there are rules and controls in modern security solutions designed to reduce exposure to signed drivers that were revoked or malfunctioning. Implement Attack Surface Reduction (ASR) rules, monitor the creation of kernel services that pass through OEM / hardware and block known problematic signatures are measures that Huntress also recommends. ASR documentation in Microsoft Defender for Endpoint is a good starting point for Windows environment management teams Here..

It is not just a matter of technology: early detection of horizontal movements and intelligence about unusual activity in the internal network are critical. In the case analysed, the intruders carried out ICMP, NetBIOS surveys and noisy SMB traffic; monitoring these patterns and alerting to abnormal bursts - such as high rates of SYN - may interrupt an operation before the actor deploys its persistence tools. It is also important to prepare responses that include isolation of affected segments and forensic review of exposed credentials.

For teams that manage forensic solutions or use third-party tools signed years ago it is appropriate to review inventory and telemetry: What drivers with old signatures are deployed in your park? Do installed drivers appear that are registered as OEM components and do not match real hardware? Block and review drivers signed with certificates issued long ago or revoked reduces the surface for BYOVD attacks. Microsoft's kernel-mode driver signature policy and historical exceptions are documented in the documentation for developers and driver signatures; reading that regulation helps to understand why old certificates are still accepted by some Windows versions Here..

This incident puts an important lesson on the table again: modern defenses require layers. To rely only on an EDR without strong access controls, without kernel isolation and without policies that restrict signed drivers is not enough. A good defence plan combines preventive controls (MFA, driver signature and blocking policies), detection (network telemetry and endpoints) and response (procedures for decoupling, containing and analysing).

If you manage Windows infrastructure, first check the accounts with remote access and force MFA. It then assesses the possibility of activating HVCI / Memory Integrity, setting up WDAC / ASR according to your risk and auditioning the presence of historically signed drivers on your teams. For technical details and the incident commitment indicators, see Huntress's report Here. and, for BYOVD context, ESET research Here..

The good news is that the defenses exist and are strengthening. The bad news is that the historical compatibility, the legitimate use of forensic or management tools and the complexity of the driver ecosystem continue to provide loopholes that the attackers take advantage of. Having a clear policy on drivers, active monitoring and robust access controls significantly reduces the possibility of an actor turning a historical vulnerability into a devastating incident.