How cybercriminals forge digital signatures on kernel-mode malicious drivers to bypass EDR

Chinese-speaking threat actors have been shown to be using a Microsoft Windows policy vulnerability to spoof signatures on kernel-mode drivers. The Windows operating system (OS) is divided into two levels, or “modes”: user mode, where the files and programs that users interact with are located, and kernel mode, where the Windows foundation and kernel mode drivers carry out system-critical operations. Through a number of methods included in system libraries, drivers may use the Windows API to enable communication between different modes. A tightly regulated logical barrier is built between the common user and the Windows kernel as a result of the operating system being split into two modes. Since access to the kernel grants full access to a system, maintaining this barrier is essential to preserving the integrity and security of the OS. As a consequence, using a rogue driver may let an attacker get past this defense and completely take over the target machine.

To counter the danger posed by malicious drivers, Microsoft started requiring kernel-mode drivers to be digitally signed with a certificate from a trusted certificate authority starting with Windows Vista 64-bit. Malicious drivers may readily avoid endpoint detection and anti-malware software, making them exceedingly difficult to fight against without signature enforcement. The most important part of protecting against malicious kernel mode drivers is requiring signatures on drivers.

Malicious drivers can make it harder to analyze samples, which is another problem. The majority of the analysis must be done manually since most sandboxes used to evaluate malware are unable to track all of a driver’s actions. Threat actors have started to utilize code obfuscation on the drivers they distribute using tools like VMProtect, which makes it even more difficult to analyze drivers.

The benefits of using a rogue driver from the attacker’s point of view include, but are not limited to, evading endpoint detection, being able to control system and user mode processes, and maintaining persistence on an infected device. These benefits provide attackers a strong incentive to figure out how to get around the Windows driver signature rules.

Threat actors have been seen by Cisco Talos exploiting a gap in Windows policy that permits the forgery of signatures on kernel-mode drivers, circumventing the certificate rules in Windows. This is made possible by the use of open-source tools and non-revoked certificates that either expired before or were issued before July 29, 2015.

Microsoft changed its driver signing policy to prohibit new kernel-mode drivers that have not been submitted to and approved by its Developer Portal as of Windows 10 version 1607. The goal of this procedure is to guarantee that drivers adhere to Microsoft’s criteria and security guidelines. Microsoft made exceptions for the following in an attempt to retain the functionality and compatibility of older drivers:

  1. The computer’s operating system was updated from a previous version to Windows 10, version 1607.
  2. In the BIOS, Secure Boot is disabled.
  3. Drivers was signed using an end-entity certificate that was issued before July 29th, 2015 and chains to a cross-signed CA that is supported.

A freshly developed driver may be signed using non-revoked certificates that were issued before or expired on July 29, 2015, as long as the certificate chains to a recognized cross-signed certificate authority, thanks to the third exemption, which opens up a security flaw. If a driver is correctly signed in this manner, installation and service startup will not be impeded. As a consequence, several open source programs have been created to take advantage of this weakness. This is a well-known approach that is often disregarded despite presenting a severe danger to Windows systems and being reasonably simple to execute thanks in part to the publicly accessible tools.

The software used to create these fake drivers, such as HookSignTool and FuckCertVerifyTimeValidity, has been made accessible to the public since 2019 and 2018, respectively. HookSignTool has been available on GitHub since January 7, 2020, and FuckCertVerifyTimeValidity was first uploaded on December 14, 2018, respectively.

According to Cisco Talos, “HookSignTool is a driver signature forging tool that changes the signing date of a driver during the signing process through a combination of manually altering the import table of a legitimate code signing tool and hooking into the Windows API.”

The signature timestamp is changed during execution via hooking to the CertVerifyTimeValidity function, which checks a certificate’s time validity.

According to the FuckCertVerifyTimeValidity GitHub website, “This tiny project prevents the signtool from verifying [sic] cert time validity and lets you sign your bin with outdated cert without manually changing system time.” The hook is installed into crypt32!Make kernel32 and CertVerifyTimeValidity always return 0!As you may sign a certificate from the year 2011 by adding “-fuckyear 2011” to the command line of signtool, GetLocalTime returns what you want.

A valid code signing certificate that was issued before to July 29, 2015, coupled with the certificate’s private key and passphrase, are necessary for a successful forgery.

More than a dozen code signing certificates, along with their associated keys and passwords, were reportedly found by Cisco Talos in a PFX file stored in a cloned repository of FuckCertVerifyTimeValidity on GitHub. It’s unclear right away how these certifications were acquired. Not just that. A previously undocumented driver known as RedDriver is likewise using HookSignTool to falsify its signature timestamp. It is a driver-based browser hijacker that has been active since at least 2021 and uses the Windows Filtering Platform (WFP) to divert browser traffic to localhost (

A hard-coded list of the process names of several well-known Chinese language browsers, including Liebao, QQ Browser, Sogou, and UC Browser, as well as Google Chrome, Microsoft Edge, and Mozilla Firefox, is used to choose the target browser at random. Although it goes without saying that such a feature may be misused to interfere with browser traffic at the packet level, the end goal of this browser traffic redirection is not entirely evident.

A major danger is posed by HookSignTool and FuckCertVerifyTimeValidity since the installation of malicious drivers might provide an attacker access to a system’s kernel. These tools may also be used to re-sign a cracked driver in order to get around DRM, which might result in software piracy costing an organization sales. In addition to these dangers, using untrusted drivers—even when no malicious intent is present—can harm a system if the driver was not properly developed.

As malicious drivers are difficult to identify heuristically and are best stopped based on file hashes or the certificates used to sign them, Cisco Talos advises banning the certificates indicated in this blog post. A good way to spot instances of timestamp forgery is occasionally to compare the signature timestamp with the driver’s compilation date. It’s crucial to keep in mind, however, that compilation dates may be changed to correspond to signature timestamps.