The idea that old software fades quietly into history feels comforting. This month, that belief proved dangerously wrong.
Security researchers revealed that threat actors are abusing a long retired Windows kernel driver from a forensic tool to shut down modern security software. The driver’s digital certificate was revoked more than a decade ago. Yet Windows still loads it, giving attackers a powerful way to blind defenses before anyone notices.
How attackers slipped in through VPN access
The intrusion began the way many real world breaches do. Attackers used stolen SonicWall SSL VPN credentials to gain access to a corporate network earlier this month.
The VPN account did not have multifactor authentication enabled. That single gap opened the door.
Once inside, the attackers moved fast. Instead of immediately deploying ransomware or stealing data, they focused on removing obstacles. Their goal was to disable endpoint detection and response tools before alarms could sound.
This early move to silence security software changed the entire balance of the attack.
An old forensic tool becomes a new weapon
To do that, the attackers turned to an unlikely tool. They weaponized a Windows kernel driver from EnCase, a well known forensic software suite first released in 1998.
EnCase was built to help investigators analyze disks and memory. Its driver runs in the Windows kernel, the most privileged layer of the operating system. That level of access is exactly what attackers want.
The driver’s signing certificate expired in 2010 and was later revoked. By modern standards, it should not be trusted. Yet Windows still allows it to load.
That decision, made years ago to preserve compatibility, gave attackers a clean path to the kernel.
Why Windows still loads revoked drivers
Windows includes a protection called Driver Signature Enforcement. Introduced with Windows Vista, it requires kernel drivers to be signed by trusted certificate authorities.
But the system has blind spots.
Windows does not check certificate revocation lists when loading drivers. The main reason is practical. Drivers load early during boot, before network services are ready. Checking revocation lists would slow startup and sometimes fail.
There is another issue tied to history. With Windows 10, Microsoft required new kernel drivers to be signed through its Hardware Dev Center. However, to avoid breaking older software, drivers signed before July 29, 2015 are still allowed if their certificates chain to an approved authority.
That creates a lasting loophole.
Expired or revoked certificates from before mid 2015 can still unlock kernel level access.
For attackers, these drivers are gold.
The rise of bring your own vulnerable driver attacks
This tactic is known as bring your own vulnerable driver, often shortened to BYOVD.
In a BYOVD attack, threat actors bring a legitimate but flawed driver into the environment. Because the driver is trusted by the operating system, it can perform powerful actions. Those actions often include terminating security processes.
These tools are commonly called EDR killers.
BYOVD attacks have surged in ransomware campaigns over the past two years. They allow attackers to disable protection silently, then encrypt systems or steal data with little resistance.
Older drivers are especially valuable because attackers do not need to submit them to Microsoft for approval. Some groups even go further, using open source tools to fake timestamps on newer malicious drivers so they appear older than they really are.
Inside the EDR killer used in this attack
In this case, the attackers deployed a 64 bit Windows executable disguised as a firmware update utility.
Inside the file was the EnCase kernel driver.
The malware used an unusual trick to avoid analysis. Instead of encrypting the embedded driver, it encoded each byte as an English word using a custom substitution system. To static analysis tools, the payload looked like harmless text scattered through the file.
This helped the malware blend in.
Once executed, the tool attempted to terminate dozens of security processes. Researchers identified 59 targeted processes linked to major vendors, including Microsoft, CrowdStrike, SentinelOne, Kaspersky, Sophos, and ESET.
One vendor was notably missing from the list.
How the attack was detected and stopped
The intrusion did not end in ransomware. It was disrupted in time.
Detection came when the attacker deployed the EDR killer on an endpoint. That action triggered alerts, allowing responders to trace activity backward through VPN logs and endpoint telemetry.
This investigation exposed the full attack chain, from the stolen VPN credentials to the attempted shutdown of security software.
Stopping the EDR killer before ransomware deployment likely saved the victim from a major outage.
The incident also gave defenders rare insight into how these tools operate in the wild.
Why fixing this problem is so hard
There is no simple switch to turn off BYOVD attacks.
Blocking legitimate drivers outright can break systems or cause crashes. Many organizations still rely on legacy software that depends on older drivers.
Possible improvements exist, but each carries risk.
Narrowing the pre 2015 signing exception could break older applications.
Checking revocation lists after boot could add protection but may miss early attacks.
Cached certificate checks could help, but attackers might still find ways around them.
This is the cost of backward compatibility. Decisions made to keep old software running can haunt modern security.
What organizations can do right now
While there is no perfect fix, defenders are not helpless.
Organizations can reduce risk by enforcing basic access controls and hardening Windows defenses.
Key steps include:
Enforcing multifactor authentication on all VPN accounts.
Reviewing VPN logs for unusual login patterns.
Enabling Microsoft’s vulnerable driver block rules through Windows Defender Application Control.
Turning on Hypervisor protected Code Integrity to enforce the Windows vulnerable driver blocklist.
These measures do not eliminate the threat, but they raise the cost for attackers.
They also turn silent failures into visible events.
Old code never really dies. It waits. This incident is a reminder that security is shaped as much by past design choices as by present threats. The question now is how long defenders will tolerate loopholes that attackers already know by heart. What do you think should change first, compatibility or security? Share this story and start the conversation.
