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.
| URL | Purpose |
|---|---|
| hxxp://110.42.4.180:2081/p | Proxy settings |
| hxxp://110.42.4.180:2081/s | Redirection IPs |
| hxxp://110.42.4.180:2081/h? | Ping with CPU-ID |
| hxxp://110.42.4.180:2081/c | Root 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
| Description | SHA256 |
|---|---|
| [1] Netfilter driver | 63d61549030fcf46ff1dc138122580b4364f0fe99e6b068bc6a3d6903656aff0 |
| [2] Netfilter dropper | d64f906376f21677d0585e93dae8b36248f94be7091b01fd1d4381916a326afe |
| [3] Netfilter driver, older version signed in March | 115034373fc0ec8f75fb075b7a7011b603259ecc0aca271445e559b5404a1406 |
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