Why load someone else's legitimately signed but vulnerable kernel driver?

## The constraint that creates the technique On 64-bit Windows the kernel will not load an unsigned driver: the code-integrity policy requires a signature chaining to a root it trusts, and for modern drivers that effectively means one issued through the platform vendor's own signing programme. Linux distributions with module signing enforced impose the same shape of rule. So the operator's problem is not writing kernel code - that is easy - it is **producing a signature the machine will accept**. That reframes the whole thing as a supply question, and there are only three answers. ## Route one: obtain a signing identity Steal a vendor's private key, or stand up a shell company convincing enough to be issued a certificate. This works, and crews with real budgets do it. It is also the worst asset a crew can own: - It is **finite**. There is one key, and every use of it is a use of the same identity. - It is **attributable**. Signed artefacts from that identity cluster together, tying otherwise unrelated operations to one crew. - It **dies on revocation**, and once dead it cannot be resurrected. There is a nuance about revocation worth knowing. Code signatures are usually countersigned with a trusted timestamp so they keep validating after the certificate expires - otherwise every shipped program would stop working when a certificate rolled over. That same property means simple revocation does not necessarily invalidate signatures already made; the revocation has to carry a compromise date so that anything timestamped after it is rejected. And a client only acts on any of this when it fetches and honours the revocation data, which is not universal. ## Route two: borrow a signature that already exists This is the technique the question is about, usually named `bring your own vulnerable driver`. Real vendors ship real, properly signed kernel drivers - for overclocking utilities, firmware flashers, hardware diagnostics, backup products, anti-cheat systems. Some of them expose extremely powerful operations to any caller that can open the device, because the vendor assumed only their own privileged tool would ever talk to it. Typical primitives: - **Map arbitrary physical memory** into a user-mode process, which is a read/write of anything on the machine. - **Write an arbitrary model-specific register or control register**, which can switch off enforcement the kernel relies on. - **Terminate or open a handle to any process**, from the kernel, ignoring the protections a user-mode caller would hit. The operator installs the vendor's driver - which requires administrative rights, so this is still privilege being spent rather than won - and then drives it from an ordinary user-mode program. Nothing is forged, the signature is genuine, the vendor is legitimate, and the driver on disk is byte-identical to the one the vendor published. ## Route three: do not go to kernel at all Worth naming because it is the most common outcome. If administrative rights already give the operator what they need, the kernel crossing is an expense with a real downside: a bug in kernel code stops the machine, and a fleet of stopped machines ends the operation. Plenty of intrusions never bother. ## Why this changes what removes the technique Because the signature is valid, signature enforcement is not the control. The platform has to refuse **specific known-bad drivers** by identity - a vulnerable-driver blocklist maintained by the platform vendor and shipped to machines - and that changes the economics in two ways: 1. **The blocklist is a race.** New abusable drivers are found faster than fleets adopt list updates, and a driver only enters the list once somebody has characterised it. 2. **Adoption lags and is uneven.** Enforcement may be off by default on older installations, tied to other platform features, or disabled because it broke something. A control that ships is not a control that runs. A second, structurally different control raises the bar rather than enumerating badness: enforcing kernel code integrity from a layer the kernel cannot modify - a hypervisor-backed policy - so that even a driver running in the kernel cannot install arbitrary executable kernel code. That does not stop a vulnerable driver from being loaded, but it narrows what the abused primitive can convert into. ## The wrong answer to avoid The reflex is `they must have stolen a certificate`. Often nobody stole anything. The scarce asset was never the code and frequently was not a certificate either - it was administrative rights on the host, spent on installing a perfectly genuine driver whose author never imagined a hostile caller.