Recycling Known Vulnerabilities -  Old Cyber Attack Goes Stealth

Posted by Michael Gorelik on May 11, 2016 12:45:48 AM
Michael Gorelik
Find me on:
 

exploit-recycling.jpg

In the course of our research we constantly encounter the simple but harsh truth that malware authors can easily bypass popular security products with small variations to their code. In this technical analysis, we present the inner details of a very specific attack that was identified several years back, and which has security patches, but which embodies the new sophistication which makes it invisible to almost every security product.

APT_Shellcode1.pngIt all goes back to the way security products work, in general of course, and the way malicious authors think. Security products search for something specific. The search can be smart and intelligent and fuzzy, but still they search for something specific, using prior knowledge acquired from a particular attack that was investigated. Malicious authors overcome that capability by understanding what the security products search for, giving a twist to their code, and - voilà! - it goes undetected. Tons of energy poured into a search mechanism, yet one dude with a laptop, persistence and a good dose of coffee, makes it useless.
 

CVE-2012-0158 is an ActiveX vulnerability patched by Microsoft back in 2012, but it remains one of the most popular CVEs to be used in document exploits. Just a few days ago, uanalysis.com discovered an Excel-transmitted version, which is able to evade almost all popular security solutions. [MD5: / see Twitter communication in the image above]

The good news is that Morphisec’s Moving Target Defense once more proved itself and prevented the attack immediately, like expected. Watch the short screen capture I prepared.

  

 

Attack Analysis

This analysis does not cover the exploitation and the vulnerability, which have already been explored thoroughly (see this post). Instead, we go deep into the shellcode, demonstrating how the exploit successfully evades most of the security solutions today.

The general steps of the shellcode execution are as follows (see the following section for the technical details):

  1. The shellcode initiated after activation of gadget from MSCOMCTL -> JMP ESP (RET)
  2. The shellcode has two sequential decryption routines which activate second stage shellcode + a few sophisticated anti-debugging techniques.
  3. Second stage shellcode locates functions by traversing the PEB and kernel32 module, locates the .xls file handle by iterating over existing handles, reading from it and locating its magic number, and decrypts the main 3rd stage shellcode.
  4. 3rd stage shellcode again locates many more functions from the PEB but this time it holds the pointers + small offset (0x5) -> to JMP over hooks (Bypass hooking).
  5. Its next step is to load MSVBVM60.dll which is the (32-bit) runtime component of VB6, although the reason for loading the module is different.
  6. Next it locates the function PutMemVar from this module and replaces it with a homemade function that is capable of receiving any function pointer (+0x5) as a parameter and activating it from the code (bypass of control flow analysis).
  7. Next the shellcode uses PutMemVar extensively by decrypting a new section from the .xls file -> this section is actually a propagative password stealer malware.
  8. To evade any white listing or AV which can scan the executable, the shellcode creates a duplicate Excel child process in suspended state, overrides its memory with the executable, and resumes the process.
 

Summary:

The creators of this attack worked extensively to evade existing advanced protections.

It can be seen from the advanced methods used in the shellcode (replacing existing dll functions to fool control flow analysis; bypassing hooking by executing the targeted functions with a small offset +0x5; staying fileless to bypass whitelisting and AV’s; locating main modules like Kernel32 only by checking the length of the module name; locating functions by hashing the names, which usually fools static analysis; the same is true for the file handles).

Although all of these techniques are well known and not new, such combination is rarely found. Similar shellcode technique can be found in the newer CVE-2015-2545 samples of malicious EPS Word documents (sha256 - 9c6dc1c2ea5b2370b58b0ac11fde8287cd49aee3e089dbdf589cc8d51c1f7a9e), although in that case the RAT is not fileless.

The Technical Details

1. The shellcode initiated after activation of gadget from MSCOMCTL -> JMP ESP (ret)
APT_Shellcode2.png
 
 
2. The shellcode has two sequential decryption routines which activate second stage shellcode + a few sophisticated anti-debugging techniques (XOR decryption).
 
APT_Shellcode3.png
 
 
3. Locates Kernel32 by only testing the length of the module name (without comparing any hash or name).
 
APT_Shellcode4.png
 
4. Second stage shellcode locates functions by traversing the PEB and Kernel32 module (calculating a simple ROR 7 hash of the function names and comparing them to existing hash results).
APT_Shellcode5.png
  
APT_Shellcode6.png
5. Locates the .xls file handle by iterating over existing handles, reading from it and locating its magic number, then decrypts the main 3rd stage shellcode with a simple XOR 0xE3.
 
APT_Shellcode7.png
 
6. 3rd stage shellcode after decryption:
 
APT_Shellcode8.png
 
7. 3rd stage shellcode locates many more functions from the PEB but this time it holds the pointers + small offset (0x5) -> to JMP over hooks (bypass hooking).
 
APT_Shellcode9.png
 
APT_Shellcode10.png
 
8. The next step is to load MSVBVM60.dll which is the (32-bit) runtime component of VB6, although the reason for loading the module is different.
 
9. Next it locates the function PutMemVar from this module and replaces it with a homemade function that is capable of receiving any function pointer (+0x5) as a parameter and activates it from the code (bypass of control flow analysis).
 
APT_Shellcode11.png
 
 10. Next the shellcode uses PutMemVar extensively by decrypting new section from the .xls file -> this section is actually a propagative password stealer Trojan.
 
APT_Shellcode12.png
 
11. To evade any white listing or AV which can scan the executable, the shellcode creates a duplicate Excel child process in suspended state, overrides its memory with the executable, and resumes the process.
 
APT_Shellcode13.png
  
APT_Shellcode14.png
 
 

12. As a closure of this investigation, I uploaded the embedded Trojan (saving the memory dump into an executable file) to VirusTotal Detection. In this case of course many AVs are effective. Too bad that attackers are well aware of this, and are now using the new evasive and stealthy methods described above.  

APT_Shellcode15.png
 
 

Recommendation for debugging

If you are using Windbg, execute “childdbg 1” and change the opcode marked in the next image from “ja” (JMP ABOVE) to “jb” (JMP BELOW), or instead, just progress the EIP so that the JMP will not happen.

APT_Shellcode16.png

 
 New Call-to-action

Topics: Attack Analysis

Welcome to our Blog

Keeping you in the loop with company updates, industry insight, cyber security trends, and cyber attack information.

Subscribe to the blog

Morphisec Named a Cool Vendor 2016

Morphisec is a Gartner Cool Vendor 2016

Each year Gartner identifies new Cool Vendors it considers innovative or transformative. Morphisec is honored be to named a Cool Vendor 2016. Here's more....