[German]Microsoft's measures to prevent the loading of malicious kernel drivers don't seem to be working at all. I've had the issue on my radar for weeks, because the driver block list doesn't really seem to work. Now security researchers at Talos have revealed a campaign in which open source tools use forged signature timestamps to load malicious Windows drivers.
Advertising
Microsoft has issued the requirement since Windows Vista in the 64-bit Windows operating systems that kernel-mode drivers must be digitally signed with a certificate from a verified certification authority. Without such a certificate, the drivers can no longer be loaded. In addition, newer Windows versions also include the option of blocking malicious drivers. However, cases are repeatedly reported where these mechanisms fail. And Microsoft has still allowed some "exceptions" (upgrade from legacy systems to Windows 10 V1607, drivers signed with a certificate before July 15, 2015, Secure Boot disabled) where the signature check does not take effect. The colleagues from Bleeping Computer have mentioned the exceptions in this post.
Talos warning about RedDriver attack
I came across the topic on Twitter via a corresponding tweet from Talos, which their security researchers took up in the blog post Old certificate, new signature: Open-source tools forge signature timestamps on Windows drivers. Details on the topic can be read within this article.
In a nutshell, Cisco Talos has discovered that threat actors are exploiting a Windows policy vulnerability that allows the signing and loading of unsigned kernel-mode drivers with a signature timestamp prior to July 15, 2015. In doing so, the actors use several open source tools that change the signing date of kernel-mode drivers. The goal is to load unverified drivers (with malicious content) into Windows, even though these driver dates are signed with expired certificates.
Analyzing such cases, Talos security researchers found more than a dozen code signing certificates with keys and passwords in a PFX file on GitHub used in conjunction with these open-source tools. Most of these prominent drivers that contained a language code in their metadata use the Simplified Chinese language code. This indicates that the actors using these tools are often native Chinese speakers.
Advertising
Cisco Talos has also identified a case where one of these open-source tools was used to re-sign cracked drivers to bypass Windows digital rights management (DRM). The security researchers published a blog post showing real-world abuse of this loophole by an undocumented malicious driver called RedDriver. A previously undocumented driver-based browser hijacker called RedDriver targets Chinese-speaking users and Internet cafes.
Talos security researchers contacted Microsoft during the research to inform the company about the vulnerability. Microsoft then revoked all the misused certificates identified by Talos and published a notice ADV230001.
Microsoft ADV230001
In security advisory ADV230001, , dated July 11, 2023, Microsoft addresses the issue, writing that it was recently informed that drivers certified by the Microsoft Windows Hardware Developer Program (MWHDP) were used maliciously for post-exploitation activities. In these attacks, the attacker obtained administrative rights on the attacked systems before using the drivers.
From Redmond, it is said that the activity was found to be limited to the misuse of several developer program accounts and no compromise of Microsoft accounts was detected. To protect users from this threat, partner vendor accounts have been suspended and blocking detections have been implemented for all reported malicious drivers. We are talking about 133 drivers.
Reading the last paragraph rang a bell and I had my déjà vu experience. A quick search in my blog found the post Microsoft certificates misused to sign malware (Dec. 2022). At that time, Microsoft published document ADV220005, dated Dec. 13, 2022. And I found no indication that the above vulnerability (driver signing before July 15, 2015) was closed. That's probably where the legacy issues with Windows 10 LTSC 2015 and 2016 are still causing problems.
Microsoft recommends installing the latest July 2023 Windows updates and ensuring that installed antivirus and endpoint detection products have the latest signatures and are enabled to prevent these attacks. This is because as of July 11, 2023, Windows security updates have been released that remove trust from drivers and driver signature certificates for affected files. There is a separate support post Notice of additions to the Windows Driver.STL revocation list.
In addition, Microsoft has implemented blocking detections (Microsoft Defender 1.391.3822.0 and later) to protect users from legitimately signed drivers that have been maliciously tampered with and then used for post-exploit activities.
Drama with the driver block liste
Actually, Windows should block known malicious drivers when they load, so they can't do any harm. At least that's what Microsoft has claimed for years (see also my blog post New security feature allows driver block lists in Windows 10, 11 and Windows Server). Microsoft uses driver blocklists and security features like Windows Defender Application Control or HVCI in Windows for this security promise.
In October 2022, I had confirmed in the blog post Microsoft confirms: Windows fails to detect dangerous drivers – block lists not updated the problem that this promised mechanism was nothing more than a placebo. Because the distribution of the blocklists to the endpoints (meaning the Windows systems of the users) did not work. I had picked up some related hints there from security researcher Will Dormann, who addressed this.
I follow Will Dormann on Twitter and in recent months I have noticed several tweets where he points out that malicious drivers are loaded despite blocklists. Above tweet dated May 26, 2023 is a reply to a post where a tool to kill protected anti-malware processes is mentioned. Dormann states that blocking drivers does not really work. He was able to load a malicious driver on a fully patched Windows 11 22H2 system, even though it is included in MS's recommended list of driver blocking rules. The Microsoft driver blocking list is distributed to endpoints (Windows systems) only 1-2 times per year.
I'm left with a bad feeling about this, and I wouldn't rely on the Microsoft driver lock list or any other ramblings a la "we've locked a developer account".
Advertising
