Microsoft signed a malicious Netfilter rootkit

06/25/2021
G DATA Blog

What started as a false positive alert for a Microsoft signed file turns out to be a WFP application layer enforcement callout driver that redirects traffic to a Chinese IP. How did this happen?

Last week our alert system notified us of a possible false positive because we detected a driver[1] named "Netfilter" that was signed by Microsoft. Since Windows Vista, any code that runs in kernel mode is required to be tested and signed before public release to ensure stability for the operating system. Drivers without a Microsoft certificate cannot be installed by default.

In this case the detection was a true positive, so we forwarded our findings to Microsoft who promptly added malware signatures to Windows Defender and are now conducting an internal investigation. At the time of writing it is still unknown how the driver could pass the signing process.

String decoding

The first thing I noted after opening the strings view are some strings that looked encoded or encrypted. While this is not necessarily a sign of a malicious file, it is odd that a driver obfuscates a part of their strings.

I decoded the strings using the following Python snippet.

 

def decryptNetfilterStr(encodedString):
	key = [9,0,7,6,8,3,1]
	i = 0
	decodedString = ""
	for ch in encodedString:
		decodedString = decodedString + chr(ord(ch) ^ key[i%7])
		i += 1
	return decodedString

 

 

Similar samples

Searching for this URL as well as the PDB path and the similar samples feature on Virustotal we found older samples as well as the dropper[2] of the netfilter driver. The oldest sample[3] signatures date back to March 2021. Virustotal queries to find similar samples via URL and PDB path are listed below.

 

content:{5c68656c6c6f5c52656c656173655c6e657466696c7465726472762e706462}
content:{687474703a2f2f3131302e34322e342e3138303a323038302f75}

 

Additionally the following Yara rule will find samples via retrohunting.

 

rule NetfilterRootkit : Rootkit x64
{
	meta:
		author = "Karsten Hahn @ GDATA CyberDefense"
		description = "Netfilter kernel-mode rootkit"
		sha256 = "115034373fc0ec8f75fb075b7a7011b603259ecc0aca271445e559b5404a1406"
		sha256 = "63D61549030FCF46FF1DC138122580B4364F0FE99E6B068BC6A3D6903656AFF0"
	strings:
		$s_1 = "\\??\\netfilter\x00" wide
		$s_2 = "IPv4 filter for redirect\x00" wide
		$s_3 = "\\Registry\\Machine\\SOFTWARE\\Microsoft\\SystemCertificates\\ROOT\\Certificates\\\x00"
		$s_4 = "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9\x0D"
		
		$url = "http://110.42.4.180:2080/u\x00"
		$pdb_1 = "C:\\Users\\omen\\source\\repos\\netfilterdrv\\x64\\Release\\netfilterdrv.pdb\x00"
		//RSDS [20] G:\<symbol>\hello\x64\Release\netfilterdrv.pdb
		$pdb_2 = {52 53 44 53 [20] 47 3A 5C E6 BA 90 E7 A0 81 5C 68 65 6C 6C 6F 5C 78 36 34 5C 52 65 6C 65 61 73 65 5C 6E 65 74 66 69 6C 74 65 72 64 72 76 2E 70 64 62}

	condition:
		any of ($pdb_*, $url) or
		all of ($s_*)
}

 

 

Dropper and installation

The dropper places the driver into %APPDATA%\netfilter.sys. Then it creates the file %TEMP%\c.xalm with the following contents and issues the command regini.exe x.calm to register the driver.

Command and control server

The URL hxxp://110.42.4.180:2081/u in the decoded string listing is the server of the rootkit. The Netfilter driver[1] connects to it for fetching configuration information.

After connecting to the hardcoded URL hxxp://110.42.4.180:2081/u the server replies with the following string.

Each URL has a specific purpose.

URLPurpose
hxxp://110.42.4.180:2081/pProxy settings
hxxp://110.42.4.180:2081/sRedirection IPs
hxxp://110.42.4.180:2081/h?Ping with CPU-ID
hxxp://110.42.4.180:2081/cRoot certificate
hxxp://110.42.4.180:2081/v?Self update

 

IP redirection

The core functionality of the malware is its IP redirection. A list of targeted IP addresses are redirected to 45(.)248.10.244:3000. These IP addresses as well as the redirection target are fetched from hxxp://110.42.4.180:2081/s.

Researcher @jaydinbas reversed the redirection configuration in this tweet and provided the latest decoded configuration in a pastebin. The general format as observed by @cci_forensics and @jaydinbas is [<redirection_target>-<port_number>]{<ip_to_redirect1>|<ip_to_redirect2>|...}

 

Update mechanism

The sample has a self-update routine that sends its own MD5 hash to the server via hxxp://110.42.4.180:2081/v?v=6&m=<md5>. A request might look like this: hxxp://110.42.4.180:2081/v?v=6&m=921fa8a5442e9bf3fe727e770cded4ab. The server then responds with the URL for the latest sample, e.g., hxxp://110.42.4.180:2081/d6 or with OK if the sample is up-to-date. The malware replaces its own file accordingly.

 

Root certificate

The rootkit receives a root certificate via hxxp://110.42.4.180:2081/c and writes it to \Registry\Machine\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\. The data that is returned from the server has the format [<certificate name>]:{<certificate data blob>}

Proxy

At hxxp://110.42.4.180:2081/p the malware requests the proxy which it sets as AutoConfigURL in the registry key \Software\Microsoft\Windows\CurrentVersion\​Internet Settings. The returned value at the time of writing is hxxp://ptaohuawu.bagua.com.hgdjkgh.com:2508/baidu.txt

Sample hashes

DescriptionSHA256
[1] Netfilter driver63d61549030fcf46ff1dc138122580b4364f0fe99e6b068bc6a3d6903656aff0
[2] Netfilter dropperd64f906376f21677d0585e93dae8b36248f94be7091b01fd1d4381916a326afe
[3] Netfilter driver, older version signed in March115034373fc0ec8f75fb075b7a7011b603259ecc0aca271445e559b5404a1406

 

More hashes related to the Netfilter rootkit are in this spreadsheet created by Florian Roth.

Contributions

Many thanks to all the contributors below.

Johann Aydinbas for the splendid analysis on Twitter

Takahiro Haruyama for additions to the analysis above

Florian Roth for the sample collection sheet and additional Yara rules

Karsten Hahn
Malware Analyst