A few months ago we wrote about PowerLoader. This malicious code uses an interesting method of privilege escalation in the context of explorer.exe. The PowerLoader source code that has been made available to the public is also used in other families of malware. For example, Win32/Gapz bootkit droppers are based on this PowerLoader code. In August, we discovered a new modification of PowerLoader for 64-bit OS (detected by ESET as Win64/Vabushky.A). This modification uses three exploits to raise its privileges in the system (Local Privelege Escalation): MS13-053 (CVE-2013-3660), MS12-041 (CVE-2012-1864), and MS12-042 (CVE-2012-0217). The use of such exploits has not previously been observed in PowerLoader samples or related families. Alexander Matrosov performed an analysis of this malware. The Win64/Vabushky
malware is a good example of how quickly attackers update their projects using the Carberp source code. Two 64-bit exploits (CVE-2012-1864 and CVE-2012-0217) from the new PowerLoader are based on the Carberp source code. It is also worth noting that the PowerLoader code, which became available to the public in April 2013, provoked a new wave of distribution of droppers based on it.
Win64/Vabushky droppers are packaged using MPRESS, since this packager is one of the few freely distributed products that supports 64-bit PE32+ files. After unpacking, the dropper extracts the original PE32+ header with compilation times as shown below.
All files include the payload compiled in early August. In the export table for this version of PowerLoader you can see the changes compared to the older version.
After injecting the code into explorer.exe, PowerLoader attempts to execute the following exploits in the context of trusted processes.
A similar set of exploits can be used to bypass certain types of sandboxes used in security products, since these exploits involve direct manipulation of kernel objects from user mode using legal Win32 APIs.
CVE-2013-3660
In March, Google Security Team researcher Tavis Ormandy (@taviso) discovered CVE-2013-3660, which was patched in July bulletin MS13-053. We have not seen a 64-bit version of this exploit until the new PowerLoader modification, while the PoC x86 version is available to the public.
Before actual exploitation, the exploit code creates a second desktop object ( user32!CreateDesktopA ) to hide the fact of working with GDI objects.
The basic operating code is shown in the figure below.
The shellcode that is executed using nt!NtQueryIntervalProfile looks like this.
This exploit code does not work in 64-bit Windows 8, since it is not able to bypass Intel SMEP (Supervisor Mode Execution Protection) hardware technology, which the new OS software supports. SMEP blocks execution of user address space code pages in kernel mode and can be bypassed in 64-bit Windows 8 using ROP. However, Intel has already announced another security technology, SMAP (Supervisor Mode Access Prevention), which introduces additional restrictions on access to memory pages. Both SMAP and SMEP are designed to prevent exploitation of the NULL pointer dereference vulnerability in kernel mode, but SMAP is not yet supported on Windows.
CVE-2012-0217 and CVE-2012-1864
The exploit code for these vulnerabilities is based on the leaked Carberp source code. We did not observe 64-bit versions of CVE-2012-1864 ITW before the Carberp texts became available to the public. The exploit code CVE-2012-0217, which is publicly available, does not work stably on 64-bit versions of the OS. After inspecting the executable exploit files in the Carberp texts, it was determined that they contained the same path to the build directories.
This suggests that the exploits were developed on a single system and possibly by a single person. The CVE-2012-0217 exploit code differs significantly from the publicly available PoC that demonstrates the exploitability. The version of the exploit from the Carberp texts is more stable and supports 64-bit OS. Below are the matches in the code blocks of these versions of the exploit for CVE-2012-0217 (code from PowerLoader is shown on the left).
At first glance they seem very similar. The main differences are found only in the additional debug code, which is not included in the PowerLoader modification. In addition, it has several methods to make operation more stable.
This code provides modification to nt!HalDispatchTable in order to avoid 100% CPU utilization by multiple threads during operation.
The exploit for CVE-2012-1864 was also not publicly available until the release of the new PowerLoader modification. The vulnerability itself was discovered by Tarjei Mandt (aka @kernelpool) from Azimuth Security. Details of the vulnerability were made public in his talk "Smashing the Atom" at RECon in June 2012, but the exploitation code was not released to the public. The exploit code from PowerLoader looks more optimized and does not contain any debugging information. Below you can see the differences in different versions of this exploit, the second screenshot shows the version from PowerLoader, which does not output debugging information.
Both of these exploits for CVE-2012-0217 and CVE-2012-1864 vulnerabilities are good examples of bypassing the sandbox mode in security products. Exploits are able to manipulate kernel mode objects from user mode using standard WinAPI. A good description of how to bypass sandboxes using these types of vulnerabilities is presented in the presentation "Application Sandboxes: A Pen-Tester's Perspective" .
Payload
After successful execution of the PowerLoader code and elevation of privileges, ransomware Win64/Vabushky.A is downloaded to the user’s computer. The ransomware file is executed after the loader has raised the current privileges to maximum, i.e. SYSTEM. The Win64/Vabushky dropper uses a trick with a legitimate self-generated certificate and its subsequent installation in local storage as a root target, i.e. ROOT CA and TrustedPublisher. The following code demonstrates this technique.
This trick is not new and was already mentioned in Mandiant’s analysis “The “Hikit” Rootkit: Advanced and Persistent Attack” . Additionally, during the installation process, the malicious code modifies the Boot Configuration Data (BCD) to enable test-signing mode, which allows unsigned drivers to be loaded. The following figure shows the registry sections into which the driver is installed.
The next step is to install a malicious driver on the system to block the system and show the screen with a specific cover image, which is downloaded from one of the URLs hard-coded into the code itself.
After all the actions of the malicious program, the user receives a blocked desktop.
Win64/Vabushky encrypts user files using Microsoft CryptoAPI. After encryption, the extension .crypted is added to the file. The driver code uses standard screen locking techniques and is not worth discussing in detail.
Conclusion
The Win64/Vabushky dropper uses an interesting modification of the PowerLoader code. It uses LPE exploits for 64-bit OSes from the Carberp source code. All modules and components extracted by Win64/Vabushky are used specifically for the 64-bit version of Windows. In addition, CVE-2013-3660 can exploit the 32-bit version of Windows 8, which makes it universal. At the same time, due to limitations of Intel SMEP and its support in Windows 8, the exploit code cannot work for the 64-bit version of the OS. Thus, Microsoft's efforts to provide additional security mechanisms in Windows 8 are truly justified in protecting the user from exploits.
(c) https://habr.com/ru/companies/eset/articles/191904/
malware is a good example of how quickly attackers update their projects using the Carberp source code. Two 64-bit exploits (CVE-2012-1864 and CVE-2012-0217) from the new PowerLoader are based on the Carberp source code. It is also worth noting that the PowerLoader code, which became available to the public in April 2013, provoked a new wave of distribution of droppers based on it.
Win64/Vabushky droppers are packaged using MPRESS, since this packager is one of the few freely distributed products that supports 64-bit PE32+ files. After unpacking, the dropper extracts the original PE32+ header with compilation times as shown below.
All files include the payload compiled in early August. In the export table for this version of PowerLoader you can see the changes compared to the older version.
After injecting the code into explorer.exe, PowerLoader attempts to execute the following exploits in the context of trusted processes.
A similar set of exploits can be used to bypass certain types of sandboxes used in security products, since these exploits involve direct manipulation of kernel objects from user mode using legal Win32 APIs.
CVE-2013-3660
In March, Google Security Team researcher Tavis Ormandy (@taviso) discovered CVE-2013-3660, which was patched in July bulletin MS13-053. We have not seen a 64-bit version of this exploit until the new PowerLoader modification, while the PoC x86 version is available to the public.
Before actual exploitation, the exploit code creates a second desktop object ( user32!CreateDesktopA ) to hide the fact of working with GDI objects.
The basic operating code is shown in the figure below.
The shellcode that is executed using nt!NtQueryIntervalProfile looks like this.
This exploit code does not work in 64-bit Windows 8, since it is not able to bypass Intel SMEP (Supervisor Mode Execution Protection) hardware technology, which the new OS software supports. SMEP blocks execution of user address space code pages in kernel mode and can be bypassed in 64-bit Windows 8 using ROP. However, Intel has already announced another security technology, SMAP (Supervisor Mode Access Prevention), which introduces additional restrictions on access to memory pages. Both SMAP and SMEP are designed to prevent exploitation of the NULL pointer dereference vulnerability in kernel mode, but SMAP is not yet supported on Windows.
CVE-2012-0217 and CVE-2012-1864
The exploit code for these vulnerabilities is based on the leaked Carberp source code. We did not observe 64-bit versions of CVE-2012-1864 ITW before the Carberp texts became available to the public. The exploit code CVE-2012-0217, which is publicly available, does not work stably on 64-bit versions of the OS. After inspecting the executable exploit files in the Carberp texts, it was determined that they contained the same path to the build directories.
This suggests that the exploits were developed on a single system and possibly by a single person. The CVE-2012-0217 exploit code differs significantly from the publicly available PoC that demonstrates the exploitability. The version of the exploit from the Carberp texts is more stable and supports 64-bit OS. Below are the matches in the code blocks of these versions of the exploit for CVE-2012-0217 (code from PowerLoader is shown on the left).
At first glance they seem very similar. The main differences are found only in the additional debug code, which is not included in the PowerLoader modification. In addition, it has several methods to make operation more stable.
This code provides modification to nt!HalDispatchTable in order to avoid 100% CPU utilization by multiple threads during operation.
The exploit for CVE-2012-1864 was also not publicly available until the release of the new PowerLoader modification. The vulnerability itself was discovered by Tarjei Mandt (aka @kernelpool) from Azimuth Security. Details of the vulnerability were made public in his talk "Smashing the Atom" at RECon in June 2012, but the exploitation code was not released to the public. The exploit code from PowerLoader looks more optimized and does not contain any debugging information. Below you can see the differences in different versions of this exploit, the second screenshot shows the version from PowerLoader, which does not output debugging information.
Both of these exploits for CVE-2012-0217 and CVE-2012-1864 vulnerabilities are good examples of bypassing the sandbox mode in security products. Exploits are able to manipulate kernel mode objects from user mode using standard WinAPI. A good description of how to bypass sandboxes using these types of vulnerabilities is presented in the presentation "Application Sandboxes: A Pen-Tester's Perspective" .
Payload
After successful execution of the PowerLoader code and elevation of privileges, ransomware Win64/Vabushky.A is downloaded to the user’s computer. The ransomware file is executed after the loader has raised the current privileges to maximum, i.e. SYSTEM. The Win64/Vabushky dropper uses a trick with a legitimate self-generated certificate and its subsequent installation in local storage as a root target, i.e. ROOT CA and TrustedPublisher. The following code demonstrates this technique.
This trick is not new and was already mentioned in Mandiant’s analysis “The “Hikit” Rootkit: Advanced and Persistent Attack” . Additionally, during the installation process, the malicious code modifies the Boot Configuration Data (BCD) to enable test-signing mode, which allows unsigned drivers to be loaded. The following figure shows the registry sections into which the driver is installed.
The next step is to install a malicious driver on the system to block the system and show the screen with a specific cover image, which is downloaded from one of the URLs hard-coded into the code itself.
After all the actions of the malicious program, the user receives a blocked desktop.
Win64/Vabushky encrypts user files using Microsoft CryptoAPI. After encryption, the extension .crypted is added to the file. The driver code uses standard screen locking techniques and is not worth discussing in detail.
Conclusion
The Win64/Vabushky dropper uses an interesting modification of the PowerLoader code. It uses LPE exploits for 64-bit OSes from the Carberp source code. All modules and components extracted by Win64/Vabushky are used specifically for the 64-bit version of Windows. In addition, CVE-2013-3660 can exploit the 32-bit version of Windows 8, which makes it universal. At the same time, due to limitations of Intel SMEP and its support in Windows 8, the exploit code cannot work for the 64-bit version of the OS. Thus, Microsoft's efforts to provide additional security mechanisms in Windows 8 are truly justified in protecting the user from exploits.
(c) https://habr.com/ru/companies/eset/articles/191904/
