How do you detect BYOVD attacks?

Detect BYOVD at driver load. Match Sysmon Event 6 hashes and file names against the LOLDrivers dataset, and alert on new kernel-mode services (System Event 7045, Security 4697) installed from user-writable paths such as Temp or ProgramData. Pair this with a follow-on rule that fires when security-product processes terminate soon after a driver load. For prevention, enable the Microsoft vulnerable driver blocklist through HVCI or WDAC and review its audit events, because hash lists alone age quickly.

Detecting BYOVD: Vulnerable Driver Loading and EDR Killers

In a bring-your-own-vulnerable-driver attack the adversary drops a legitimately signed but exploitable kernel driver, loads it as a service, and abuses its read/write primitives to gain kernel access. The usual goal is terminating EDR and antivirus processes before encryption begins. Examples seen in the wild include the MSI Afterburner driver (CVE-2019-16098) and Dell’s dbutil_2_3.sys (CVE-2021-21551).

Signals at a Glance

Signal	Where	ATT&CK
Driver load whose hash or name appears in the LOLDrivers list	Sysmon 6, EDR driver telemetry	T1068
New kernel-mode service installed (Type 1) from a user-writable path	System 7045, Security 4697	T1543.003
Driver file written to Temp, ProgramData or a user profile, then loaded	Sysmon 11 and 6	T1068
Security product processes terminated shortly after a driver load	EDR tamper alerts, Sysmon 5	T1562.001
Driver loads blocked or audited by HVCI or WDAC policy	CodeIntegrity 3076/3077	T1562.001

Driver Load and Install Events

Every BYOVD attack must load a driver, and Windows logs that. Sysmon Event 6 records the driver path, hashes and signature status; the Service Control Manager writes Event 7045 for a new service. Match hashes against the LOLDrivers dataset, loaded as a lookup:

index=sysmon EventCode=6
| rex field=Hashes "SHA256=(?<sha256>[A-Fa-f0-9]{64})"
| lookup loldrivers_hashes sha256 OUTPUT driver_name, category
| where isnotnull(driver_name)
| stats count min(_time) as first_seen by host, ImageLoaded, sha256, driver_name, Signed, SignatureStatus
| sort - first_seen
`comment("tune/validate: loldrivers_hashes is built from the LOLDrivers feed; refresh it regularly")`

Hash lists age quickly because attackers rebuild or re-sign drivers. Add behavioural coverage that does not depend on knowing the driver in advance:

title: Kernel Driver Service Installed from User-Writable Path
logsource:
  product: windows
  service: system
detection:
  selection:
    Provider_Name: 'Service Control Manager'
    EventID: 7045
    ServiceType: 'kernel mode driver'
  suspicious_path:
    ImagePath|contains:
      - '\Users\'
      - '\ProgramData\'
      - '\Temp\'
      - '\AppData\'
  condition: selection and suspicious_path
level: high
# tune/validate: legitimate installers sometimes stage drivers in Temp briefly.

Prevention and Follow-On

Enable the Microsoft vulnerable driver blocklist, through HVCI or a WDAC policy, and watch the CodeIntegrity audit events to see what it would have blocked.
Alert when a security product’s process or service stops within minutes of any new driver load; the pairing is the BYOVD signature.
Treat repeated load of an unusual driver name across several hosts as an operator moving laterally, not as software rollout.
Inventory legitimate third-party drivers so that net-new names stand out; most estates have a few dozen.
Name matching on rare, vendor-specific drivers (for example RTCore64.sys) is a useful hunt when hashes do not match.

Vetted sources

Use the LOLDrivers project (hashes, names and detection rules), the Microsoft recommended driver block rules, the SigmaHQ driver-load and service-install rules, Elastic’s vulnerable driver detections and MITRE ATT&CK T1068. Baseline your own environment — hardware vendors, anti-cheat and virtualisation software all load signed kernel drivers.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Driver Load and Install Events

Prevention and Follow-On

Build Detections That Fire

Defense Evasion Detection

Detection Hub

Disabling Defender Detection

EDR Unhooking Detection