BYOVD EDR Evasion: Weaponizing Validly Signed Drivers to Blind Kernel Telemetry

Technical Overview & Threat Model#

Endpoint Detection and Response (EDR) platforms establish their defensive visibility within the operating system kernel. By registering callbacks with the kernel—such as process creation monitors, thread injection listeners, and object access interceptors—security sensors observe adversary actions before user-space code executes. To neutralize this telemetry, modern ransomware cartels and advanced persistent threat (APT) groups frequently deploy a technique known as Bring Your Own Vulnerable Driver (BYOVD) (MITRE ATT&CK T1068 and T1562.001).

Rather than burning expensive zero-day kernel exploits, attackers drop legitimate, validly code-signed third-party device drivers (such as legacy motherboard utilities, hardware diagnostic tools, or anti-cheat engines) that contain known memory management vulnerabilities.

sequenceDiagram
    autonumber
    participant Attacker as Adversary (Admin / Elevated Context)
    participant SCM as Service Control Manager (advapi32)
    participant VulnDriver as Legitimate Signed Driver (Kernel Space)
    participant EDR as EDR Kernel Sensor (Callbacks)
    participant TargetProcess as Target Process / LSASS

    Attacker->>SCM: Create & Start Service Loading Vulnerable Driver
    SCM->>VulnDriver: Load Driver into Ring 0 (Signature Validated by Driver Signature Enforcement)
    Attacker->>VulnDriver: Issue DeviceIoControl() with Arbitrary Kernel Write Primitive
    VulnDriver->>EDR: Overwrite EDR Notification Array (e.g., PspCreateProcessNotifyRoutine)
    Note over VulnDriver,EDR: EDR Callback Pointer Zeroed / Patched with RET
    Attacker->>TargetProcess: Execute Credential Dumping / Memory Injection Unhindered
    Note over TargetProcess,EDR: EDR Blinded: Zero Process Creation Telemetry Emitted

The attack model exploits an asymmetry in kernel trust:

Driver Signature Enforcement (DSE) Bypass: 64-bit operating systems require kernel-mode drivers to carry a valid cryptographic signature from a recognized Certificate Authority or the vendor. Attackers leverage drivers signed years prior that operating systems continue to trust because the signing certificate has not been revoked or blocked by hypervisor policies.
Arbitrary Ring-0 Read/Write Primitive: The dropped driver exposes an insecure Input/Output Control (IOCTL) handler that exposes physical memory mapping (ZwMapViewOfSection) or direct port I/O without validating the caller's privileges.
Telemetry Blinding: With arbitrary read/write capability, the attacker scans kernel memory for the array of active EDR notification routines, unhooks them by replacing the callback addresses with no-op routines (RET), and terminates protected user-space agent processes without raising an alert.

Technical Walkthrough: Anatomy of an Insecure IOCTL Handler#

The vulnerability in legacy signed drivers typically stems from exposing direct physical memory access or control register manipulation directly to user-mode callers without sanity checking:

flowchart TD
    subgraph UserSpace [User-Space Execution]
        Payload[Attacker Process: BYOVD Loader]
        DeviceHandle[CreateFile: Open Handle to Device]
        IOCTLCall[DeviceIoControl: Write Kernel Memory]
    end

    subgraph KernelBoundary [Kernel I/O Manager]
        DispatchPass[Driver Dispatch Routine]
        InputBuffer[Attacker-Supplied Virtual / Physical Address]
    end

    subgraph KernelSpace [Ring-0 Execution Engine]
        MemoryMap[MmMapIoSpace or Direct Pointer Dereference]
        CallbackArray[PspCreateProcessNotifyRoutine Array]
        TargetCallback[EDR Hook Entry Zeroed or Patched with RET]
    end

    Payload --> DeviceHandle
    DeviceHandle --> IOCTLCall
    IOCTLCall --> DispatchPass
    DispatchPass --> InputBuffer
    InputBuffer --> MemoryMap
    MemoryMap --> CallbackArray
    CallbackArray --> TargetCallback

The illustrative pseudo-C implementation below models the vulnerable driver logic that attackers look for in signed legacy binaries:

/*
 * Illustrative Example:
 * Demonstrates an insecure IOCTL dispatcher pattern commonly weaponized in BYOVD campaigns.
 * In production drivers, kernel memory mapping must enforce strict caller access controls.
 */

#define IOCTL_MAP_PHYSICAL_MEMORY CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)

struct KERNEL_WRITE_REQUEST {
    ULONG_PTR TargetAddress;
    ULONG BufferSize;
    UCHAR Data[64];
};

NTSTATUS InsecureDispatchIoControl(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
    ULONG controlCode = stack->Parameters.DeviceIoControl.IoControlCode;
    NTSTATUS status = STATUS_SUCCESS;

    if (controlCode == IOCTL_MAP_PHYSICAL_MEMORY) {
        struct KERNEL_WRITE_REQUEST *request = (struct KERNEL_WRITE_REQUEST *)Irp->AssociatedIrp.SystemBuffer;
        
        // VULNERABILITY: Arbitrary memory write without validating destination address
        if (request != NULL && request->TargetAddress > (ULONG_PTR)0x80000000) {
            void *destination = (void *)request->TargetAddress;
            RtlCopyMemory(destination, request->Data, request->BufferSize);
            Irp->IoStatus.Information = request->BufferSize;
        } else {
            status = STATUS_INVALID_PARAMETER;
        }
    }

    Irp->IoStatus.Status = status;
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return status;
}

Once loaded, an adversary locates the PspCreateProcessNotifyRoutine table, iterates through the registered pointers until locating the address owned by the EDR's driver image, and zeroes out the entry or patches the target function's entry point with 0xC3 (RET).

Detection Engineering: Sigma & YARA Artifacts#

Detecting BYOVD requires shifting focus from user-mode telemetry (which may be terminated) to driver load events, file hashes, and kernel integrity telemetry.

1. Sigma Detection Rule: Detecting Suspicious Driver Load Operations#

The following Sigma rule detects driver load events originating from user directories or non-standard paths using Sysmon Event ID 6:

YAML

title: Suspicious Kernel Driver Load from Non-System Directory
id: 5f98e72c-29b1-41b4-9274-1a3b934789fa
status: experimental
description: Detects a driver loading from user-writable directories, a common staging pattern in BYOVD attacks.

references:
  - https://attack.mitre.org/techniques/T1068/
  - https://attack.mitre.org/techniques/T1562/001/
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 6
    ImageLoaded|contains:
      - '\Users\'
      - '\Temp\'
      - '\AppData\'
      - '\ProgramData\'
      - '\PerfLogs\'
  filter_system:
    ImageLoaded|startswith: 'C:\Windows\System32\drivers\'
  condition: selection and not filter_system
falsepositives:
  - Specialized diagnostic tools running from custom directories
level: high
tags:
  - attack.defense_evasion
  - attack.privilege_escalation
  - attack.t1068
  - attack.t1562.001

2. YARA Rule: Scanning for Known Vulnerable IOCTL Signatures#

Security teams can scan disk images and staging directories for vulnerable driver samples utilizing known vulnerable dispatch strings and dangerous API imports:

YARA

rule Suspicious_Vulnerable_Driver_Artifact
{
    meta:
        description = "Identifies driver PE binaries combining dangerous physical memory mapping imports with unvalidated IOCTL routines"
        author = "blogs.redwan.work Research"
        threat_model = "BYOVD EDR Telemetry Blinding"
        reference = "https://cisa.gov/known-exploited-vulnerabilities-catalog"
    strings:
        $api_map = "MmMapIoSpace" ascii fullword
        $api_phys = "ZwOpenSection" ascii fullword
        $device_path = "\\Device\\" wide
        $dos_path = "\\DosDevices\\" wide
    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        $api_map and
        $api_phys and
        ($device_path or $dos_path)
}

Defensive Engineering & Verification Checklist#

Preventing BYOVD requires architectural defenses that operate before driver execution:

Enforce Hypervisor-Protected Code Integrity (HVCI): HVCI executes driver validation within an isolated virtual trust environment (VTL1), preventing unsigned code execution and blocking memory pages from being simultaneously writable and executable (W^X).
Activate Microsoft Vulnerable Driver Blocklist: Ensure Windows Defender Application Control (WDAC) or endpoint policies enforce the synchronized driver blocklist, denying load requests for drivers with known CVEs.
Monitor Driver Load Telemetry: Ingest Sysmon Event ID 6 (Driver Load) and Windows System Event 7045 (A new service was installed in the system) into central SIEM platforms to alert on new driver registrations in real time.

POWERSHELL

## Verify HVCI and Memory Integrity Status via PowerShell
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | 
Select-Object SecurityServicesConfigured, SecurityServicesRunning

## Expected result when protected:
## SecurityServicesRunning contains 2 (Hypervisor-Enforced Code Integrity active)