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:
Author
Aleksandr Matrosov,