Malware Analysis: A Kernel Land Rootkit Loader for FK_Undead

Before the rootkit's loader functionality is executed, it first must be installed as a system service. According to VirusTotal, the rootkit loader is dropped and installed by a malicious executable disguising itself as “Microsoft Foundation Applications” [F2]. The dropper places the rootkit loader into “C:\Windows\System32\drivers\ws3ifsl.sys” [P1] and registers it as a system service in user mode [P2]. The name “ws3ifsl” is probably chosen to disguise itself as Winsock2 IFS Layer (ws2ifsl.sys) which is a legitimate Windows utility for socket communication.  

Once the driver is executed, it first moves itself from “C:\Windows\System32\drivers\ws3ifsl.sys” [P1] to “C:\ProgramData\Microsoft\Windows\EventStore.dat” [P3]. Afterwards, it deletes the old service “ws3ifsl” and registers a new system service called “EventStore” pointing to the new location [P3] (see Figure 1). However, this time the service is configured to be loaded as kernel driver with “Type” equals “1”. This is most likely done to prevent users from detecting the service in the Windows Task Manager or Services overview.  

Since traditional automated sandbox systems are usually not capable of triggering the functions of a kernel driver, we employ Mandiant’s speakeasy emulator instead. The tool allows us to capture memory accesses to extract the plain strings protected by VMProtect and create memory dumps. We increase the default emulation timeout from 60 seconds to 10 minutes:  

speakeasy -t <payload> -q 600 -d <results>.zip -o <report>.txt  

After speakeasy emulated all 15 API calls to the kernel interface “ntoskrnl.exe“, we find several interesting strings. Among them are four URLs which point to an HTTP address containing the uncommon port 38005 [U1-4]. At the time of publication of this blog post the domains are not registered anymore. The URLs [U1-2] previously hosted the file [F3] and the URLs [U3-4] served the file [F4]. The files [F3-4] contain a base64-encoded blob which turn out to be deaddrops with random-looking bytes in the front and an HTTP URL at the end. As shown in Figure 2 the deaddrops only differ in the URL paths [U5-6] which host the encrypted second stage payload that belongs to the FK_Undead malware family.   

The driver uses different deaddrops and FK_Undead payloads depending on the Windows version. It determines the Windows version by calling the system routine “RtlGetVersion” or alternatively the deprecated function “PsGetVersion”. If the Windows version number is equals to 10.0 it will download the deaddrop “auth.bin” [F3] from URL [U1] otherwise “auth7.bin” [F4] from URL [U3] to “C:\ProgramData\Microsoft\Windows\Templates.log” [P4]. If the download fails, it tries to fetch the deaddrop from URL [U2] or [U4]. Once the download finishes, it decodes the base64 blob and decrypts the first 16 bytes with AES-128. While the AES key (”0XMTXKEDTNLDKADSLIOKJASDF”) is 25 bytes long, only the first 16 bytes are used in the AES key expansion step.  

The content and structure of the decrypted deaddrop file is visualized in Figure 3. It consists of a begin and end marker, two delimiters as bytes “0D 0A”, an eight bytes long seed and the URL to the FK_Undead payload. After parsing the deaddrop‘s file, the rootkit loader downloads the payload “txlsddlx64.dat” [F5] or “txlsddlx64_7.dat” [F6] and stores it in the Windows program data folder with a filename derived from a fingerprint based on the machine GUID and the fixed-size seed.  

After the payload is downloaded successfully, the rootkit loader decrypts it by inverting every bit (see Figure 4).

The payload is once again a signed driver protected with VMProtect [F7-8]. We identified the sample as a variant of the FK_Undead malware family. As already described in previous blog posts, it routes user traffic via attacker-controlled servers using PAC (Proxy auto-config).  

Subsequently, the rootkit loader registers the FK_Undead driver as a new system service using the same function as for the EventStore service but with the generated fingerprint as DisplayName and filename in the ImagePath (see Figure 5).   

The rootkit loader takes several measures to disguise itself from being detected.  First, it checks if files related to PC Hunter (pchunter64as.sys) or Windows Kernel Explorer (WIN64AST.SYS) exist on the system. If this is the case, it will just abort.  
Additionally, it scans if drivers from VMWare (vmci.sys, vmmouse.sys, vmrawdsk.sys) or VirtualBox (VBoxGuest.sys, VBoxMouse.sys, VBoxSF.sys, VBoxWddm.sys) are present. However, the rootkit loader does not apply any mitigation if any of the files are found. Moreover, we found an unused function sub_180016DD0 which checks if an Internet connection is available by downloading a file from an attacker-controlled server [U7-8] and saving it to “C:\ProgramData\Microsoft\Crypto\RSA\connect.dat” [P11] (see Figure 6). Unfortunately, we were not able to get the files because the domain is not registered anymore.