The ransomware that brought a signed driver to switch off the rule against unsigned drivers

RobbinHood ransomware did something in early 2020 that’s now standard tradecraft but was a milestone then: it brought its own signed driver to defeat the rule against unsigned drivers. The crew installed a legitimately-signed GIGABYTE motherboard driver, gdrv.sys, exploited a vulnerability in it to reach the kernel, used that access to switch off Windows Driver Signature Enforcement in memory, and then loaded their own unsigned malicious driver to terminate and delete security software from kernel space, clearing the way to encrypt. The four GIGABYTE driver vulnerabilities behind this, CVE-2018-19320, CVE-2018-19321, CVE-2018-19322, and CVE-2018-19323, are the reason a deprecated motherboard utility became a ransomware tool.

What the bugs are

The four CVEs are a cluster of flaws in GIGABYTE’s driver software, disclosed in 2018. The most consequential, CVE-2018-19320, is in gdrv.sys and allows reading and writing arbitrary kernel memory, which is a direct path from a driver loaded by an admin to full kernel control. The driver was legitimately signed by GIGABYTE, and that signature is the whole trick: Windows will load a properly-signed driver even when it’s known to be vulnerable. GIGABYTE eventually deprecated the software, but the signed binary remained usable. CISA added all four to the Known Exploited Vulnerabilities catalog on October 24, 2022, with the ransomware flag.

This is bring-your-own-vulnerable-driver (BYOVD), the same class as the Intel Ethernet driver Scattered Spider used and the built-in Windows driver Lazarus abused. What makes the GIGABYTE/RobbinHood case worth its own look is the specific two-driver technique and its place in history.

The two-driver move

Most BYOVD descriptions stop at “the vulnerable driver gives kernel access.” RobbinHood went a step further, and the sequence is elegant in a way that should worry you:

1. Load the signed, vulnerable gdrv.sys. Windows accepts it because the signature is valid.
2. Exploit CVE-2018-19320 to read/write kernel memory, and use that to flip the in-memory flag that enforces driver signing. Driver Signature Enforcement is now off, on the fly, without a reboot.
3. With signing enforcement disabled, load a second driver, the attacker’s own unsigned rbnl.sys, which has no valid signature and would normally be rejected.
4. From that malicious kernel driver, terminate and delete the processes and files of endpoint security products, which run in user mode and are now below the attacker in the trust hierarchy.

This was, as Sophos noted at the time, the first observed instance of ransomware shipping a trusted signed driver specifically to patch the kernel and load its own unsigned code. It turned “we have admin” into “we have the kernel and your EDR is gone,” and it became a template the whole ransomware ecosystem copied.

What to do

The defenses are the same ones that stop commodity BYOVD generally, covered in detail in the Intel-driver piece, and they apply directly here:

• Enable and update the Microsoft Vulnerable Driver Blocklist. The GIGABYTE drivers are cataloged known-bad; the blocklist refuses to load them. Confirm it’s on and current.
• Turn on Memory Integrity (HVCI). Hypervisor-enforced code integrity raises the bar for loading malicious or vulnerable drivers and helps protect signing enforcement from the in-memory tampering this attack relied on.
• Use WDAC driver allowlisting in high-assurance environments so only approved drivers load at all, vulnerable or not.
• Treat EDR going dark as an incident. The entire point of this technique is to kill your security tooling from the kernel. Security agents that get terminated or stop reporting, especially around new driver loads, are a high-fidelity sign of an active BYOVD intrusion.
• Alert on unexpected driver installs, particularly old signed third-party drivers like motherboard utilities appearing on machines that have no reason to run them.

The reframe is the lesson RobbinHood taught the industry: a valid signature means the code came from who it says, not that the code is safe, and an attacker with admin can borrow someone else’s good signature to get into the kernel and then disable the very mechanism that vouches for signatures. Signed is not the same as trustworthy. Enable the blocklist and Memory Integrity so a deprecated GIGABYTE driver from 2018 can’t be the thing that turns off your defenses in 2026. We track the BYOVD entries as one ongoing story, because the technique RobbinHood pioneered is now in everyone’s kit.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2018-19320 — 2018-12
• Sophos: Living off another land, ransomware borrows vulnerable driver to remove security software — 2020-02-06
• BleepingComputer: Ransomware exploits GIGABYTE driver to kill AV processes — 2020-02
• Security Affairs: RobbinHood ransomware exploits GIGABYTE driver flaw to kill security software — 2020-02