BYOVD in 2026: the signed-driver loophole powering EDR bypass at scale

Last updated: 21 February 2026 (Europe/London)

1. Executive Summary

Bring Your Own Vulnerable Driver (BYOVD) is a post-compromise technique where attackers load a legitimately signed (but vulnerable) kernel driver and then abuse it to gain ring-0 capabilities—most often to disable EDR/AV, tamper with telemetry, or escalate privileges. Modern ransomware intrusions have repeatedly adopted BYOVD because it can neutralise endpoint controls even after an adversary has obtained local administrator rights, as shown in public reporting on BlackByte, AvosLocker, and dedicated “EDR killer” tooling such as AuKill and Terminator. (SOPHOS)

From a defender’s perspective, BYOVD risk is concentrated around a predictable set of “popular” drivers (often bundled with OEM utilities, performance tools, or legacy security products), plus a long tail of newly discovered signed drivers that attackers can commoditise quickly. Microsoft’s vulnerable driver blocklist and the Defender ASR rule “Block abuse of exploited vulnerable signed drivers” are currently the two most practical, high-leverage controls to reduce BYOVD exposure at scale. (Microsoft Learn)

2. Contextual Background

2.1 Nature of the threat

At its core, BYOVD is about abusing trusted code-signing to get kernel-mode access without needing to ship an unsigned rootkit. Attackers typically:

• obtain a foothold and elevate privileges,
• introduce a vulnerable signed driver (or reuse one already present),
• use exposed IOCTL functionality or known flaws to perform privileged actions (terminate protected processes, manipulate kernel callbacks, etc.). (SOPHOS)

Representative BYOVD-relevant CVEs (widely referenced in defensive guidance and intrusion reporting) include:

• CVE-2021-21551 (Dell dbutil_2_3.sys) — Dell Advisory for CVE-2021-21551 and NVD. (Dell)
• CVE-2018-19320 (GIGABYTE gdrv.sys / APP Center) — GIGABYTE Security Advisory for CVE-2018-19320 and NVD. (GIGABYTE)
• CVE-2019-16098 (MSI Afterburner RTCore64.sys/RTCore32.sys) — No dedicated MSI security bulletin was located in open sources; the widely cited details are available via third-party advisory databases. See GitHub Advisory for CVE-2019-16098 and NVD. (GitHub)
• CVE-2024-51324 (Baidu Antivirus BdApiUtil driver) — Public vendor guidance is limited; see third-party reporting and vulnerability databases. See GitHub Advisory for CVE-2024-51324 and NVD. (GitHub)

2.2 Threat-actor attribution (where evidenced)

BYOVD is a technique used by both crimeware and state-backed actors:

• Lazarus (North Korea) — ESET documented abuse of CVE-2021-21551 in campaigns targeting an aerospace employee in the Netherlands and a political journalist in Belgium, describing it as the “first recorded abuse” of that Dell driver vulnerability in their reporting. Confidence: Confirmed (direct vendor reporting). (ESET)
• BlackByte ransomware — Sophos reported BlackByte abusing RTCore64.sys to bypass security products (kernel callback removal and related tampering). Confidence: Confirmed (incident analysis). (SOPHOS)
• AvosLocker ransomware — Trend Micro reported AvosLocker using an Avast anti-rootkit driver (aswArPot.sys) to disable defence solutions. Confidence: Confirmed. (www.trendmicro.com)
• Broader intrusion ecosystem — Google Threat Intelligence (Mandiant) notes BYOVD use across multiple actor sets (including both financially motivated and espionage operators), highlighting how generally useful the technique is once an actor is inside an environment. Confidence: Likely (high-quality synthesis, but not a single-actor attribution). (Google Cloud)

2.3 Sector and geographic targeting

Publicly documented BYOVD usage spans:

• Enterprise ransomware intrusions (multi-sector by design, as ransomware affiliates target whichever organisations they can operationalise).
• Targeted espionage where persistence and stealth are priorities (e.g., Lazarus campaigns observed in Europe). (SOPHOS)

3. Technical Analysis

3.1 How BYOVD works in practice (mapped to MITRE ATT&CK)

BYOVD typically appears mid-to-late in an intrusion, when attackers want to remove friction from endpoint controls.

Common behaviours and ATT&CK mappings:

• Driver installation and service creation (kernel driver service): T1543.003
• Kernel-level privilege gain / ring-0 primitives via a vulnerable driver: T1068
• Defence evasion through exploiting a legitimate but vulnerable component: T1211
• Disabling security tooling (terminating protected processes, sabotaging EDR): T1562.001

Concrete examples from public reporting:

• BlackByte: Sophos describes abuse of RTCore64.sys (CVE-2019-16098) to remove kernel notify routines used by security products. (SOPHOS)
• AuKill: Sophos reports AuKill abusing an outdated Microsoft Process Explorer driver and explicitly categorises this as BYOVD, including the presence of PROCEXP.SYS and the legitimate PROCEXP152.sys in C:\Windows\System32\drivers. (SOPHOS)
• AvosLocker: Trend Micro reports use of aswArPot.sys (Avast anti-rootkit) to disable security products. (www.trendmicro.com)
• Terminator (EDR killer tooling): Sophos and CrowdStrike-linked reporting associates Terminator with vulnerable Zemana drivers (zamguard64.sys / zam64.sys). (SOPHOS)

3.2 Exploitation status and PoC availability

• CVE-2021-21551 (Dell dbutil_2_3.sys) has been widely researched by multiple vendors (e.g., CrowdStrike, SentinelOne) and is consistently treated as high-risk because it is a signed OEM driver and has appeared in real intrusions. (CrowdStrike)
• CVE-2018-19320 (GIGABYTE gdrv.sys) has been highlighted in CISA catalogue update reporting as added to the Known Exploited Vulnerabilities list in 2022 (as reported by SecurityWeek).
• Commodity BYOVD is increasingly “tool-driven” (AuKill, Terminator variants, and other EDR killers), reducing the skill barrier for affiliates. (SOPHOS)

4. Impact Assessment

4.1 Severity and scope

BYOVD’s impact is disproportionately high because kernel-mode access can invalidate assumptions behind many endpoint controls (tamper protection notwithstanding). The most common operational outcomes are:

• EDR/AV neutralisation (process termination, callback removal, telemetry suppression) prior to ransomware deployment. (SOPHOS)
• Privilege escalation to SYSTEM/kernel for lateral movement staging and credential access (depending on the driver and environment). (Dell)

Risk scoring signals (noting that EPSS is time-variant and represents a 30-day exploitation probability):

• CVE-2021-21551 — CVSS 8.8 in Dell advisory; EPSS reported in GitHub Advisory DB as 62.654%. (Dell)
• CVE-2019-16098 — NVD CVSS 7.8; EPSS in GitHub Advisory DB reported as 77.756%. (NVD)
• CVE-2018-19320 — EPSS in GitHub Advisory DB reported as 36.499%. (GitHub)
• CVE-2024-51324 — EPSS in GitHub Advisory DB reported as 0.04% (low overall, but still relevant given observed criminal use). (GitHub)

4.2 Victim profile

Victims skew towards Windows estates where:

• local admin is attainable (phishing + token theft, RMM misuse, or other privilege escalation),
• driver install controls are weak,
• vulnerable OEM/performance/security utilities are present or can be introduced quietly. (SOPHOS)

5. Indicators of Compromise (IOCs)

Note: BYOVD is a technique, so IOCs are often driver filenames, service artefacts, and known tool hashes from specific reports rather than a single universal indicator.

5.2 Detection guidance

Practical detection usually hinges on driver load telemetry and service creation:

• Enable / collect Sysmon Event ID 6 (Driver loaded) to record driver loads with signature and hashes. (Microsoft Learn)
• Use curated detections such as Sigma rules that key off known vulnerable driver names (example rule: “Vulnerable Driver Load By Name”). (Detection)
• Integrate LOLDrivers datasets and detections (YARA/Sigma enrichment) into hunting and CI/CD rule deployment workflows. (GitHub)

6. Incident Response Guidance

6.1 Containment, eradication, recovery

• Assume security tooling may be blinded: validate host integrity via out-of-band sources (network telemetry, hypervisor logs, EDR back-end “last seen” gaps). (SOPHOS)
• Isolate suspected hosts rapidly (especially if BYOVD appears in a ransomware kill-chain).
• Remove or remediate the driver source (uninstall vulnerable utility, apply vendor patch, block driver load) before restoring normal operations. (Microsoft Learn)
• Rebuild trust: if kernel tampering is suspected, prioritise re-imaging over “cleaning”, particularly for high-value endpoints and servers.

6.2 Forensic artefacts to collect

• Driver load events (Sysmon EID 6; Code Integrity logs where applicable). (Microsoft Learn)
• SCM activity: creation of new services of type “kernel driver” (Windows event logs / EDR telemetry).
• File system artefacts: unexpected .sys files in System32\drivers or user-writable directories (Sophos notes attacker placement patterns in multiple BYOVD cases). (SOPHOS)
• Memory captures (where feasible) to validate callback tables / kernel structures if you have specialist capability.

6.3 Lessons learned

• BYOVD is rarely the first step—treat it as a signal of late-stage intrusion maturity and triage accordingly.

7. Threat Intelligence Contextualisation

7.1 Similar incidents and evolution

BYOVD has moved from niche tradecraft into repeatable playbooks:

• Ransomware crews increasingly standardise around a small “driver kit” (e.g., Talos describes BlackByte dropping multiple vulnerable drivers as part of its usual BYOVD chain). (Cisco Talos Blog)
• Tooling ecosystems (AuKill / Terminator / Backstab-like approaches) continue to iterate, targeting multiple EDR vendors and operationalising driver abuse as a service. (SOPHOS)

7.2 Full MITRE ATT&CK mapping (BYOVD-centric)

8. Mitigation Recommendations

8.1 High-impact hardening steps

1. Enforce Microsoft’s vulnerable driver blocklist
   • Microsoft states the vulnerable driver blocklist is enabled by default since Windows 11 2022 update and enforced under HVCI/Smart App Control/S mode scenarios; it is updated with new Windows releases and also available via optional Windows Update, with more comprehensive options via App Control for Business. (Microsoft Learn)
2. Enable the ASR rule: “Block abuse of exploited vulnerable signed drivers”
   • Microsoft lists this as a standard protection ASR rule and provides the rule GUID (56a863a9-875e-4185-98a7-b882c64b5ce5) in its ASR reference documentation. (Microsoft Learn)
3. Adopt an allowlist posture for drivers where feasible
   • Microsoft explicitly recommends an “explicit allowlist approach” and positions the blocklist as a critical disruption tool when allowlisting is not feasible. (Microsoft Learn)
4. Reduce driver installation opportunities
   • Tighten local admin exposure, remove unnecessary OEM utilities/performance tooling, and enforce least privilege (Sophos explicitly notes BYOVD tooling typically requires administrative privileges to operate). (SOPHOS)
5. Strengthen tamper protection
   • Ensure EDR tamper protection is enabled and validated; multiple vendors highlight tamper protection as a key control when adversaries attempt to disable endpoint agents. (SOPHOS)

8.2 Patch management advice (prioritise by exploitation likelihood and exposure)

A practical prioritisation model is:

• Patch / remove drivers with high exploitation probability and broad footprint first (high CVSS + high EPSS + common deployment), then expand outward.

Suggested priority (using publicly reported CVSS/EPSS signals and observed abuse):

1. CVE-2019-16098 (RTCore64.sys) — EPSS reported as 77.756%; repeatedly seen in ransomware EDR bypass reporting. (GitHub)
2. CVE-2021-21551 (dbutil_2_3.sys) — Dell CVSS 8.8; EPSS reported as 62.654%; used in APT campaigns per ESET. (Dell)
3. CVE-2018-19320 (gdrv.sys) — EPSS reported as 36.499%; included in CISA KEV update reporting. (GitHub)
4. Legacy security and utility drivers (e.g., aswArPot.sys, Zemana drivers, Process Explorer driver abuse paths) — may not map cleanly to a single CVE in every report, but repeatedly show up in “EDR killer” operations; focus on blocklisting + removal of outdated components. (www.trendmicro.com)

9. Historical Context & Related Vulnerabilities

9.1 Previously exploited vulnerabilities in this space

• OEM and utility drivers remain attractive because they are signed, widely distributed, and often persist for years on endpoints (Dell’s dbutil driver has been analysed across multiple vendors and shown in both crimeware and APT contexts). (CrowdStrike)
• Defender-focused guidance has converged on blocklisting, ASR prevention of driver drops, and driver allowlisting as durable mitigations as BYOVD continues to recur. (Microsoft Learn)

9.2 Related coverage and resources

• Curated driver corpora like LOLDrivers exist specifically to track drivers used by adversaries and support defensive detection. (GitHub)

10. Future Outlook

10.1 Emerging trends

• Tool commoditisation will continue: AuKill/Terminator-style “EDR killers” demonstrate repeatable patterns (drop/load vulnerable driver → terminate/impair security → deploy payload). (SOPHOS)
• Driver diversity will expand: defenders should expect attackers to rotate into less well-known but still-signed drivers as blocklists mature, particularly from consumer software ecosystems with long update tails. (Check Point Research)

10.2 Likely shifts in targeting and tooling

• Where Microsoft’s blocklist/ASR adoption is strong, attackers may prioritise:
  • abusing already-installed vulnerable drivers,
  • targeting environments with weaker application control, or
  • leaning harder on alternative kernel-evasion routes (e.g., stolen certificates, supply chain). (Microsoft Learn)

11. Further Reading

Vendor and platform mitigations

• Microsoft recommended driver block rules (vulnerable driver blocklist, update cadence, and ASR recommendation) (Microsoft Learn)
• Microsoft ASR rules reference (includes “Block abuse of exploited vulnerable signed drivers”) (Microsoft Learn)

Threat research and case studies

• Sophos: BlackByte EDR bypass via RTCore64.sys (SOPHOS)
• Sophos: AuKill abuses Process Explorer driver (SOPHOS)
• Trend Micro: AvosLocker abuses aswArPot.sys to disable AV (www.trendmicro.com)
• ESET: Lazarus campaigns documenting DBUtil abuse (welivesecurity.com)
• Cisco Talos: Exploring vulnerable Windows drivers (BlackByte multi-driver BYOVD chain) (Cisco Talos Blog)
• Google Threat Intelligence: LIGHTSHOW/LIGHTSHIFT mentions BYOVD across actor sets (Google Cloud)

Detection content and datasets

• LOLDrivers (GitHub repository) (GitHub)
• SigmaHQ: Vulnerable Driver Load By Name rule (GitHub)
• Sysmon documentation (Driver loaded Event ID 6) (Microsoft Learn)