A Microsoft Windows policy loophole has been observed being exploited primarily by native Chinese-speaking threat actors to forge signatures on kernel-mode drivers.
“Actors are leveraging multiple open-source tools that alter the signing date of kernel mode drivers to load malicious and unverified drivers signed with expired certificates,” Cisco Talos said in an exhaustive two-part report shared with The Hacker News. “This is a major threat, as access to the kernel provides complete access to a system, and therefore total compromise.”
Following responsible disclosure, Microsoft said it has taken steps to block all certificates to mitigate the threat. It further stated that its investigation found “the activity was limited to the abuse of several developer program accounts and that no Microsoft account compromise has been identified.”
The tech giant, besides suspending developer program accounts involved in the incident, emphasized that the threat actors had already gained administrative privileges on compromised systems prior to use of the drivers.
It’s worth pointing out that the Windows maker had rolled out similar blocking protections in December 2022 to prevent ransomware attackers from using Microsoft-signed drivers for post-exploitation activity.
Driver signature enforcement, which requires kernel-mode drivers to be digitally signed with a certificate from Microsoft’s Dev Portal, is a crucial line of defense against malicious drivers, which could be potentially weaponized to evade security solutions, tamper with system processes, and maintain persistence. The policy change was introduced with the debut of Windows Vista.
The new weakness discovered by Cisco Talos makes it possible to forge signatures on kernel-mode drivers, thereby allowing Windows certificate policies to be bypassed.
This is made possible due to an exception carved out by Microsoft to maintain compatibility, which permits cross-signed drivers if the computer was upgraded from an earlier release of Windows to Windows 10, version 1607; Secure Boot is off in the BIOS; and the drivers were “signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed [certificate authority].”
“The third exception creates a loophole that allows a newly compiled driver to be signed with non-revoked certificates issued prior to or expired before July 29, 2015, provided that the certificate chains to a supported cross-signed certificate authority,” the cybersecurity company said.
As a result, a driver signed in this manner will not be prevented from being loaded on a Windows device, thereby enabling threat actors to take advantage of the escape clause to deploy thousands of malicious, signed drivers without submitting them to Microsoft for verification.
These rogue drivers are deployed using signature timestamp forging software such as HookSignTool and FuckCertVerifyTimeValidity, which have been publicly available since 2019 and 2018, respectively.
HookSignTool has been accessible via GitHub since January 7, 2020, while FuckCertVerifyTimeValidity was first committed to the code hosting service on December 14, 2018.
“HookSignTool is a driver signature forging tool that alters the signing date of a driver during the signing process through a combination of hooking into the Windows API and manually altering the import table of a legitimate code signing tool,” Cisco Talos explained.
Specifically, it involves hooking to the CertVerifyTimeValidity function, which verifies the time validity of a certificate, to change the signing timestamp during execution.
“This tiny project prevents the signtool from verifing [sic] cert time validity and let you sign your bin with outdated cert without changing system time manually,” the GitHub page for FuckCertVerifyTimeValidity reads.
“It install hook into crypt32!CertVerifyTimeValidity and make it always return 0 and make kernel32!GetLocalTime return what you want as you can add “-fuckyear 2011″ to signtool’s command line to sign a cert from year 2011.”
That said, pulling off a successful forgery requires a non-revoked code signing certificate that was issued before July 29, 2015, along with the certificate’s private key and passphrase.
Cisco Talos said it discovered over a dozen code signing certificates with keys and passwords contained in a PFX file hosted on GitHub in a forked repository of FuckCertVerifyTimeValidity. It’s not immediately clear how these certificates were obtained.
What’s more, it has been observed that HookSignTool has been used to re-sign cracked drivers in order to bypass digital rights management (DRM) integrity checks, with an actor named “Juno_Jr” releasing a cracked version of PrimoCache, a legitimate software caching solution, in a Chinese software cracking forum on November 9, 2022.
“In the cracked version […], the patched driver was re-signed with a certificate originally issued to ‘Shenzhen Luyoudashi Technology Co., Ltd.,’ which is contained in the PFX file on GitHub,” Talos researchers said. “This ability to resign a cracked driver removes a significant roadblock when attempting to bypass DRM checks in a signed driver.”
That’s not all. HookSignTool is also being utilized by a previously undocumented driver identified as RedDriver to forge its signature timestamp. Active since at least 2021, it functions as a driver-based browser hijacker that leverages the Windows Filtering Platform (WFP) to intercept browser traffic and reroute it to localhost (127.0.0.1).
The target browser is chosen at random from a hard-coded list containing the process names of many popular Chinese language browsers like Liebao, QQ Browser, Sogou, and UC Browser, as well as Google Chrome, Microsoft Edge, and Mozilla Firefox.
“I initially found RedDriver while researching certificate timestamp forging on Windows drivers,” Chris Neal, outreach researcher for Cisco Talos told The Hacker News. “It was one of the first samples I ran into that was immediately suspicious. What caught my attention was the list of web browsers stored inside the RedDriver file.”
The ultimate objective of this browser traffic redirection is not clear, although it goes without saying that such a capability could be abused to tamper with browser traffic at the packet level.
RedDriver infection chains commence with the execution of a binary named “DnfClientShell32.exe,” which, in turn, initiates encrypted communications with a command-and-control (C2) server to download the malicious driver.
“We didn’t observe the delivery of the initial file, but it’s very likely that the file was packaged to masquerade as a game file, and was hosted on a malicious download link,” Neal said. “The victim probably thought they were downloading a file from a legitimate source and ran the executable. ‘DNFClient’ is the name of a file belonging to ‘Dungeon Fighter Online’ which is an extremely popular game in China and commonly referred to as ‘DNF.'”
“RedDriver was likely developed by highly skilled threat actors as the learning curve for developing malicious drivers is steep,” Cisco Talos said. “While the threat appears to target native Chinese speakers, the authors are likely Chinese speakers as well.”
“The authors also demonstrated a familiarity or experience with software development lifecycles, another skill set that requires previous development experience.”
The development comes as Sophos said it found over 100 malicious kernel drivers that had been signed by Microsoft and other companies, some dating as far back as April, and used to either sabotage security software from running as designed or function as a stealthy rootkit capable of monitoring network traffic using WFP.
“It appears the creator of the malicious driver built out one ‘parent’ version of the driver, then ran the parent version through one or more packer utilities one or more times, creating in some cases dozens of ‘child’ variants, all of which the creators could submit to Microsoft for signing,” Sophos researcher Andrew Brandt said.
“There are a lot of benefits for threat actors to deploy drivers in their infection chain, however they are a lot more difficult to develop than user-mode malware,” Neal said. “Drivers are harder to detect for EDR and are hard to analyze, especially if there is any obfuscation employed.”