Recycling Known Vulnerabilities -  Old Cyber Attack Goes Stealth

 

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.

It 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 3^rd stage shellcode.
4. 3^rd 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 whitelisting or AV which can scan the executable, the shellcode creates a duplicate Excel child process in a 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)

 

 

2. The shellcode has two sequential decryption routines which activate second stage shellcode + a few sophisticated anti-debugging techniques (XOR decryption).

 

 

 

3. Locates Kernel32 by only testing the length of the module name (without comparing any hash or name).

 

 

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).

  

5. Locates the .xls file handle by iterating over existing handles, reading from it and locating its magic number, then decrypts the main 3^rd stage shellcode with a simple XOR 0xE3.

 

 

6. 3^rd stage shellcode after decryption:

 

 

7. 3^rd 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).

 

 

 

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).

 

 

 10. Next the shellcode uses PutMemVar extensively by decrypting a new section from the .xls file -> this section is actually a propagative password stealer Trojan.

 

 

11. To evade any whitelisting or AV which can scan the executable, the shellcode creates a duplicate Excel child process in a suspended state, overrides its memory with the executable, and resumes the process.

 

  

 

 

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.  

 

 

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.