We all know how the infamous RIG Exploit Kit have been used to infect the end users. We are seeing a constant spike in the usage of the RIG Exploit Kit by malware actors to spread malware. Its use has been noticed in different campaigns such as EITest, pseudoDarkleech, and AFRAIDGATE. The RIG Exploit Kit is mostly used to drop ransomware on targeted machines. We have recently observed an upsurge in the usage of Adobe Flash Player Exploit (CVE-2015-8651) by the RIG Exploit Kit. The infection chain starts with a compromised web page which redirects the user to a landing page and then loads the Flash exploit as shown in Fig 1.
In this blog post, we will discuss the working of the Adobe Flash exploit (CVE-2015-8651).The Flash exploit has 5 DefineBinary tags which hold obfuscated data. After analysing the DefineBinary tags, we found that two DefineBinary tags data are encrypted by RC4 encryption algorithm and their keys are kept in other DefineBinary tags. Let’s take a closer look at these DefineBinary tags.
The ‘DefineBinary Tag-1’ shown in Fig 2 contains the decryption key. This key is used to decrypt the data present in DefineBinary Tag-2. After the decryption of DefineBinary Tag-2, we found the below strings.
Also, there was another decryption key in the ‘DefineBinary Tag-4’. This key is used to decrypt the data present in ‘DefineBinary Tag-3’.
The decrypted data shows strings which are used in shellcode preparation by the exploit.
The Exploit Entry Point
The code snippets in Fig 6 shows the entry point of Flash execution. In method_6 given argument -1820302796 gets XOR’ed with 0x93806237 (present in DefineBinary tag-5 data) gives the index value as ‘3’ which represents string “iQWERddQWERqd”. The _loc5_ variable holds “iddqd” which is decoded from the string “iQWERddQWERqd” after removing “QWER”. This iddqd variable holds data which is passed as a parameter to the current Flash file. Then _loc6_ variable holds hex data which is decoded by replacing “QWER” by “E” by the earlier XOR process and those strings are also stored in DefineBinary tag-3.
The function call ‘this.sdfghfghfgj’ triggers the exploit code. It performs fingerprinting and version checks to obtain the version of the installed Flash player. If a vulnerable Flash installation is found, it triggers the vulnerability and carries out heap spray. The function ‘get_big_ba’ triggers the well-known integer overflow vulnerability (CVE-2015-8651).
The function ‘is_vuln’ performs Exploit checks.
Below are the checks:
Below is the snippet of the function ‘check_versions’ which does the Flash player version checking when it’s called.
The functions related to domain memory which is responsible for the Flash exploit are defined in package “avm2.intrinsics.memory”. The package provides methods as ‘li32’ and ‘si32’ where li32 is used to load 32-bit integer values from the memory and si32 used to store 32-bit integer into the memory. The definition of ‘li32’ and ‘si32’ functions exploits an Integer Overflow Vulnerability (CVE-2015-8651). The detailed analysis of the vulnerability can be found here.
Upon successful exploitation of the said integer overflow vulnerability, the exploit runs a shellcode. We have observed that the shellcode generally connects to the exploit kit domain and downloads malware and executes them on the victim’s machine.
Quick Heal Detections
Quick Heal has released the following detection for the RIG Exploit Kit Flash exploit:
As observed in Quick Heal Labs, below is the trend of the ‘Exp.SWF.Rig.EK’ over the last month.
With a limited set of reversing tools, the analysis of the highly obfuscated Flash Exploit was a bit difficult. Malware actors are using a deeper level of obfuscation to hide actual exploit from reverse engineering. Such techniques are used to evade detection at every level and will continue to evolve in the future. We strongly recommend users to update the Windows Operating System and Flash Player and use a multi-layered security software such as Quick Heal.
Subject Matter Experts