Big Surprise: Chinese PUPs Deliver Backdoored Drivers

Also, a bit of caution here in regards to the POC code.

The Chinese malware was bundled as a PUP in an "assumed" safe app. The user would have allowed the safe app to run and began the installation. The installation process could have involved a "Trusted Installer" for example. So I don't know how AppGuard will react under this scenario.

Also as previously noted, "the real malware" was packed and obfuscated which means its unpacking and decrypting in memory. I took a look at the POC .exe, .asm, and .sys files and none are packed and obfuscated.

Finally, the point of the POC is to show that the driver can be loaded into the kernel without issue bypassing Win's driver signing requirements. This can be verified by using Winobj and viewing the driver global root table. Of course, you have to allow the POC .exe to run ..............

 

I need to clarify something before everyone gets "bent out of shape." All kernel mode drivers since Win 7 and possibly Vista need to be code signed. Plus, they can only be signed with a cert. issued from a few designated CA's. What Win 10 ver. 1607 introduced was the previous kernel driver code signing certs. are no longer adequate and that these drivers must now be signed with a special cert. only issued by Microsoft. Also as previously mentioned, this Microsoft cert. requirement only applies to fresh installs of Win 10 ver. 1607 and not to Win 10 vers. that were upgraded from a prior ver..

That said, I ran the POC and could not verify that its unsigned kernel driver loaded. The POC runs very fast. I believe what the POC is doing is loading and immediately unloading the driver. So now I am going to fire up Process Monitor and see what the logs show. Will report back on that.

 

Hi, PoC writer here.

Seems there's been some confusion. The *drivers* are properly signed, and contain a backdoor that allows for LPE (if the driver is already installed) or just driver signature enforcement bypass (if not).

The PoC uses the backdoor in the already signed drivers to load an unsigned driver.

 

Hi,

I saved the Process Monitor log. Please help point me to where the driver is being loaded using DSE bypass. I can't find any such activity.

Nor can I find any ref. to FSDrv64.sys which I assume is the signed driver ever loading.

-EDIT-

If your .Net program is using PowerShell assemblies to load the signed driver, it will fail on my PC since I am running PowerShell in "ConstrainedLanguage" mode.

 

FSDrv.sys/FSDrv64.sys is a proof of concept driver (source provided) to be loaded via the backdoor, that just bugchecks the system on load.

Signed drivers containing the backdoor were not provided with the PoC.

 

What ever drivers you provided via the download, were not signed that I could see. And what is the purpose of not including the backdoor in a PoC. It really isn't a PoC then in my mind.

 

So what you are saying is running the .exe never loaded any drivers? Or does anything malicious from what I can tell. So any security product that detected the .exe from execution behavior is a false positive.

I did see in the source code where HelpDetectW2 driver would be loaded.

 

If a HelpDetectWz driver is loaded, the .exe will when passed a device name to use and a driver path, will make a call to an ioctl exposed by HelpDetectWz which will load the driver.

 

OK, so you need a signed driver in order to load additional unsigned drivers on the system? I wonder if HIPS will block this, normally speaking HIPS will alert about drivers being loaded by running processes.

 

https://www.theregister.co.uk/2016/09/23/capcom_street_fighter_v/
https://packetstormsecurity.com/fil...om.sys-Kernel-Execution-Exploit-x64-only.html

 

OK, but if you block the first driver from loading with HIPS, it can't load additional malicious drivers. It would have been scarier if apps could bypass HIPS to load any driver they want.

 

The point of the POC was to show its possible to load an unsigned kernel malware driver from a valid signed kernel driver. I guess that is not "earth shattering" since a kernel driver can do whatever it wants. No HIPS driver protection will be able to block this activity.

Your best protection against crap like this would be on a freshly installed Win 10 rel. 1607 OS since all kernel drivers there need to be signed with a special Microsoft code signed certificate.