Friday, May 15, 2015

Rovnix Dropper Analysis (TrojanDropper:Win32/Rovnix.P)

The Win32/Rovnix family is known for its usage of a VBR based Bootkit in order to load itself before the Windows operating system starts to run.

In this post i am going to analyze a recent Rovnix dropper that is able to install its Bootkit component on a x86 and x86-64 Windows OS, the dropper contains at-least two previously known exploits in order to elevate its privileges on the system in case it doesn't have enough permissions to access the VBR.

This post will cover:

  • Environment info - Which information is sent by the dropper to the C&C server and where in the registry the dropper writes its configuration.
  • Anti-Analysis - The technique used by the dropper and the driver in order the detect sandboxes and to prevent the launching of analysis tools.
  • Bootkit installation preparations - Which steps the dropper takes in order to make sure it will be able to install the Bootkit component.
  • Payload - How the actual payload is installed in the system.
  • Code and Module storage - How and where the dropper stores the files and shellcode that it uses throughout the installation process.

The post will not cover:

  • Bootkit Installation - Since the actual process of installing the Bootkit inside the VBR seems to be very much the same as it was done in previous versions of Rovnix. The installation process of the Bootkit can be found in the Carberb source code leak.
  • VBR Analysis - I didn't analyze the infected VBR and the process of the driver loading.
The dropper sample that this post cover has hash value of:

You can download the sample and the various files extracted from it here (Password: infected), the archive contains:
  • Packed and unpacked sample
  • Extracted drivers (32 and 64 bit)
  • Extracted FJ sections (payload 32b)
  • Extracted payload (32 and 64 bit)
  • Downloaded payload (packed VT 2/57, unpacked VT 14/56)
  • Infected VBR

Environment info

When the dropper starts to execute it gather various information about the operating system, this information is used in order to generate Mutexes and Registry keys for the installation process.
The gathered information about the system is later sent to the C&C server.

The dropper retrieve the volume serial number using the GetVolumeInformation API and use this value throughout the installation process to create Mutexes and registry keys. 

The Registry key that is created and used to store various information that is related to the bot functionality is:
if the dropper has sufficient privileges it will create the key under HKEY_LOCAL_MACHINE.

The information that is stored under this key is used throughout the installation process by the dropper.
The payload use the same key in order to store more C&C addresses and plugin files in an encrypted form.
Information file path
As seen in the picture the LP value is used the store the path to a temporary file that stores the various information about the environment.
The content of this temporary file is later sent to the C&C server.


The Anti-Analysis features found in the dropper are used to grade the environment the dropper is running on.
Check the current process name and path
In addition to checking the process name and process path for suspicious strings the dropper runs various threads that perform known checks for the existence of the following tools\flags:
VMware, VirtualPC, WinICE/SoftICE, BeingDebugged flag (PEB).

If the dropper gets a positive results it increments the value of a global variable that its value is later sent to the C&C server.

Process list

The dropper send to the C&C server a list of all the running process with the information found in the Version Info (RT_VERSION) section of each process executable file.

The dropper contains a list of various vendors of protection software and AV programs and while the it iterates over all the process's Version Info sections is going to search for a match inside the list, if a match is found the matched string is going to be appended to a global string.

The dropper is going to inspect the global match string later in order to decide how to continue the installation of the Bootkit.

The list inside the dropper contains the following strings:
agnitum alwilsoftware pctools grisoft aviragmbh aviraproduct avirafreeantivirus bitdefender avginternetsecurity comodo doctorweb eset,spol esetsmart frisksoftware kaspersky pandasoftware symanteccorporation checkpointsoftware microsoftsecurity microsoftmalware mcafee bullguard novashieldinc cjscreturnilsoftware sophosplc quickhealtechnologies gdatasoftware beijingrising immunetcorporation k7computing sunbeltsoftware beijingjiangmin usbdisksecurity deepfreeze virus malware rootkit rapport

The same vendor list is used in the dropped driver inside the callback function registered using PsSetLoadImageNotifyRoutine.
The registered callback routine inspect the Version Info (RT_VERSION) resource of every loaded Image file, if it finds even one matc it terminates the new process (ZwTerminateProcess) thereby is able to prevent running most of the analysis and removal tools.
Driver search strings in RT_VERSION

Further inspection of the driver revealed that in addition to terminating suspicious processes it patch the code of the application in memory in order to prevent its execution. The patching process is done whether the loaded image is the actual application executable or one of its DLLs, The same patching happens even for drivers and kernel-mode DLLs (DllInitialize).

In-memory patch

Patched application (in-memory) view
I have examined only the x86 version of the driver, it seems that in the x86-64 version of the driver it is enough only to change the filename of the program you want to run in order to bypass the checks the driver is doing.

Bootkit installation preparations

Privilege escalation

Before the dropper starts to install the Bootkit component it checks if the token of the current process is elevated (On Windows XP it starts the installation process right away).

If the operating system is Windows Vista+ and the token is not elevated the dropper tries to exploits two local privilege escalation vulnerabilities in order to elevate the privileges of the process.

The dropper contains the CVE-2013-3660 and CVE-2014-4113 exploits, before the actual exploitation the dropper make sure that the version of the local win32k.sys file is vulnerable by acquiring the file last write time using the GetFileTime API.

The CVE-2014-4113 exploit is only executed on a 32bit systems.

Once the dropper has sufficient rights it checks that the environment is compatible with the VBR Bootkit.
Running exploits

Environment check

The dropper launch a thread that checks if there are any system level encryption tools, the thread starts by a querying the WMI service (using the COM interface) about BitLocker and checks if the C:\ driver is encrypted by BitLocker.

The thread continues by iterating over the process list and checks if there are any process name that equal to TrueCrypt.exe or VeraCrypt.exe.

If the dropper finds that there is system encryption software installed (or running) in the system or if the Windows version is 8, 8.1, Server 2008, Server 2008-R2, Server 2012, Server 2012-R2 it skips the Bootkit installation and continues to drop the payload module in the system.

After the checks is done the dropper starts the installation process of the Bootkit component.

Bootkit install

The Bootkit installation starts by dropping the driver part of the Sysinternals's NoMyFault program and creating a new service for it, once the installation of the bootkit is done the dropper will send an IoControlCode code to the driver in order to generate a BSOD and forcing a system restart.

The actual installation of the Bootkit seems to be very much the same as it is done (starts from the BkSetupWithPayload function) in the leaked source code of this Bootkit (The source code can be found inside the Carberp source leak).

If the installation of the Bootkit couldn't be completed because it can't find enough free space outside the system volume the dropper will run the Sysinternals's Contig tool in order to defragment the data, the dropper will run the tool with the following parameters:
 <tmpfilename.exe> -q -n <C:\Windows\System32\Boot.dat 0x3E800

After the defragmentation process the dropper will call the BkSetupWithPayload function again.

If the Bootkit installation finished successfully the dropper will try to generate a BSOD by sending an IoControlCode to the myfault.sys driver dropped previously.

If the installation of the Bootkit wasn't successful the dropper will install the payload module on the system.

Using the VFS.exe tool included in the Carberb source leak i was able to view the contents of the VFS:

VFS Content


The payload module is the component that Rovnix use in order to communicate with the C&C server and to download and run additional plugins.

Depending on which security software found in the system during the process list check the dropper is going to do either downloading a fresh payload from a url that is encoded inside or dropping the payload that is contained inside the dropper itself.

The downloaded payload seems to contains the same functionality as the payload that is dropped from the dropper however it is packed and has much less detection ratio (in this case the downloaded payload had only 2/57 detection ratio on VT)

Download fresh payload

If the dropper was able to install the Bootkit successfully the communication with the C&C server is done using a different payload module that is injected to a system process (svchost, winlogon, services, explorer), this payload module is stored inside the driver on a location named FJ.

The dropper contains both 32 and 64 bit versions of the driver and the payload module.

One of the differences between the payload that is installed by the dropper and the payload that is injected from the driver is that the payload from the dropper contains a thread that the payload runs in order to protect its persistence registry key, obviously this thread is not found in the payload  that is injected from the driver since it relays on the driver to achieve its persistence on the system.

Code and Module Storage

The dropper stores the code it injects and the files it drops onto the system as an aPlib packed blobs, the header of this blobs has one more field that is not found in the original aPlib source:


This Rovnix dropper uses the same VFS and driver that is found in the Carberb source leak with minor changes to the driver that gives it the capability to prevent the usage of various protection software. In fact i wasn't able to run the TDSSKiller tool (Kaspersky) designed to detect and remove this type of malware. It seems that on x86-64 version of the driver it is enough only to change the file name of the program in order to be able to run it on the system.

It seems that the threat actors behind this malware have used the Rovnix package as the basis for the actual malicious activity that is done using the plugins that the payload downloads.


  1. Anonymous15/5/15 18:14

    could you describe how to lad cve-2013-3660.bin into ida so it's possible to see it's functions?

    1. Write yourself a simple shellcode running tool that read the whole shellcode into an executable memory and starts execution of this memory. The first function inside the shellcode resolves all the APIs it needs (just import those into IDA).