Microsoft have signed multiple rootkits
twitter.com
twitter.com
If you manage to say install npcap on a machine which is also signed these days you can pretty much capture the entire network traffic and send it w/e you want… heck both the capturing and the “sending” can be done from within the npcap driver itself since it can both capture and send packages the logic however needs to reside somewhere else.
The biggest issue here looks to be that MSFT changed their signing protocols.
> In the past, Microsoft only signed the .cat file. Starting with Windows 10, Microsoft now signs all of the portable executables in the returned payload. For example, the .dll file is also signed by Microsoft.
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
They used to sign only CAT files now they’ll sign pretty much anything that was submitted, I’m guessing their review process can’t actually validate what these things do other than they meet the compatibility requirements.
So what they do is that they base their process on “validating” the partner which these days with 100,000 hardware vendors especially in China is pretty darn hard, and even if the process is quite strict it still leaves them open to supply chain attacks.
While it might look bad it’s still better than the alternative, if getting your driver signed would be too hard then it would be the same as the early Windows 7 days during which even relatively large and reputable hardware vendors asked you to disabled driver the mandatory driver signature checks because they were too slow in getting their software signed.
Also note that this doesn’t impact other signing protection such as smart screen for that Microsoft has a much stricter process however I’m also guessing it would quite possible to sneak something past that too since plenty of small even one man shop commercial software managed to get through the red tape for that.
Same goes for VT they only classify something as malware after there is sufficient evidence that it is malware.
For the most part the only difference between malware and non malware is the intent of the operator, pretty much any functionality can be abused for malicious purposes.
This especially holds true for most security/system management suites they have pretty much the same capabilities as any decent RAT malware the only difference is the reason behind why they are deployed.
But I don't see how that regime is useful here because the rules they would need to follow are anything but simple and easy-to-follow. To be effective they need to be more or less reverse engineering complicated drivers day in and day out. So I am not surprised the result is ineffective.
Actually I'd say the practical alternative, which you should indeed prefer in real life, is Class Drivers. Notice how that webcam you bought just plugs in and works? Same for your wireless mouse, the no-name USB headset and the 2TB USB hard disk you bought. Because those are standard classes of device, they don't need custom drivers.
This current practice is security theatre. There's the big show with the "certification process" and then actually they'll just ship whatever malware somebody pays for.
Class drivers are great, but they require devices to comply with standards, which are usually not very accommodating of whatever new bells and whistles manufacturers want to add. Putting RGB lighting on literally everything, for example, was not really considered when the standards were written.
Signature validation means checking an embedded signature if it exists, then looking for the hash in the installed .cat files and, if found, checking that signature.
Authenticode signatures like this are PKI-based. They can be revoked if determined not to be valid later.
If everyone thinks random signed drivers can be malicious, then they're more cautious about them, looking for them. If everyone thinks signed drivers are a sign of trustworthiness, it's much more likely that your malicious driver can wind up where it needs to be, and stay there without being noticed.
My personal bet is heavily on malware getting signed either through a stolen cert/compromised signer or simple incompetence.
Don't forget that the other mission of the NSA is to protect American computer infrastructure. Doing something like this where the driver distribution is so wide and indiscriminate would also argue against their involvement.
My guesses are in order: 1. The driver authors copied source from somewhere else without understanding what it did. 2. Malicious intent from the Chinese firms. 3. Malicious intent from the CCP. 4. Any other reason.
Perhaps OS developers should move to a validation system something like FCC has (i.e. to check for allowed electromagnetic interference) that requires analysis and certification by a third party of the driver before it gets signed and rolled-out.
If you are a genuine hardware vendor, giving them an actual, working driver binary so they can run whatever QA and static static analysis test suite on the binary, you might have the benefit of a doubt and get it signed once it passes.
That assumption of good faith mixed with "Betriebsblindheit" is probably all it takes to get a signed driver with a backdoor/rootkit/whatever in it.
For comparison: https://news.ycombinator.com/item?id=26887670
EDIT: I'm not trying to imply that's what happened here, we don't have enough details yet. Just trying to point out, that binary signing isn't a panacea and doesn't require Ethan Hunt cable dangling into a secure computer room to work around.
Even if Microsoft makes some pretense of vetting, no one can ever perfectly weed out malware authors in advance, as that would require knowledge of their future thoughts and motivations (hard enough to assess those in the present).
(If Microsoft has failed to revoke certs for known rootkits, by all means bash them hard for that.)