Catch a malicious kernel driver: BYOVD defense on your own machine

Before you can spot an odd driver, look at a normal machine. In an elevated PowerShell, list the kernel drivers and where each one lives on disk.

> Get-CimInstance Win32_SystemDriver | Select-Object Name,State,PathName | Sort-Object PathName

Almost every path is under C:\Windows\System32\drivers. Burn that into your memory — it is the “normal” that makes the abnormal obvious later. A kernel driver running from a user folder, ProgramData or a temp directory is the thing you are learning to catch.

Why this matters. Detection is just “this differs from normal.” You cannot define abnormal until you have actually looked at normal once, on your own box.

Windows does not log driver loads clearly out of the box. Sysmon does, as Event ID 6. Install it with a config, from the folder you unzipped it into.

> .\Sysmon64.exe -accepteula -i sysmonconfig.xml

Open the config in a text editor and find the DriverLoad section — that is the rule group feeding Event ID 6. Read it before you trust it; you are installing a thing that watches your kernel, so you should know what it keeps and what it drops.

Why this matters. No log, no detection. This one event — every driver that loads, with its path, hash and signature — is the single most useful thing you can add for catching BYOVD.

Reboot, or just wait a minute, then pull the most recent driver-load events and read the fields that matter.

> Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 200 | Where-Object Id -eq 6 | Select-Object -First 10 TimeCreated,Message | Format-List

In each message, find ImageLoaded (the driver file), Signed, Signature (who signed it) and SignatureStatus. On a clean machine every one is signed and valid. The fields you will care about on a bad day are Signed: false, an unexpected signer, or an ImageLoaded path outside System32.

The attacker’s view. Their driver is often validly signed — that is the whole trick of BYOVD, it is a real vendor’s driver with a real certificate and an old hole. So the signature alone will not always save you; the path and the known-bad hash will.

The defender’s move. You now log signer, hash and path for every load. That is exactly what the next two controls check against automatically.

Memory Integrity (HVCI) walls the kernel off behind the hypervisor, so a loaded driver cannot tamper with protected code. Check whether it is actually running — not just switched on in the UI.

> (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

A 2 in the list means HVCI is running. If it is missing, turn it on: Windows Security → Device security → Core isolation → Memory integrity, then reboot and re-run the command. If it refuses, an old driver is incompatible — Windows will name it, and that driver is itself worth a second look.

Why this matters. HVCI is the structural defence: even a driver that loads cannot rewrite kernel code it should not. It is the floor the other two controls stand on.

Microsoft ships a blocklist of the exact drivers used in real BYOVD attacks, and refuses to load them. On current Windows it is often already on; confirm it, and turn it on if not.

> Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name VulnerableDriverBlocklistEnable

A value of 1 means it is on. If the property is missing or 0, turn it on in Windows Security → Device security → Core isolation → Microsoft Vulnerable Driver Blocklist, then reboot. This is the one control aimed squarely at BYOVD: the known-bad drivers simply will not load.

Microsoft updates this list, but on its own schedule — it is a floor, not a force field. The logging in step 2 is what catches the driver that is vulnerable but not yet on anybody’s list. Run both. — Nyx

Why this matters. This is the cheapest, most direct block for the technique. The blocklist plus HVCI stops the common case outright; the logging is your net for the rest.

Now use the log from step 2 the way you would in an investigation: list every driver load whose file did not come from the Windows driver folder.

> Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object { $_.Id -eq 6 -and $_.Message -notmatch "C:\\Windows\\System32\\drivers" } | Select-Object TimeCreated,Message | Format-List

On a clean machine this is usually empty or a couple of known vendor tools (a GPU or VPN driver from Program Files). Anything loading from a user profile, ProgramData, Temp or a downloads folder is the lead you open first.

Why this matters. This is the whole blue-team move in one line: define normal (System32 drivers), then show only the exceptions. Forward this same logic to your SIEM and it watches every machine, not just this one.

A hunt you ran once protects you once. If you forward Sysmon to Splunk (the Splunk labs here show how), turn step 6 into a saved alert.

> index=sysmon EventCode=6 ImageLoaded!="C:\\Windows\\System32\\drivers\\*" | table _time Computer ImageLoaded Signed Signature SignatureStatus

Save that as an alert that fires when the result count is above zero. Add a second one for Signed=false. Between the blocklist, HVCI and these two alerts, a driver has to be signed, valid, not on the blocklist, and loading from the right folder — or you hear about it.

Why this matters. Controls you have to remember to run are controls you will forget. The alert is what makes this survive past today.