PowerLoader 64-bit updated with new LPE exploits
A few months ago we wrote about PowerLoader . This malicious code uses an interesting privilege elevation method in the context of explorer.exe. PowerLoader sources that are publicly available are also used in other malware families. For example, the Win32 / Gapz bootkit droppers are based on this PowerLoader code. In August, we discovered a new modification of the PowerLoader for 64-bit OS (found 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.
Win64 / Vabushky malware is a good example of how quickly attackers update their projects using Carberp source code . Two 64-bit exploits (CVE-2012-1864 and CVE-2012-0217) from the new PowerLoader are based on 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 propagation of droppers based on it.
Win64 / Vabushky droppers are packed using MPRESS , as this packer is one of the few free products that supports 64-bit PE32 + files. After unpacking, the dropper retrieves the original PE32 + header with a compile time as shown below.
')
All files include a payload compiled in early August. In the export table of this version of PowerLoader, you can see the changes compared to the older version.
After implementing the code in explorer.exe, PowerLoader tries to execute the following exploits in the context of trusted processes.
Such a set of exploits can be used to bypass certain types of sandboxes (sandboxes) that are used in security products, since these exploits use direct manipulation of kernel objects from user mode using the legal Win32 API.
CVE-2013-3660
In March, a researcher at Google Security Team Tavis Ormandy (@taviso) discovered a vulnerability CVE-2013-3660, which was closed by the July bulletin MS13-053 . We did not observe the 64-bit version of this exploit until the new modification of PowerLoader appeared, while the PoC x86 version is available to the public.
Before directly exploiting, the exploit code creates a second desktop object ( user32! CreateDesktopA ) to hide the fact of working with GDI objects.
The main operating code is shown below.
The shell code that is executed using nt! NtQueryIntervalProfile looks like this.
This operating code does not work in 64-bit Windows 8, because it cannot bypass Intel SMEP hardware technology (Supervisor Mode Execution Protection), which the new OS software supports. SMEP blocks the execution of code pages of user address space in kernel mode and in the 64-bit version of Windows 8 can be bypassed using ROP. However, Intel has already announced another protective technology SMAP (Supervisor Mode Access Prevention), which introduces additional restrictions on access to memory pages. Both of these SMAP and SMEP technologies are designed to prevent the exploitation of a NULL pointer dereference vulnerability in kernel mode, but SMAP is not yet supported in Windows.
CVE-2012-0217 and CVE-2012-1864
The exploit code for these vulnerabilities is based on leaked Carberp sources. We did not observe 64-bit versions of ITE CVE-2012-1864 before the Carberp texts were made publicly available. The operating code CVE-2012-0217, which is publicly available, does not work stably on 64-bit OS versions. After inspecting the executable exploit files in the Carberp texts, it was determined that they indicated the same path to the build directories.
This indicates that the exploits were developed on one system and, possibly, by one person. The exploit code CVE-2012-0217 is significantly different from the publicly available PoC, which demonstrates the possibilities of exploitation. The version of the text exploit Carberp is more stable and supports 64-bit operating systems. Below are the matches in the code blocks of these versions of the exploit for CVE-2012-0217 (the code from the PowerLoader is indicated 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 modification of PowerLoader. In addition, there are several methods in it to make operation more stable.
This code provides a modification of nt! HalDispatchTable in order to avoid one hundred percent CPU load by multiple threads during operation.
The exploit for CVE-2012-1864 was also not publicly available until the new modification of PowerLoader. The vulnerability was discovered by Tarjei Mandt (aka @kernelpool) from Azimuth Security. Details of the vulnerability were made public in his Smashing the Atom report at the RECon conference in June 2012, but the exploitation code was not published to the public. The exploit code from PowerLoader looks more optimized and does not contain any debug information. The following shows the differences in the different versions of this exploit, in the second screenshot, the version from PowerLoader, in which there is no debug output.
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 can manipulate kernel mode objects from user mode using standard WinAPI. A good description of how to circumvent sandboxes using these types of vulnerabilities is presented in the presentation "Application Sandboxes: A Pen-Tester's Perspective" .
Payload
After the successful execution of the PowerLoader code and privilege escalation, the ransomware (Win32 / Vabushky.A ) ransomware is downloaded to the user's computer. The extortioner file is executed after the loader has raised the current privileges to the maximum, that is, SYSTEM. The Win64 / Vabushky dropper uses a trick with the legitimate self-generated certificate and its subsequent installation in the local storage as a measles target, that is, ROOT CA and TrustedPublisher. The following code demonstrates this technique.
This trick is not new and was already mentioned in the Mandiant "The“ Hikit ”Rootkit: Advanced and Persistent Attack analysis. In addition, during the installation process, the malicious code modifies Boot Configuration Data (BCD) data to activate test-signing mode, which allows you to download unsigned drivers. The following figure shows the registry keys in which the driver is installed.
The next step is to install a malicious driver into the system to block the system and display a screen with a specific cover that is downloaded from one of the URLs that are hard-wired in the code itself.
After all actions of the malware, the user gets a locked desktop.
Win64 / Vabushky encrypts user files using Microsoft CryptoAPI. After encryption, the .crypted extension is appended to the file. The driver code uses standard screen lock techniques and does not deserve detailed discussion.
Conclusion
Win64 / Vabushky dropper uses an interesting modification of the PowerLoader code. It uses LPE exploits for 64-bit operating systems from Carberp sources. All modules and components extracted by Win64 / Vabushky are used specifically for the 64-bit version of Windows. In addition, CVE-2013-3660 can operate a 32-bit version of Windows 8, which makes it universal. At the same time, due to the limitations of Intel SMEP and its support in Windows 8, the operation code cannot work for the 64-bit version of the OS. Thus, Microsoft’s efforts to provide additional security mechanisms in Windows 8 are indeed justified if the user is protected from exploits.
Win64 / Vabushky malware is a good example of how quickly attackers update their projects using Carberp source code . Two 64-bit exploits (CVE-2012-1864 and CVE-2012-0217) from the new PowerLoader are based on 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 propagation of droppers based on it.
Win64 / Vabushky droppers are packed using MPRESS , as this packer is one of the few free products that supports 64-bit PE32 + files. After unpacking, the dropper retrieves the original PE32 + header with a compile time as shown below.
')
All files include a payload compiled in early August. In the export table of this version of PowerLoader, you can see the changes compared to the older version.
After implementing the code in explorer.exe, PowerLoader tries to execute the following exploits in the context of trusted processes.
Such a set of exploits can be used to bypass certain types of sandboxes (sandboxes) that are used in security products, since these exploits use direct manipulation of kernel objects from user mode using the legal Win32 API.
CVE-2013-3660
In March, a researcher at Google Security Team Tavis Ormandy (@taviso) discovered a vulnerability CVE-2013-3660, which was closed by the July bulletin MS13-053 . We did not observe the 64-bit version of this exploit until the new modification of PowerLoader appeared, while the PoC x86 version is available to the public.
Before directly exploiting, the exploit code creates a second desktop object ( user32! CreateDesktopA ) to hide the fact of working with GDI objects.
The main operating code is shown below.
The shell code that is executed using nt! NtQueryIntervalProfile looks like this.
This operating code does not work in 64-bit Windows 8, because it cannot bypass Intel SMEP hardware technology (Supervisor Mode Execution Protection), which the new OS software supports. SMEP blocks the execution of code pages of user address space in kernel mode and in the 64-bit version of Windows 8 can be bypassed using ROP. However, Intel has already announced another protective technology SMAP (Supervisor Mode Access Prevention), which introduces additional restrictions on access to memory pages. Both of these SMAP and SMEP technologies are designed to prevent the exploitation of a NULL pointer dereference vulnerability in kernel mode, but SMAP is not yet supported in Windows.
CVE-2012-0217 and CVE-2012-1864
The exploit code for these vulnerabilities is based on leaked Carberp sources. We did not observe 64-bit versions of ITE CVE-2012-1864 before the Carberp texts were made publicly available. The operating code CVE-2012-0217, which is publicly available, does not work stably on 64-bit OS versions. After inspecting the executable exploit files in the Carberp texts, it was determined that they indicated the same path to the build directories.
This indicates that the exploits were developed on one system and, possibly, by one person. The exploit code CVE-2012-0217 is significantly different from the publicly available PoC, which demonstrates the possibilities of exploitation. The version of the text exploit Carberp is more stable and supports 64-bit operating systems. Below are the matches in the code blocks of these versions of the exploit for CVE-2012-0217 (the code from the PowerLoader is indicated 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 modification of PowerLoader. In addition, there are several methods in it to make operation more stable.
This code provides a modification of nt! HalDispatchTable in order to avoid one hundred percent CPU load by multiple threads during operation.
The exploit for CVE-2012-1864 was also not publicly available until the new modification of PowerLoader. The vulnerability was discovered by Tarjei Mandt (aka @kernelpool) from Azimuth Security. Details of the vulnerability were made public in his Smashing the Atom report at the RECon conference in June 2012, but the exploitation code was not published to the public. The exploit code from PowerLoader looks more optimized and does not contain any debug information. The following shows the differences in the different versions of this exploit, in the second screenshot, the version from PowerLoader, in which there is no debug output.
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 can manipulate kernel mode objects from user mode using standard WinAPI. A good description of how to circumvent sandboxes using these types of vulnerabilities is presented in the presentation "Application Sandboxes: A Pen-Tester's Perspective" .
Payload
After the successful execution of the PowerLoader code and privilege escalation, the ransomware (Win32 / Vabushky.A ) ransomware is downloaded to the user's computer. The extortioner file is executed after the loader has raised the current privileges to the maximum, that is, SYSTEM. The Win64 / Vabushky dropper uses a trick with the legitimate self-generated certificate and its subsequent installation in the local storage as a measles target, that is, ROOT CA and TrustedPublisher. The following code demonstrates this technique.
This trick is not new and was already mentioned in the Mandiant "The“ Hikit ”Rootkit: Advanced and Persistent Attack analysis. In addition, during the installation process, the malicious code modifies Boot Configuration Data (BCD) data to activate test-signing mode, which allows you to download unsigned drivers. The following figure shows the registry keys in which the driver is installed.
The next step is to install a malicious driver into the system to block the system and display a screen with a specific cover that is downloaded from one of the URLs that are hard-wired in the code itself.
After all actions of the malware, the user gets a locked desktop.
Win64 / Vabushky encrypts user files using Microsoft CryptoAPI. After encryption, the .crypted extension is appended to the file. The driver code uses standard screen lock techniques and does not deserve detailed discussion.
Conclusion
Win64 / Vabushky dropper uses an interesting modification of the PowerLoader code. It uses LPE exploits for 64-bit operating systems from Carberp sources. All modules and components extracted by Win64 / Vabushky are used specifically for the 64-bit version of Windows. In addition, CVE-2013-3660 can operate a 32-bit version of Windows 8, which makes it universal. At the same time, due to the limitations of Intel SMEP and its support in Windows 8, the operation code cannot work for the 64-bit version of the OS. Thus, Microsoft’s efforts to provide additional security mechanisms in Windows 8 are indeed justified if the user is protected from exploits.
Source: https://habr.com/ru/post/191904/
All Articles