Elastic Adds Automated BYOVD Defense for 800-Plus Windows Drivers

Key Takeaways

• The endpoint protection platform now covers more than 800 known vulnerable drivers using automatically generated detection rules.
• Threat researchers continuously monitor VirusTotal, LOLDrivers, and Microsoft’s Vulnerable Driver Block List to reduce delays between disclosure and protection.
• New capabilities include automated troubleshooting through the agent builder and extended endpoint support for Windows on ARM.

Bring Your Own Vulnerable Driver (BYOVD) attacks exploit a structural weakness in Windows security: code can be legitimately signed and still be dangerous. An attacker introduces a trusted driver with a known vulnerability, loads it into the operating system, and then uses its kernel privileges to manipulate memory, terminate protected processes, or interfere with endpoint defenses.

That kernel-level access can turn a security product into a spectator. Ransomware operators increasingly use BYOVD techniques before deploying their primary payload, borrowing an approach once associated more closely with state-backed groups and red teams. The driver is not necessarily malware; its vulnerability is the weapon.

To address the delay between disclosure and defense, Elastic Security Labs automates how its endpoint protection receives vulnerable-driver coverage. The threat research team monitors VirusTotal, the LOLDrivers catalog, and Microsoft’s Vulnerable Driver Block List, then generates and deploys detection rules from digital signatures and file characteristics. The process automatically filters out drivers already covered by existing rules.

The resulting library covers more than 800 known vulnerable drivers, demonstrating how quickly the vulnerable-driver inventory expands across the threat landscape. New disclosures do not need to wait for a conventional product release, and security teams do not need to alter settings or install separate content updates when the platform pushes new coverage.

Delay is a structural advantage for attackers. Once researchers publicly identify a vulnerable driver, offensive operators begin testing it immediately. If defensive coverage arrives with the next scheduled software release, that lag creates a usable window for exploitation. Decoupling detection content from the primary endpoint product’s release cycle narrows that gap considerably.

One example is Avast’s signed anti-rootkit driver, aswArPot.sys. Attackers found that the driver could be abused to terminate protected processes from the kernel. It later appeared in Cuba ransomware intrusions and GHOSTENGINE campaigns, illustrating how one trusted component can move between different threat operations. Threat actors actively reuse signed, vulnerable components because they already provide the required kernel access without needing custom exploit development.

Elastic Defend applies several defensive layers rather than relying solely on generated signatures. The system validates drivers against a blocklist before permitting them to load and flags a driver when it appears in an environment for the first time. The signature layer covers publicly reported drivers, while first-seen detection draws attention to unfamiliar components that have not yet entered public catalogs.

This approach reflects the broader principle in NIST SP 800-207: trust should not be treated as permanent simply because a component has already passed an identity or integrity check. For Windows drivers, a valid signature confirms provenance, but it does not establish that the code lacks exploitable flaws. Continuous evaluation gives defenders a concrete mechanism to identify trusted-but-vulnerable software.

Microsoft takes a related approach through its recommended vulnerable driver block rules. The automated detection system uses Microsoft’s Vulnerable Driver Block List as one input, alongside VirusTotal and LOLDrivers, because no individual source captures every disclosure. The researchers also publish generated rules in a public protections-artifacts repository, giving security teams visibility into the triggering driver, source record, and detection logic.

Deployment settings determine the effectiveness of these protections. The updated rules arrive through the platform's malware protection tier, which requires running in prevention mode rather than detection-only mode. Organizations should review exceptions, test policy behavior on representative Windows systems, and investigate first-seen driver alerts instead of treating every signed file as routine.

Adjacent capabilities broaden the recent release. The endpoint agent builder now includes an automatic troubleshooting skill for third-party antivirus conflicts, policy application failures, and related endpoint errors. It returns a likely root cause, suggested commands, and the diagnostic data analysts need to collect. The endpoint platform also adds support for Windows on ARM, allowing Snapdragon laptops, Copilot+ PCs, and ARM workstations to enroll under existing policies and provide telemetry consistent with x64 endpoints.

For enterprise security teams, the practical value lies in shortening the distance between public disclosure and operational detection. The known-driver library handles established threats, while blocklist validation and first-seen monitoring add coverage for less predictable cases. Attackers will continue bringing their own vulnerable drivers, but automated detection pipelines limit the window those drivers remain useful.