When a false positive is a true positive: Microsoft inadvertently signs a malicious driver

Microsoft is aware and investigating as of June 26th, 2021. Currently, only gamers in China are negatively impacted. Nevertheless, this is an example of how established processes and systems designed to detect bad actors cannot be solely relied on.

What Is It?

Approximately a week ago, systems at long standing security vendor G DATA advised them of a possible false positive detection of a driver called Netfilter. The system identified this file as a possible false positive as it was digitally signed legitimately by Microsoft. Review by G DATA analysts determined it was not a false positive, the sample was in fact malicious. Microsoft were immediately informed and are still investigating; however, they have stated that it appears the driver was submitted for signing via the legitimate process.

Microsoft Windows can run code in two different modes, user mode and kernel mode, in general applications run in user mode and critical operating system code runs in kernel mode. Many drivers require kernel mode to function. Given that all kernel mode code runs together, not isolated like user mode code, any issues with kernel mode drivers can result in a system crash. Therefore, beginning with Windows Vista, Microsoft mandated that any drivers needing to run in kernel mode are required to be submitted for testing and digital signing. In the normal course of events, unsigned kernel mode drivers will not be loaded by Windows Vista and later versions of Windows.

There have been examples of private keys for code signing certificates being stolen and used to sign malware. Most famously, the Stuxnet malware which destroyed centrifuges in Iranian nuclear facilities, were signed with certificates from Taiwanese companies Realtek, and JMicron, without their knowledge. Digitally signing of software, not just drivers, is commonplace and is intended to reassure the user the software is genuine and has not been tampered with. However, despite a digital signature from Microsoft,  essentially being the top of the trust hierarchy, this case is an excellent example that the presence of a valid digital signature, is in no way the only factor to consider when determining whether a given sample is legitimate or malicious. However, to most users, a digital signature from Microsoft is a guarantee of a file’s validity, and it usually is.

After discovering the Netfilter driver sample, G DATA identified an associated dropper sample, and an older driver sample. The dropper sample is basic, placing the Netfilter driver into the user’s AppData directory and registering it with the system. The driver connects to a hardcoded Command and Control (C2) server, located in China, and receives a configuration string consisting of additional URLs used to receive further settings. The primary function of this driver is IP address redirection, a list of approximately 350 IP addresses are redirected to a single IP address located in China. The Microsoft Security Response Center (MSRC) released a blog entry stating the malicious driver distribution is limited to gamers in China and is used to “spoof their geo-location to cheat the system and play from anywhere” and “to gain an advantage in games”. The PDB path of the driver, which is used when debugging, contains two Chinese characters, which translate to “source code”, indicating it was written by a native Chinese speaker. The MSRC blog further explains an attacker would also require administrative privileges on a system prior to being able to install this driver.

There have been various supply chain breaches already this year, this is an example that there can still be issues in the legitimate supply chain process, without the direct involvement of malicious actors. It is also a reminder that whether code is digitally signed, or not, is only one factor to be considered when determining the legitimacy of a given sample – malicious code can be validly signed and unsigned code can be legitimate.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. The malicious driver is circulating in the gaming community, in China. Aside from a dropper being identified, the attack vector is not currently known.

When/How Did BluVector Detect It?

The two Netfilter driver samples and the dropper sample referred to in the G DATA report are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected them all. Regression testing has shown the samples would have been detected an average of 62 months prior to their release.

All Threat Reports