Elastic Defend now covers 800+ vulnerable drivers, with automated troubleshooting and ARM support

Attackers reaching for kernel access on a Windows machine bring a driver Microsoft already trusts. It is signed, it loads, and it carries a known flaw. That flaw gives them enough room to tamper with memory or disable the security software watching the host.

Once an attacker holds that level of access, the tools on the machine stop reliably protecting it. Ransomware crews run the technique as a step before they deploy a payload, a move that began as tradecraft mostly reserved for advanced state actors and red teams.

Where the rules come from

“To close this gap, Elastic Security Labs Threat Command, Elastic’s security research team now continuously monitors public vulnerable driver disclosure sources, including VirusTotal, the LOLDrivers catalog, and Microsoft’s Vulnerable Driver Block List, and automatically generates and instantly deploys detection rules,” Elastic Security Labs explained.

No single source catches everything. The system checks all three, filters out drivers Elastic already covers, and builds rules from the driver’s digital signature and file characteristics.

vulnerable driver detection

Automated YARA rule generation workflow (Source: Elastic Security Labs)

Elastic Security Labs has published vulnerable driver coverage for years. This automated process started in 2023 with 65 rules.

The library covers more than 800 known vulnerable drivers, and the number keeps growing.

The delay is the technique

A vulnerable driver becomes public knowledge and attackers know about it the same day. Vendor coverage can take an entire product release to arrive. That window is what BYOVD depends on.

Elastic decoupled this coverage from its release cycle. A driver flagged in one of the three feeds becomes a driver Elastic Defend recognizes, with no update or setting change on the customer side.

One driver, two campaigns

Avast’s signed anti-rootkit driver, aswArPot.sys, gave attackers a way to terminate protected processes from the kernel. It surfaced in Cuba ransomware intrusions and in GHOSTENGINE campaigns.

What a defender has to check

The rules ship through Elastic Security’s malware protection. Elastic recommends enabling it and setting it to Prevent.

Signature coverage is one layer. Elastic Defend validates drivers against a blocklist before they are allowed to load, and it flags a driver the moment it appears in an environment for the first time. A driver built to slip past one of those layers still has to clear the others.

Every generated rule is public. The elastic/protections-artifacts repository carries them alongside the rest of the company’s detection content, so a team can see which driver triggered a rule, which source flagged it, and the detection logic itself.

Two other changes

Elastic Agent Builder carries automatic troubleshooting as a skill. It covers third-party antivirus conflicts, policy application failures, and the errors that send analysts into logs for hours, and it returns a root cause, the commands to run, and the data to collect. The existing automatic troubleshooting feature stays in place.

Elastic Defend also runs on Windows on ARM. Snapdragon laptops, Copilot+ PCs, and ARM workstations enroll under existing policies and report the same telemetry as x64 endpoints, and devices added to a fleet enroll automatically.

Signature rules cover the drivers someone has already reported. The layer that flags a driver on its first appearance covers the ones nobody has reported yet.

Don't miss