Inside the RIG Exploit Kit Infection Chain and Adobe Flash Vulnerability CVE-2015-8651 ..!!

We recently observed RIG exploit kit delivering Adobe Flash exploit that takes the advantage of Integer overflow vulnerability CVE-2015-8651 in the Adobe Flash and delivering the malware on the infected system. I got the opportunity to analyze the Rig exploit kit infection chain and the delivered exploit.

Infection Chain of Rig Exploit Kit

Infection starts when user accesses the link which initiates the “GET” request to “signup1.php” to the IP: 194.58.40.252. Current Whois information of this IP reveals that this server is hosted in Russian Federation

This web server was compromised which possibly would have been a part of the malvertising campaign, and the page was modified to inject the malicious iframe which would redirect the browser to the Exploit kit landing page. 

Once the Browser is redirected to the landing page, server responds with the obfuscated JavaScript. Purpose of the JavaScript is most likely to determine the type and version  of the browser running according to which the exploit will be delivered in subsequent stage.

Below is the  part of the Deobfuscated JavaScript that contains the URL to request the flash  exploit from the hosting server.

Subsequently, the Flash exploit is delivered to the victim machine that exploits the Adobe flash vulnerability. Below communication with the server depicts the clear picture of the flash file being delivered to the user.

Flash exploit triggers CVE 2015-8651 vulnerability post which the encrypted payload embedded in the flash file is executed.

Below picturizes the entire infection cycle of the Rig exploit kit.

Vulnerability exploited and the root cause

Vulnerability exploited by the delivered flash exploit:  CVE 2015-8651. This vulnerability is due to the Integer overflow in Intrinsics Memory / Fast Memory opcode generation by ActionScript Virtual Machine JIT compiler.

Analysis of the exploit:

Execution of the ActionScript starts with the Init() method as show below which passes   “-1820302793” which is 0x93806237 as the argument in the method_10 of the class 3 , where it gets XORED with the var_7 which is set in the method_1 by reading 32 bit Unsigned Integer from the ByteArray Class. The returned value is a string in which “QWERTY” is then replaced with “E” and subsequently appended to the var_209 . This resultant string is then stored in _loc_5_  which stores the decrypted shellcode and passed as the parameter to the sdfghfghfgj() function where ultimately exploit is triggered .

Function sdfghfghfgj() is the one that initiates the vulnerability triggering flow . This function calls the run () function internally which in turn executes the vulnerability check function “is_vuln()’ . Latter checks for the Windows version, flash versions and then prepares to triggers the vulnerability, and eventually triggers Integer overflow by calling the method get_big_ba()

As indicated earlier, function sdfghfghfgj() creates the instance of the class “world” which calls the prepare() method in the constructor to check for the following :
- Debug version checks
- Determine the flash player type
- Get the flash player version
- Get the OS type
Below is the code snippet performing above mentioned checks.

Vulnerability:

Adobe implemented a feature in the Adobe Flash Player called “DomainMemory” which was primarily used by developers to gain the fast read and write access to the domain memory. Domain memory opcodes are provided by the package avm2.intrinsics. memory. This  package provides the methods to load / store integers to byte streams like ByteArrays. Integer overflow vulnerability lies in the way these Domain Memory opcodes are generated by Action Script Compiler (ASC). As seen below, Flash exploit imports these packages and specifically li32 and si32 which is used to load and store 32-bit unsigned integers into the memory.

Below is the documented list of Domain Memory opcodes provided for faster read and write access to ByteArrays.

Vulnerability existing in these si32 and li32 domain memory opcodes allows the attacker to perform arbitrary read and writes into the memory.

Triggering the Integer Overflow:

As indicated in the previous figure get_big_ba() function within the exploit is responsible to trigger the Integer overflow condition. In this function, first the several ByteArray objects is sprayed on the heap and then ByteArray.Length is corrupted. Domain memory data is initialized after that in the function make_big_ba() and then eventually confuse_ba() function is called where it is able to perform out-of-bounds read and write in the calls read_int_overflow() and write_int_overflow() respectively. However, the latter calls will achieve the arbitrary memory read /write using si32_overflow () and li32_overflow ().

Bypassing windows Mitigations to execute shellcode

Let's take a detailed look at how this flash exploit bypasses windows mitigations

Bypassing ASLR:

Exploit performs the ASLR bypass by creating the information leak. It leaks the address of the Initialized ByteArray object by calling the method get_obj_addr() and eventually gets the address of the objects’ virtual function table which is later corrupted by writing the address of VirtualProtect() API. As described in the earlier section, world:run_payload() method triggers the execution of the shellcode before which the mitigations are bypassed.  In the run_payload() function , init_ba() function is called which initializes the ByteArray and ByteArray.Length is corrupted to gain RW primitives.

Below code snippet from the find_data() reveals the leaking of ByteArray object address.

Subsequently in the run_shell() function, find_virtprot() is called which resolves the address of the VirtualProtect () API leading to the ASLR bypass. Below is the code performing the address resolution.

In the subsequent code, address of the VirtualProtect () API is written using the acquired RW primitives [ write_uint() ] following which the arguments to the API are pushed.

In the following code, apply() method is called on the function object which will execute VirtualProtect () API and marks the shellcode buffer  as RWX achieving DEP bypass.

Finally call() method is invoked on the dummy object, which will execute the shellcode as shown in the code below.

Details on the call() method of the function object as described by Adobe:

Intention and analysis of Shellcode

Once the shellcode is executed, it would connect and download additional malware from the attacker-controlled server. Debugging the Action Scripts with the AS debugger reveals that the shellcode embedded in the DefineBinaryData 1 tag of the flash file is decrypted with the key and then XORed with 0x84 during the execution.

Below is the snapshot of the code that decrypts the shellcode when the init() method is called initially.

During the execution , shellcode is then XORed with 0x84 as shown below.

Once code is XORed , it will  execute and drop the JavaScript in the “Temp” directory, which is finally executed using the windows wscript engine with the command “wscript //B //E: Jscript o32.tmp”. Below is the XORed code.

Indented JavaScript is as show below for readability.

From the dropped JavaScript, it is apparent that exploit is downloading additional malware [ a DLL ] from the attacker controlled server and then executes it using “regsvr32.exe /s ” command.

Win32/Furtim : Malware With Galore Of Stealth And Evasions..

Recently around a mid May 2016 , a sophisticated malware nicknamed Win32/Furtim was uncovered and since then , lot of noise has been made about the attribution of the malware and the suspected targets. One of its dropped components was believed to target European energy company while others believed it to be a credential stealer. However , while the purpose of the malware and the potential targets are still unclear and perhaps under investigation , this piece of code sounded extremely interesting to me because of the fact that , it goes an extra mile to implement heterogeneous techniques to hide its behavior. This methods are wide ranged from detecting installed Anti-Virus products, virtualization ,sandboxes, monitoring tools and plenty of stuff.

I wanted to take a in-depth look at the malware to see evasion techniques used.This code also has been obfuscated by using indirect calls to the huge extent to prevent static analysis . Apparently , it must also have several anti-debugging techniques to hide itself from debuggers. It uses ZwQueryInformationProcess with ProcessDebugPort to check if the process is running under the context of the debugger.

Bypassing user-space hooks

Win32/Furtim bypasses user space hooks by directly calling ntdll APIs. Several AV products and sandboxes implement user space hooks to monitor the API calls of the process. This malware uses lower level calls to avoid being monitored by traditional hooks. Some of the ntdll APIs that it tries to resolve:
























Blacklisted processor architectures

It executes CPUID instruction after loading the registers with the appropriate values to get the processor brand string and compares with the blacklisted processor architectures. If found, it will terminate :


















Apart from these , CPUID instruction also reveals the hypervisor details. Below is the check performed if the malware is running under hypervisor environment.






Blacklisted hostnames

Next it tries to detect the analysis system by checking the hostname . Process will terminate if it finds the hostname matching any of the ones in the blacklist.







These hostnames should apparently correspond to known sandboxes. Below are couple of instances found:













File paths containing the known strings

Many of the automated analysis systems including commercial sandboxes tend to use the "malware" , "sample" , "virus" etc in the file name or the path. Here is the check that is performed to match the path against the known path names or string after calling GetModuleFileNameW.


















VxStream sandbox

It calls GetDriveTypeW to check if Z:\ drive exists on the system as a DRIVE_FIXED and then checks for Z:\\VxStream to see if it is running inside the VxStream sandbox.









Known hooking DLLs used by AV products for behavior monitoring

Antivirus products and sandboxes attempt to monitor the behavior of the processes by injecting the DLLs into its address space. These monitoring DLLs patch the API calls in the kernel32.dll redirecting to its own stub to log the behavior or to modify the stack before the call is made. It is very unlikely that ntdll will be hooked by commercial sandboxes unless unavoidable , since it interface is not consistent and changes between OS. Win32/Furtim calls the ntdll API GetLdrDllHandle to check if any of the below monitoring DLLs is loaded in the process . If it finds one , it will terminate.






















Known sandbox / monitoring tools artifacts

As another addition to the implemented evasion techniques,it calls NtQueryAttributesFile to check if the infected machine has any of the blacklisted files . This list includes the check for Cuckoo sandbox,Cwsandbox, presence of debugger , Sysanalyzer monitoring tools,Gfisandbox , malware decoders and several others . It will perhaps refuse to run or alter its behavior if any of the file is existing on the machine .























Mismatch in the number of CPU cores reported

This is yet another clever check performed by the malware. It calls NtQuerySystemInformation to populate the buffer with SYSTEM_BASIC_INFORMATION. At the offset into the structure, it will access the SYSTEM_BASIC_INFORMATION.NumberOfProcessors to see if the Number of Processors reported is 1 . It the check is successful , it matches the brand string extracted using CPUID instruction with the known CPU brand strings to validate the number of CPU cores . If this check if successful , the process will prematurely terminate .





















Dynamic anlaysis apparently reveals this fact :







Blacklist of processes related to known sandboxes / monitoring tools / Virtualization environment / Honeypots 

Here is one more check for running processes to see if monitoring / debuggging / static analysis tools , sandbox processes , traffic capture tools, Honeypot processes are found in the infected system.























Kernel drivers associated with AV products / Monitoring tools / Virtualization 

Another extensive blacklist of loaded kernel drivers. It calls NtQuerySystemInformation with SYSTEM_MODULE_INFORMATION to get the list of loaded kernel drivers and checks is performed against the below list:























Virtul NIC cards

Following virtual NIC cards are checked as well . It any of these virtual NICs are found , it will terminate the execution.





















Before this code gets executed , it also checks for system with the NIC card named "Realtek RTL8139 Family PCI Fast Ethernet NIC" , username "Antony" or Antonie" and existance of C:\\Downloads directory. This doesn't sound like a sandbox specific configuration . Perhaps it doesn't want to run on a system owned by "Antony"













Hypervisor registry keys

As if these aren't enough, it also has the checks for the Hypervisor specific known registry keys. Below is the code that checks for it .











Next to this , it accesses the registry key:\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\ and verifies if it has following values :

• SystemBiosVersion has following data
• BOSCH - 1
• VBOX - 1
• PRLS - 1
• VideoBiosVersion has following data
• Virtualbox

DLLs associated with analysis tools and sandboxes

Below list of DLLs are usually loaded by the tools used to analyse the malware samples (SysAnalyzer etc .) . Some of these are loaded by known sandboxes ( Sandboxie , Sunbelt , Buster)













Presence of  "Vmware Tools" directory under C:\

Calls GetDriveTypeW to check if the C:\ is present on the system and checks for the existance of following directories:

• C:\\Program Files\\VMware\\VMware Tools
• C:\\Program Files (x86)\\VMware\\VMware Tool ( 64 bit systems)

Presence of Virtual HD

Below two registry keys are accessed and the value extracted is checked against the known Virtual HDs . A successful match with result into termination of process.

\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\IDE
\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\SCSI

• QEMU_
• VMware
• Ven_Red_Hat&Prod_VirtIO
• DiskVBOX
• DiskVirtual

Presence of BioMetrics / Fingerprint software by ZkTeco

It is hard to believe that any malware would check for this . But it was interesting to know that it checks if ZkTeco software is installed on the system . Googling for this , apparently it is a provider of Biometrics / Fingerprint sensors . I can certainly say at this point that this malware has came out to be too restrictive. These nature of softwares wouldn't run on any automated analysis systems. Along with this, it also has the checks if the Path Names contains "Oracle" . Not sure if the author really intended to check for sandbox.



















Registry check for installed traffic analyzers / analysis tools / virtual environment

Yet another list of software installations to check for in the registry.






Window class names / Window Title Names

Eventually , it also runs a check for the known window class and window title names used by sysinternals monitoring tools and sandboxes . Below is the exhaustive blacklist for that as well .



















Malwares have become extremely evasive in nature to avoid running in the automated analysis systems. Authors employ variety of techniques to make static analysis time consuming and complex for the researchers as well. However , none of the techniques used in this malware is new or is something which we haven't seen before. Its just that its a comprehensive list of almost all the evasions that we would have probably came across in other malwares in the past.