A few months ago on this blog I described PowerLoader functionality including an interesting way for privilege escalation into the explorer.exe system process. The leaked PowerLoader code is also used in other malware families. For example the Win32/Gapz dropper is based on leaked PowerLoader code. In August 2013 we have tracked a new modification of PowerLoader for 64-bit operating systems (detected by ESET products as Win64/Vabushky.A). This modification uses three exploits for local privilege escalation (LPE): MS13-053 (CVE-2013-3660), MS12-041 (CVE-2012-1864), and MS12-042 (CVE-2012-0217). Use of this set of LPE exploits was not previously observed in PowerLoader samples or by related malware families.

Win64/Vabushky is a good example of how cybercriminals update their projects with code based on leaked Carberp sources. Two 64-bit exploits (CVE-2012-1864 and CVE-2012-0217) from the updated PowerLoader update are based on the leaked code. Before this leak into the public domain, 64-bit exploitation code for these vulnerabilities was not available. It’s also worth noting that the PowerLoader code was leaked in April 2013 and initiated the wave of distribution of droppers based on PowerLoader leaked code.

The dropper for Win64/Vabushky is packed by MPRESS because this packer is one of the few free products that support x64 PE32+ files. After unpacking, the dropper extracted the original PE32+ header with the time of compilation:

All binaries include a payload compiled at the beginning of August, according to time stamp data. PowerLoader’s export table  also shows a few changes after unpacking when compared to the older version:

The most interesting part of latest changes provided concern the exploitation code for local privilege escalation.

LPE exploits update

After code injection into explorer.exe the modified version of PowerLoader tried to execute following local privilege escalation exploits into trusted process address space:

This set of LPE exploits can bypass some types of sandbox technologies used by security products. This is because direct manipulation of some kernel-mode structures is possible from user-mode using legitimate WinAPI calls.

CVE-2013-3660

Google researcher Tavis Ormandy discovered the MS31-053 vulnerability in March and exploitation details were disclosed in May. The patch only became available with July’s patch Tuesday. Before this modified version of PowerLoader, I hadn’t seen a 64-bit version of MS13-053 exploit in-the-wild. Only an x86 version of proof of concept code has been seen made available publicly, but PowerLoader uses 64-bit exploitation code. There is a good description of the way in which this vulnerability is exploited in the VUPEN blog.

Before the start of the exploitation process a second desktop is created for hiding visible artifacts by manipulating GDI objects.

The main exploitation code for CVE-2013-3660 is presented in the following figure:

The shellcode which executed by nt!NtQueryIntervalProfile() looks like this:

This exploitation code does not work for the 64-bit MS Windows 8 platform because it cannot bypass the Intel SMEP (Supervisor Mode Execution Protection) technology in modern CPU’s (for which support has been provided since the Ivy Bridge line of processors). Microsoft only started to support SMEP with Windows 8 and upwards. This technology blocks attempts to execute code from user-mode memory pages into kernel-mode. A good description of Intel SMEP as exploit protection technology can be found here. The SMEP technology in Windows 8 for x64 can be bypassed using a ROP (Return-Oriented Programming) technique. However, Intel announced the new protection technology SMAP (Supervisor Mode Access Prevention). Intel’s SMAP blocks attempts to read memory pages from user-mode into kernel-mode. SMAP and SMEP were developed to prevent exploitation of NULL pointer dereferences in kernel-mode but SMAP is not supported in Microsoft operating systems yet.

CVE-2012-0217 and CVE-2012-1864

The CVE-2012-0217 and CVE-2012-1864 exploitation code is based on leaked Carberp sources. The 64-bit versions of CVE-2012-1864 had never been made public before the source code leakage. The exploitation code for CVE-2012-0217 released on public doesn’t work reliably on 64-bit versions of operating systems. Neither exploit will work on Microsoft Windows 8 because of the restricted vulnerability of the platform. After observing the similarity to leaked Carberp source code I checked compiled exploit binaries found in the leaked archive. In both compiled exploits I found the same path to the build directory.

This finding points to the same developer and seller for these exploits. The exploitation code for CVE-2012-0217 is different in many respects to the publicly available Proof of Concept exploits. The leaked exploit works more reliably and supports 64-bits operating systems.

I’m going to check similarities in the code from the PowerLoader modification and the leaked exploit for CVE-2012-0217. The following flow graph shows the similarity of basic structural blocks (PowerLoader code on the left side):

It looks to be pretty much the same structure. All the differences are found only in additional debugging code which is not included in PowerLoader modification. Also there are some specific techniques for making the exploitation more stable that look exactly the same.

This code provides modifications in nt!HalDispatchTable for avoiding 100% CPU activity with multiple threads in exploitation process.

The same thing was found with exploitation code for CVE-2012-1864 vulnerability. This exploit has never before been publicly available either. CVE-2012-1864 was discovered by Tarjei Mandt from Azimuth Security. The vulnerability details were disclosed on the slides “Smashing the Atom” at the Recon conference in June 2012 but exploitation code was not released to the public. The exploit code from PowerLoader looks more optimized and doesn’t have debugging code with console output. For example, as seen in this code (disassembly code from PowerLoader is the second image):

CVE-2012-0217 and CVE-2012-1864 are good examples of exploits that make it possible to bypass sandboxes in security software. Both of these exploits can manipulate kernel-mode structures from user-mode using standard WinAPI functions. A nice description of vectors for bypassing sandboxes using these types of vulnerabilities is presented in the research report “Application Sandboxes: A Pen-Tester’s Perspective” by Bromium Labs.

The Payload

After successful PowerLoader execution and privilege escalation, the ransomware (Win64/Vabushky.A) was downloaded in order to infect the system. Earlier this week my colleague Jean-Ian Boutin discussed another example of ransomware in the blog post “Nymaim – Obfuscation Chronicles”. The downloaded file was executed once escalated privileges were achieved to SYSTEM. The Win64/Vabushky installer uses the trick with a self-generated legitimate certificate and the following installation to the local trust store as a ROOT CA and TrustedPublisher. The following code shows this technique:

This trick is not new and was mentioned in the blog post “The “Hikit” Rootkit: Advanced and Persistent Attack” by Mandiant. Also, during the installation process modifications are made to Boot Configuration Data (BCD) so as to activate test-signing policy for loading the unsigned driver module. The next figure presents registry keys with system configuration to allow the malicious driver to load (safeboot with various options is covered too):

The next steps are to install the malicious driver for locking the system and displaying a demonstration screen with the picture downloaded from the following URL’s, hardcoded into malicious code:

After successful infection the locked desktop screen looks like this:

The user-mode part of Win64/Vabushky also encrypts the user’s files using the Microsoft CryptoAPI and uses the .crypted file extension for encrypted files. The driver code uses standard tricks for locking that don’t merit further discussion in this blog.

Conclusion

The Win64/Vabushky dropper uses an interesting modification to the PowerLoader code. However the PowerLoader modifications are based on leaked LPE exploits for 64-bit operating systems from Carberp code. All modules and components dropped by Win64/Vabushky target x64 versions of Microsoft Windows. Only one exploit, CVE-2013-3660, can attack MS Windows 8. However the exploitation code does not work for the 64-bit version of Windows 8 because it can’t bypass Intel SMEP technology. Microsoft is implementing better kernel-mode protection on Windows 8, making x64 exploits for this operating system more expensive. These security mechanisms can be bypassed in such cases with targeted attacks but this adds up to an expensive exploitation technique for run-of-the-mill cybercriminals.

Special thanks to R136a1 who reported the new modification of PowerLoader.

Aleksandr Matrosov, Security Intelligence Team Lead

SHA1 hashes for analyzed samples:

Win64/Vabushky.A (dropper)        – 110e23ce497d6cd1fd3dc570e50cd701c612b7ba

Win64/Vabushky.A (driver installer)    – 62a53ff68d1c862c9c68fb577b06fa261ef573e4

Win64/Vabushky.A (driver)        – 9434792df305f59a7b9deb99dd8b2617942513b0