Microsoft blocked code signing certificates predominantly used by Chinese hackers and developers to sign and load malicious kernel mode drivers on breached systems by exploiting a Windows policy loophole.
Kernel-mode drivers operate at the highest privilege level on Windows (Ring 0), allowing complete access to the target machine for stealthy persistence, undetectable data exfiltration, and the ability to terminate almost any process.
Even if security tools are active on the compromised device, a kernel-mode driver can interfere with their operation, turn off their advanced protection capabilities, or perform targeted configuration modifications to evade detection.
With Windows Vista, Microsoft introduced policy changes restricting how Windows kernel-mode drivers could be loaded into the operating system, requiring developers to submit their drivers for review and sign them through Microsoft’s developer portal.
However, to prevent issues with older applications, Microsoft introduced the following exceptions that allowed older kernel mode drivers to continue to be loaded:
- The PC was upgraded from an earlier release of Windows to Windows 10, version 1607.
- Secure Boot is off in the BIOS.
- Drivers were [sic] signed with an end-entity certificate issued before July 29th, 2015 that chains to a supported cross-signed CA
A new report by Cisco Talos explains that Chinese threat actors are exploiting the third policy by using two open-source tools, ‘HookSignTool’ and ‘FuckCertVerify,’ to alter the signing date of malicious drivers before July 29th, 2015.
By altering the signing date, the threat actors can use older, leaked, non-revoked certificates to sign their drivers and load them into Windows for privilege escalation.
HookSignTool and FuckCertVerify
HookSignTool is a feature-rich tool released in 2019 on a Chinese software cracking forum, using Windows API hooking alongside a legitimate code signing tool to perform malicious driver signing.
The tool uses the Microsoft Detours library for intercepting and monitoring Win32 API calls and a custom implementation of the ‘CertVerifyTimeValidity’ function named ‘NewCertVerifyTimeValidity,’ which verifies invalid times.
HackSignTool requires the presence of the “JemmyLoveJenny EV Root CA certificate” to sign driver files with a backdated timestamp, which is available through the tool’s author website.
However, using this certificate leaves artifacts in the forged signature, making it possible to identify drivers signed with HookSignTool.
In a separate report also published today, Cisco Talos details a real-world example of a malicious driver called ‘RedDriver,’ signed using the HookSignTool.
RedDriver is a browser hijacker that intercepts browser traffic, targeting Chrome, Edge, and Firefox, as well as an extensive list of browsers popular in China.
FuckCertVerify is another tool threat actors use to modify the signature timestamps of malicious kernel-mode drivers, originally made available on GitHub in December 2018 as a game cheat tool.
“FuckCertVerifyTimeValidity works in a similar fashion to HookSignTool in that it uses the Microsoft Detours package to attach to the “CertVerifyTimeValidity” API call and sets the timestamp to a chosen date,” explains Cisco Talos.
“[But] unlike HookSignTool, FuckCertVerifyTimeValidity does not leave artifacts in the binary that it signs, making it very difficult to identify when this tool has been used.”
Both tools require a non-revoked code-signing certificate issued before July 29th, 2015, when Microsoft introduced the policy change, along with the matching private key and password.
Cisco’s researchers have found more than a dozen certificates in GitHub repositories and Chinese-language forums that can be used by these tools, which are widely used for game cracks that can bypass DRM checks and malicious kernel drivers.
Cisco Talos says they informed Microsoft of its findings, and the tech company blocked all certificates reported as widely abused and released an advisory about the issue.
However, the risk is far from eliminated as further certificates likely remain exposed or stolen, allowing threat actors to continue to abuse this Windows policy loophole.