Kernel Mode Drivers: A Hidden Danger for All Windows Users
Microsoft is revoking certificates, and Chinese hackers are looking for new loopholes to carry out attacks.
Kernel-mode drivers run at the highest level of privilege in Windows, giving full access to the target machine for hidden persistence, undetectable data filtering, and the ability to terminate virtually any process.
Even if security features are active on a jailbroken device, a kernel-mode driver can interfere with security features, disable advanced security features, or perform targeted configuration changes to avoid detection.
Back in Windows Vista, Microsoft made policy changes to restrict the loading of Windows kernel-mode drivers into the operating system, requiring developers to submit new drivers for review and sign them through the Microsoft Developer Portal.
However, to prevent problems with older applications, Microsoft introduced certain exceptions that allowed older kernel-mode drivers to continue loading. Among these exceptions:
- The computer was upgraded from an earlier version of Windows to Windows 10 version 1607.
- Secure Boot (secure boot) is disabled in BIOS.
- The drivers were signed with an end-entity certificate issued prior to July 29, 2015 that is linked to a supported, cross-signed CA.
IN yesterday’s report Cisco Talos explains that Chinese attackers use the last exception from the list above, using two open source tools “HookSignTool” and “FuckCertVerify” to change the time of signing malicious drivers to any date before July 29, 2015.
By changing the signing date, hackers can use older, unrevoked certificates to sign their drivers and load them into Windows for privilege escalation.
HookSignTool is a feature-packed tool released in 2019 on a Chinese software hacking forum using Windows Hooking. API along with a legitimate signing tool to perform the signing of a malicious driver.
The tool uses the library Microsoft Detours to intercept and monitor Win32 API calls and a custom implementation of the “CertVerifyTimeValidity” function named “NewCertVerifyTimeValidity” needed to check the time.
HackSignTool requires a “JemmyLoveJenny EV Root CA Certificate” to sign driver files with a backdated timestamp, which is available through the tool’s author’s website.
However, the use of this certificate leaves artifacts in the fake signature, allowing drivers signed with the HookSignTool to be identified.
FuckCertVerify is another tool used by attackers to change signature timestamps of malicious kernel-mode drivers that has appeared on GitHub in December 2018 as a game hack tool.
“FuckCertVerifyTimeValidity works similarly to HookSignTool in that it uses the Microsoft Detours package to hook into the “CertVerifyTimeValidity” API call and sets the timestamp to the selected date,” explains Cisco Talos.
“But unlike HookSignTool, FuckCertVerifyTimeValidity leaves no artifacts in the binary it signs, making it very difficult to determine when this tool was used,” the researchers added.
Both tools require an unrevoked code signing certificate issued before July 29, 2015, when Microsoft introduced the policy change, and the corresponding private key and password.
Cisco researchers have found more than a dozen such certificates in GitHub repositories and Chinese forums that can be used in conjunction with these tools.
Microsoft quickly took action and has already revoked the certificates used by the attackers, as well as suspending the accounts of developers who abuse this loophole in Windows policy.
In addition, Microsoft has also implemented the appropriate detection tools in the branded Microsoft Defender (1.391.3822.0 and later) to protect customers from malicious drivers with a fake signature.
Reportedly, Microsoft does not classify this abuse as a vulnerability, and therefore did not assign a separate CVE identifier to it. Meanwhile, a Sophos report yesterday said that researchers have uncovered more than a hundred malicious kernel-mode drivers used as “EDR killers” to kill security software normally protected from user-mode programs.
While the certificates discovered by the aforementioned companies have now been revoked, the risk still exists as other similar certificates can still be found on the Internet, which could allow cybercriminals to continue to abuse this Windows policy loophole.