Vulnerable Driver Blocklist

The vulnerable driver blocklist is the layer that answers what DSE cannot: among validly signed drivers, which ones are too dangerous to load. It is a deny-by-identity list, so its bypass inventory has exactly two shapes, and both are structural rather than cryptographic: a driver the list has not caught yet, and a driver the list can never list.

That second shape is the important one. The Lazarus Group's pivot, documented in Lazarus / FudModule, was to stop bringing drivers at all and take the primitive from appid.sys and afd.sys, components Windows ships and cannot remove. A load-time list cannot answer that, because the answer to "should afd.sys load" is yes on every machine in the fleet.

Layer	Kernel. The protected asset is the set of drivers admitted at load.
Enforced by	Kernel. A WDAC policy applied to driver loads.
Mechanism	Deny list of signed-vulnerable drivers, distributed through servicing.
Introduced	Windows 10 1709 era, expanded repeatedly since; on by default with HVCI.

Bypass inventory

Why the inventory looks like this

Two of the three entries are open on every configuration, which reads badly until you notice what kind of open they are. The first is a race the list can eventually win. The second is a category error the list can never win: afd.sys is load-bearing for networking. The realistic defense posture is therefore the blocklist plus App Control for Business with a allowlist policy, which answers "which signer may load" per fleet rather than globally, and the detection guidance in the Lazarus profile for the unlistable case.

What a defender sees

Telemetry for the policy version itself is the health signal: a fleet whose blocklist ages is a fleet drifting toward the third technique. Loads of listed drivers are the loudest event on this page, essentially zero-false-positive. For the unlistable case there is no load signal at all, which is the point: detection moves to anomalous IOCTL traffic, as documented in CVE-2024-21338.