A valid digital signature does not make a vulnerable driver safe. In a bring-your-own-vulnerable-driver (BYOVD) attack, an intruder, usually already holding administrative or driver-loading privileges, abuses a legitimate driver to cross into the Windows kernel and interfere with security controls. Prophet Security’s November 4 detection guide recommends investigating the sequence around a driver load, rather than relying on a filename match alone.
Start with the driver and the surrounding timeline
Begin with a newly observed or unexpected driver. Record its path, hash, signer, version and loading time, then identify the account and process activity that preceded it. Compare those details with approved hardware, software and maintenance changes before treating a signed utility as malicious.
Microsoft documents Sysmon Event ID 6 as a source of driver-load hashes and signature information. Where the relevant auditing is enabled, Security Event 4697 adds service-installation context, including the installing account; service type 0x1 identifies a kernel driver. Confirm that these logs are collected before building a hunt around them.
Next, compare the load time with endpoint-agent health, service stops and changes in event volume. Prophet warns that an agent may remain running while its visibility is impaired. A sharp telemetry drop on a host that continues authenticating or making network connections deserves investigation, but scheduled upgrades and connectivity failures remain alternative explanations.
Use centrally retained endpoint, identity and network records to reconstruct what happened. An absence of fresh endpoint detections is weak reassurance when the suspected action could impair that sensor. Preserve available evidence and escalate suspicious combinations through the incident-response process rather than simply deleting the driver and closing the alert.
Distinguish attempted loads from blocked files
In the CodeIntegrity Operational log, Microsoft distinguishes event 3076 from 3077: the former records a file that an audit-mode policy would block; the latter records an enforced block. Neither event, on its own, establishes that a driver loaded successfully. Retain the policy context with the alert.
Check what prevention actually covers
Review the Microsoft vulnerable-driver blocklist, memory integrity and applicable App Control policies on the actual device fleet. Defaults vary by Windows version and enabled protections. Microsoft cautions that the list is incomplete and that blocking drivers can disrupt legitimate software; validate policy changes in audit mode before enforcing them.
The ASR rule for exploited vulnerable signed drivers complements those controls by preventing applications from writing vulnerable drivers to disk. It does not stop an already-present driver from loading. Keep driver updates, administrative-access review and investigation coverage alongside prevention.
