Reverse Engineering the Vanquish Rootkit – Part 1

• April 18, 2016

The first warning sign that we noticed in this snapshot was in the process for cmd.exe (this is for a Windows command line window). See below for a screenshot of the contents of this process:

In the screenshot you will see that WindowsSCOPE has detected a hidden module, which is shown selected in the screenshot. This was a module that has its name removed, which it most likely did to itself to attempt to avoid detection. Since this is very uncommon and suspicious, this module will be the place where we begin our investigation of the rootkit.

Taking a closer look at this hidden module, we will first look in its strings to look for clues to help figure out what the rootkit might be doing, or where to start looking next. See some of the strings from this module below:

The first thing we noticed here was that there were numerous references to “Vanquish”, so we can be fairly certain that this computer is infected with the Vanquish rootkit. There was also a handful of other useful hints in the strings, and this screenshot shows several of the most important ones. First, circled in red we see three debug statements that were left in the code. These three strings seem to indicate that the rootkit uses the LoadLibrary and FreeLibrary Windows API calls as a means of DLL injection. Next, we see a reference to the file “c:vanquish.log”. We won’t look at this file in this article, but it’s a point of interest and this log file contains more information about what the rootkit is doing (and many of the debug statements we see here in the strings can be seen in the log file). Lastly, we see the print statement “Replace API failed!”. This is a strong indicator that Vanquish may be hooking some Windows API functions.

The next place where we looked was the module’s export table. This table shows us the list of functions that this hidden module is providing for other modules to use. The export table is shown in the screenshot below:

The function names are strange looking strings, but you may notice they contain the names of some Windows API functions. In particular, you will notice the export that is circled in red, which contains the name “FindNextFileW”. Since we knew this function gets exported from kernel32.dll, we decided to look at the export table of kernel32.dll next.  See the screenshot of the kernel32.dll export table below:

After a quick look we found that everything appeared to be normal in the export table of kernel32.dll. We found the entry for FindNextFileW and it was pointing to code in the kernel32.dll module as it should be. So next we decided to look at the code that the entry pointed to. So we went to the code for kernel32.dll, switched to the investigate view, and then to the disassembled view tab. Then we navigated to the virtual address 0x77b6cb2d. See the screenshot of the code at this address below:

If you look at the code at the entry point for FindNextFileW, you’ll see a big problem – the instruction at the entry point is a jump. And taking a closer look at the destination of the jump instruction, it appears to be pointing to a completely different module, since the target of the jump is very far away from the jump instruction. As you probably already guessed, this instruction is jumping into the hidden module that we were just looking at.

With these discoveries we were certain that the machine we were looking at was infected with the Vanquish rootkit. We found an injected DLL, a hook that was inserted in the FindNextFileW API function, and numerous strings indicating that the injected DLL belonged to Vanquish. In part 2 of this article we will take you through the process we followed to use WindowsSCOPE to reverse engineer Vanquish and determine exactly how it uses this API hook to hide files from users and the operating system.