Analysis of Rovnix Dropper 5/5 - Driver and Bootkit Installation

In the final post on the my analysis of the Rovnix dropper, I will document how the sample install drivers and bootkits.

After achieving HIGH integrity as documented in the previous post, the sample will first terminate its parent process which is likely to be the sysprep.exe process.

Next, the sample check for the use of volume encryption application such as Bitlocker and Truecrypt.

Then the sample checks if it has sufficient privileges (SeLoadDriverPrivilege and SeShutdownPrevilege)

With sufficient previleges, the sample will now load and install the driver as a service. The service name is created with the string "BS" concat with the volume ID of the HDD of the victim machine.

After installing the NotMyFault driver, the bootkit will be injected next.

A x64 driver payload would be decrypted first.

Next, the modified Initial Program Loader (IPL) in the Volume Boot Record (VBR) would be decrypted

Then both these payloads would be injected into the HDD sectors

The driver payload would be written into sector 0x1600 (5632)

The IPL of the VBR is overwritten.

The driver payload and the IPL modification is now completed! The Rovnix dropped will cause a BSOD via the NotMyFault driver.

This concludes the long over due blog posts on my analysis of the Rovix dropper. I hope to document how the dynamic analysis from the execution of the modified IPL to the loading of the driver payload.

Analysis of Rovnix Dropper 4/5- Bypassing UAC

In the first post, I mentioned that the sample always caused a BSOD after execution. The BSOD was due the execution of the Sysinternals tool, NotMyFault. In this post, I will cover how NotMyFault was installed and executed by the sample.

The sample works for both x86 and x64 Windows environments. In x64 Windows, drivers had to be signed before they could be loaded and executed. NotMyFault was actually signed a driver that was signed by Sysinternals. This driver was considered legit and would be loaded by Windows x64.

However, the sample could not load drivers directly as it had only MEDIUM integrity. The User Access Control (UAC) would prompt users to ask for permission to load and install the driver. To bypass UAC the sample executed the following 4 steps.

1. Write a modified cryptbase.dll into the temp directory.
2. Pack the modified cryptbase.dll into cryptbase.msu using makecab.exe
3. Extract cryptbase.msu into C:\Windows\system32\sysprep using wusa.exe
4. Execute C:\Windows\systems32\sysprep\sysprep.exe using command promp

As a result of the UAC bypass technique, the modified cryptbase.dll was used to execute the sample again with HIGH integrity to load and install the NotMyFault driver.

Details on the UAC bypass technique could be found in this blog post by Parvez Anwar.

Next, I would document how cryptbase.dll was modified and then trace the modified code to execute the sample with HIGH integrity.

The sample would have to decode a blob of codes required to overwrite into cryptbase.dll

A loop to locate the .rsrc section in the cryptbase.dll was executed.

The strings and function addresses required were also written into cryptbase.dll.

The Address of Entry Point (AOE) was also updated to point to the start of the .rsrc section.

Finally the checksum was also calculated and updated into the PE header of cryptbase.dll

The following is the PE header of the original cryptbase.dll note its AOE.

Next is the modified cryptbase.dll with a different AOE.

After looking at how cryptbase.dll was modified. Let us trace how the modified cryptbase.dll was used to load and install the NotMyFault driver. Do note that the cryptbase.dll was loaded by sysprep.exe. I used the x64dbg debugger to debug sysprep.exe in Windows x64.

Inside the DLL entry point of cryptbase.dll is a loop to locate the virtual address of the .rsrc section.

Next a indirect call was made to the CreateThread function to start a new thread.

Finally, inside the new thread the CreateProcess function was called. The function created a new process using the sample path and an argument of "2"

Now the sample runs at HIGH integrity and it is ready to do some really nasty stuff!

In the next and final post of the series on analysing Rovnix dropper. I will copy how the NotMyFault driver was load and executed. I will also document how the Bootkit is inserted.

Analysis of Rovnix Dropper 3/5 - Anti Analysis (Static & Dynamic)

In the previous post, I described how I unpacked the sample. In this post, I will focused on the anti analysis techniques used by the sample. I will first touch on the anti static analysis then the anti dynamic analysis.

After the sample was unpacked, I noticed a number of strings were still obfuscated.

The strings were de-obfuscated into strings containing names of various security products during runtime:

I did not found other anti static analysis techniques such as anti-disassembly. However, I notice quite a few anti dynamic analysis techniques.

First, was a common anti VM technique to detect the use of VMware. The sample sent the VMware magic value of "VMXh" into the "VX" port using the 'IN' instruction. By reading and comparing the reply from the port the sample could detect the use of VMware.

Next, was a less common anti VM technique to detect the use of VirtualBox. The less common "VPCEXT" instruction was executed to detect the use of VirtualBox.

Then to detect the use of debuggers the "BeingDebugged" flag is checked in the PE.

Next to check for the use of various tools for instrumentation. The name of the parent process of the sample is compared against a fix list of strings.

The sample also created multiple threads to carried out its activities. The use of multi threading brought a little hurdle to overcome when debugging the sample.

All in all the sample did not make use of many anti analysis techniques. In the next post, I will cover how the sample escalated its privilege to install a driver in x64 Windows.

Analysis of Rovnix Dropper 2/5 - Unpacking

In the previous post, I documented how I begin with the analysis of the Rovnix dropper and I concluded with the guess that I am dealing with a packed binary. In this post I showed how I unpacked the sample.

I begin by setting a breakpoint at 0x402038 which was contained a dynamic call.

From Ollydbg, I observed the address 0x3AEE590 is located in the heap and the access rights was set to RWX. At this point, the sample is unpacked yeah \o/.

After I dumped out the 'unpacked' heap memory segment and fixed the IAT. I import the 'unpacked' memory segment into IDA Pro. I noticed no strings pointing the URL that I obtained from FakeNet and no APIs were imported for accessing the internet. I guessed the sample is not unpack completely. :(

I tried to let the execution of the sample continue hoping to see the RWE memory segments created by the unpacker codes but I end up with BSOD.
I tried to hook the VirtualAlloc and HeapAlloc APIs to catch the sample dumping the unpacked binary.

Both options failed :( I guess I can only TRY HARDER!

At this point I knew, there was no short cut. I try to figure out what are the code in the heap memory segment doing. Then I noticed this:

Both the .text and .rdata sections of the binary(SUPERRAM) were set to RWE. The original memory access to these two sections were R_E not RWE. Now I understand how my hook attempts failed. The unpack was making using of SELF Modifying code. Next I set a hook at VirtualProtect and run the binary again. I noticed how the .text and rdata sections were changed from R_E to RWE.

Now, I went back to IDA Pro to look at the CFG of the heap memory segments there was no import function of VirtualProtect. WHY ? This was due to a 'trick' used by the author of the binary. It used an indirect call access to VirtualProtect API via a function table that was pre-populated with function addresses.

Finally, I located an indirect call that goes to the unpacked code!

Finally after fixing the IATs and executing a few functions to decode the strings, I could now dump the unpacked binary. I can now see the URL being accessed and the APIs used to access Internet.

YES finally the binary is unpacked! \o/

Next, I will cover some of the anti analysis techniques used by the sample.

Analysis of the Rovnix Dropper 1/5 - Information Gathering

This post is the first of the 5 post series on  how I analysed the Rovnix dropper.

Analysis of the Rovnix Dropper 1/5 - Information Gathering

Analysis of Rovnix Dropper 2/5 - Unpacking

Analysis of Rovnix Dropper 3/5 - Anti Analysis (Static & Dynamic)

Analysis of Rovnix Dropper 4/5- Bypassing UAC

Analysis of Rovnix Dropper 5/5 - Driver and Bootkit Installation

I always begin with static analysis of the binary sample. I would acquire information such MD5 and SHA1 hash of the sample. I would also need to know what sort of binary am I dealing with, for example, PE,ELF,.dot NET, or office documents. For this I would use CFF Explorer.

Usually at this point, if possible I would do a Google search using the hash values to check if the sample had been analysed. As this sample is pretty old (2015), there were much information related to the sample. From CFF Explorer, I knew I am likely dealing with a PE binary written using C++.

Knowing that I am dealing with a PE binary, I would use PE Studio to determine what the sample does, for example does it connect to internet, download/upload files or collect information from the victim machine. I would also like to know if the binary is packed.

From PE Studio, I could not tell much information about the sample. There are only a few dlls being imported by the sample. There was a large number of strings but I could not see any URLs.

Next, is the dynamic analysis phase. I will try to execute the sample in a VM with Sysmon and FakeNet running in the background. I could see some URLs being accessed by the binary via FakeNet. However, before I could take a closer look at the URLs the infamous BSOD happened.

BSOD happened every time after running the sample I also tried to run it in a different VM and also Virtualbox.

From FakeNet, it show a URL being accessed after the binary was executed. Some information related to the victim machine was also being uploaded to the URL.

At this point, I am certain the sample will upload information gathered from the victim machine to a fixed URL. However, from the strings dumped using PE Studio, there was nothing related to the URL. In addition, PE Studio also did not showed any APIs that could be used to access internet.
I guess the sample is packed. I opened up the sample in IDA Pro and I am greeted with this long WinMain() that seemed to be drawing dialog boxes.

I scrolled through WinMain() and it ended this interesting dynamic call instruction.

In the next post, I would document how I unpacked the sample using Ollydbg. :)