BYOVD via EnCase: When the Forensic Driver Becomes the Weapon
11.08.2026 byovdedr-evasiondriver-signingsonicwall
When a Forensic Tool Becomes an EDR Killer
In February 2026, Huntress investigated an incident that should give every DFIR practitioner pause. Attackers used compromised SonicWall SSLVPN credentials to gain initial access, then deployed an EDR killer that abuses a legitimate Guidance Software (EnCase) forensic driver with a revoked certificate to terminate security processes from kernel mode — a classic Bring-Your-Own-Vulnerable-Driver (BYOVD) technique, but with a particularly bitter twist: a driver from the digital forensics toolkit itself becomes the weapon against defenders.
The attack was disrupted before ransomware deployment, but the case highlights a growing trend: threat actors weaponizing signed, legitimate drivers to blind endpoint security. The EnCase driver’s certificate expired in 2010 and was subsequently revoked, yet Windows still loads it, a gap in Driver Signature Enforcement that attackers continue to exploit.
The Technical Gap: Why a Dead Driver Still Loads
The root cause lies in a legacy quirk of Windows’ driver-signing architecture. The attack relies on a known gap in Windows Driver Signature Enforcement (DSE). The deployed driver is a legitimate component of Guidance Software’s EnCase forensic suite (EnPortv.sys), signed with a certificate that expired in 2010 and was subsequently revoked. Despite the revocation, Windows loads the driver because the kernel primarily validates the cryptographic integrity of the signature rather than checking the Certificate Revocation List (CRL) during boot. Because the driver was timestamped by a trusted authority before the certificate expired, it meets Microsoft’s legacy exception for drivers signed prior to July 29, 2015.
A decade-old, officially invalid signature timestamp is therefore still enough to gain kernel privileges in 2026 and terminate EDR processes at will.
Not an Isolated Case: BYOVD Goes Commodity
The EnCase incident is no outlier. In parallel SonicWall-related compromises, Huntress observed two additional drivers in play: threat actors have installed two legitimate Windows drivers—rwdrv.sys and hlpdrv.sys—in Bring Your Own Vulnerable Driver attacks, with the goal of evading or disabling security tools; Huntress confirmed detecting these drivers across multiple incidents linked to Akira ransomware. In one such case, the threat actor attempted to delete Volume Shadow Copies via WMI and clear event logs to limit visibility — the usual pairing of defense evasion and anti-forensics.
The trend keeps diversifying. In a later case, a malicious ad led to installation of ScreenConnect, after which a vulnerable Huawei audio driver was used to terminate security services. Across these investigations, Huntress observed repeated driver abuse, process-killing loops, and the use of trusted signed drivers to evade basic static detection. BYOVD has moved from niche trick to commodity technique — with forensic drivers being an unexpectedly attractive target precisely because they’re old, widely distributed, and underrepresented in detection rules.
Implications for Incident Responders
Several practical lessons emerge. First, correlating firewall telemetry with endpoint data was decisive in unraveling the intrusion: Huntress Managed SIEM ingested SonicWall telemetry from the victim environment, which proved critical in detecting and piecing together the intrusion timeline; analysis of VPN authentication logs revealed the threat actor successfully authenticated to the SonicWall SSLVPN from a malicious external IP address in February 2026. Second, analysts should consistently enforce Microsoft’s Vulnerable Driver Blocklist and maintain their own hash lists of known legacy drivers (EnCase EnPortv.sys, rwdrv.sys, hlpdrv.sys). Third, systematic monitoring of driver-load events (Sysmon Event ID 6, WDAC audit logs) belongs in every hunting playbook — especially for drivers relying on the pre-July-2015 timestamp exception.
The uncomfortable takeaway for the DFIR community itself: when a forensic tool becomes the attack weapon, responders also need to regularly scrutinize their own software supply chain and its signing history.
← Back to overview