A "Clear And Present" Danger Lurking In Windows 10/11

[itman 1,748]

Now that someone has posted in the forum two malicious attestation kernel mode drivers that Eset currently doesn't detect, it's time to get into the details of Microsoft's "dirty little secret" on this subject. Also, I am utterly amassed on the lack of discussion of this issue by the security community on the potential risk that has existed since when Windows 10 was introduced.

In the way of introduction to this issue, Microsoft "caved into" demands by enterprise sourced software developers who were tired of going through the process of having their internally developed kernel mode drivers WHQL certified. Hence, the establishment of attestation signing of kernel mode drivers.

Also, this is not the first time malicious attestation signed drivers have been deployed. It happened a while back. What utterly amazed me at that time was the publicized article about the incident at bleepingcomputer.com never once mentioned the fact these were attestation signed drivers. Only mentioned was Microsoft was "tightening up" the validation processing in regards to drivers which obviously has not resolved the issue. As such, it appears to me there appears to be some overall "collusion" taking place to keep the fact that attestation driver signing exists as silent as possible.

Eset needs to starting checking for the attempted installation of attestation signed drivers and at the minimum warn of this activity.

Let's get into the "nitty gritty " detail of this subject.

Quote

An attestation signed driver works on Windows 10. It does not work on earlier versions of Windows, such as Windows 8.1 and Windows 7, and is not supported for Windows Server 2016 and later.

When a driver receives attestation signing, it is not Windows Certified. An attestation signature from Microsoft indicates that the driver can be trusted by Windows, but because the driver has not been tested in HLK Studio, there are no assurances made around compatibility, functionality, etc.

https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release

https://www.osr.com/blog/2017/07/06/attestation-signing-mystery/

The below also shows a way to "slip in" an attestation signed kernel mode driver on Windows 7/8.1!

Quote

A Work-Around:

• Remember: The goal here is to be able to install drivers on down-level versions of Windows, without having to pass WHQL.
• One solution that we know works on Windows 7: Attestation Sign your driver package and binary for Windows 10. The resulting driver package will install on Windows 7 (with KB4474419, which enabled SHA-256 signing installed). Note that this works as long as you DO NOT sign the driver binary with your own signature before you submit it to MSFT for Attestation Signing.
• Attestation Signing your driver package for Windows 10 will also allow non-PnP drivers drivers to be installed on Windows 8.1(including right-click install using an INF) -- This does not, however, work for PnP drivers.

https://community.osr.com/discussion/292723/what-we-know-about-cross-signing-for-down-level-windows-versions-as-of-today-2-march-2021

I also believe the Windows trust bit for attestation drivers is a bit of a stretch. It primarily consists of signing your kernel mode driver with an EV cert. upon submission to Microsoft.  Just go to the Sectigo web site for one of those where they are easy to obtain. Or, just steal one.

Below is how you identify attestation signed drivers. Make sure you read the the entire Geoff Chappell article linked below since it's about 'Back Doors for Cross-Signed Drivers.'

Quote

How the certificate chain gets to this root is irrelevant, but different types of signature will be created by signing with different certificates and an observed correlation will tend to be reliable for a time, such that a few examples can usefully be presented for concreteness:

Signature Type	Certification Path (Root CA to End Entity)
built-in	Microsoft Root Certificate Authority 2010 → Microsoft Windows Production PCA 2011 → Microsoft Windows
WHQL testing	Microsoft Root Certificate Authority 2010 → Microsoft Windows Third Party Component CA 2012 → Microsoft Windows Hardware Compatibility Publisher
attestation	Microsoft Root Certificate Authority 2010 → Microsoft Windows Third Party Component CA 2014 → Microsoft Windows Hardware Compatibility Publisher

 

https://www.geoffchappell.com/notes/security/whqlsettings/index.htm

Finally, this article pretty much sums up the state of attestation signed drivers:

Quote

Myth: Kernel-mode drivers require WHQL testing

Starting with Windows 10, kernel-mode drivers have to be signed by Microsoft using their portal, but that does not entail any testing of the quality of the driver. The code could still contain infinite loops and viruses, but at least it can be tracked to its source when problems arise!

https://www.davidegrayson.com/signing/

 

-EDIT- About the premise that an EV certificate is a valid criteria for assuming a legitimate and trustworthy entity exists:

Quote

How to get an EV certificate in under 2 weeks.

---

This is my 2nd renewal of my EV cert, so I figured I'd let you guys know how to do it the easy way, no lawyers or real offices required.

1. Go to LegalZoom or IncFile and create a new LLC in your state. This costs about $100-$200. It's not hard, you have to be 18 obviously, but besides that it's easy.

2. Once your LLC is created, go to https://www.dnb.com/ . This is a business credit file service, and you can use it for physical address verification/operation existence. Pay the $200 for DUNSFile so you don't have to wait a month. Attach your cell phone as the business number.

3. Wait about 5 days for dnb to create a D-U-N-S number for your business.

4. Purchase the EV certificate, and ask them to use your DUNS number for verification. This will bypass physical address + operational existence. For the actual business address, this should be Incfiles or Legalzoom's office that they register your company under.

5. Wait about 3 more business days for the EV company to verify your information. They will call you too FYI, but it's a bunch of indians/chinese so just say "Hello this is X" and they'll ask you 3 questions to confirm.

https://www.unknowncheats.me/forum/anti-cheat-bypass/393843-ev-certificate-2-weeks.html

Edited June 28, 2022 by itman

[itman 1,748]

Now for a specific example on how kernel mode attestation signed kernel mode drivers are being deployed.

There is a Chinese based security product that has been the "darling" of the folks over at wilderssecurity.com and malwaretips.com for sometime named WiseVector StopX. From its initial "discovery" at the above forums, a persistent question asked has been is the product AV lab certified? The developer's response has been "We're a small start up operation and can't afford the expense to do so." This has went on for at least two years. Of note is Microsoft's specific requirements in regards to it's issuance of the certificate to sign an ELAM driver to allow for registration to Microsoft Security Center.

Presently Eset flags WiseVector StopX as malicious although it did not do so initially.

Next is a fundamental requirement by anyone who has knowledge of security software. Is WiseVector StopX kennel mode driver WHQL certified? Well, it turns out it is attestation signed instead:

Now I have known about this situation for some time. I never mentioned it in the above forums for the following reason. Individuals who frequent those forums classify themselves as knowledgeable in regards to computer security matters. The basic fundamental requirement for anyone using a Windows anti-virus product is that its AV lab certified.

[itman 1,748]

I was able to find a previous article on one instance of a hacked attestation signed driver: https://www.neowin.net/news/microsoft-whql-signed-fivesys-driver-was-actually-malware-in-disguise/ .

I specifically selected this article to show the "confusion" that exists in regards to attestation signed drivers. Neowin.net made a point to state this instance was a hacked Microsoft WHQL certified driver. In reality, the driver was not WHQL tested by Microsoft. However, reviewing the driver certificate it does state it is? This is because Microsoft wants to give the "illusion" that attestation signed drivers are actually tested by Microsoft when in reality, they were not.

[Nightowl 206]

Here also there was a malware as a signed driver - https://www.lifewire.com/rootkit-malware-found-in-signed-windows-driver-5190521

[itman 1,748]

13 hours ago, Nightowl said:

Here also there was a malware as a signed driver - https://www.lifewire.com/rootkit-malware-found-in-signed-windows-driver-5190521

This refers to the NetFilter driver incident that was also referenced in the Neowin.net article I posted.

This also is another example of the "confusion" that currently exists in Win 10/11 driver cert. signing. The Netfilter driver incident actually was a far greater lapse in Microsoft's internal validation processing in regards to Windows kernel mode driver verification. In the Netfilter driver incident, the driver actually was tested and certified via WHQL processing. See the below screen shot:

https://www.bleepingcomputer.com/news/security/microsoft-admits-to-signing-rootkit-malware-in-supply-chain-fiasco/

I guess the folks at Microsoft WHQL failed to noticed the connections to Chinese C&C servers from the driver .......... 🙄

Edited July 17, 2022 by itman

[itman 1,748]

Since the topic of a Microsoft tested and WHQL certified borked driver has been presented, this article from 3 years ago might be enlighting: https://eclypsium.com/2019/08/10/screwed-drivers-signed-sealed-delivered/ .

Now a borked app based WHQL certified kernel mode driver is one thing. AV vendors that register in Microsoft Security Center of Win 10/11 can at least scan those at system boot time via use of their ELAM driver.

However, the linked Eslypsium article noted 40 borked kernel mode device drivers that were WHQL certified. When it comes to a malicious kernel mode device driver, your Windows installation is indeed "dead meat." There is no way AV vendors  can detect those other than by specific signature at driver creation time.

Edited July 17, 2022 by itman