Yesterday, a targeted campaign leveraging a Flash zero day exploit hit the news. Adobe has now released a security bulletin regarding this vulnerability. Based on the attack vector mentioned in prior research, we have concluded that recently observed .SWF exploitation is related to the recent zero-day threat flagged as CVE-2014-0502. Upon successful infection, the exploited victim is served a RAT (Remote Access Trojan).
While we were doing our daily review of logs, we found a significant number of transactions related to this campaign. We specifically started looking for those compromised servers which have been mentioned in prior research. We began investigating all suspicious transactions which used a known compromised site as a referral location.
After some brief inspection of this location, we found not only the malicious .SWF, but also all other connected malicious files detailed in the analysis below. We will cover the dropped Flash file that exploits the vulnerability using an image that contained embedded shell code. This shellcode is then used to download the malware.
The Flash file was found to be encrypted using the DoSWF flash encryptor.
Upon throwing the Flash file into an ActionScript viewer, we immediately see the script shown below. The script tries to make a URL Request to a GIF Image file, which contains the embedded shellcode for an ROP exploit.
The script checks for the presence of a cookie labeled 'XPT2013111'. If this cookie is not already present, it sets the same.
The script then checks the operating system version and in the case of Windows XP, further checks the OS language. Details of the OS language and version are then used to determine the base address for the exploit. In case of Windows 7, the script further probes for unpatched and outdated versions of Java (Web Start 1.6 and 1.7) or Microsoft Office (Sharepoint OpenDocuments 3 or 4).
Here we can see on XP, based on the version and language, the base address for the exploit is determined by the script. Then the ROP sled is built to carry out the exploit.
The GIF image used for embedding the shellcode is shown below, which of course seems innocuous to the victim.
When opened in a hex editor, the magic bytes for a GIF image file can be seen.
However, upon careful examination, we further see extra bytes appearing toward the end of the image as shown below.
Using a shellcode emulator like libemu, we can see that this extra data represents the shellcode to be executed.
Here we see that the shellcode makes a call to the LoadLibraryA function and then to VirtualProtect to allocate memory in which to place the shellcode. It then checks for the /temp folder path and makes calls to InternetOpenUrlA to download the malware from a remote location http://[x.x.x.x]/common/update.exe and drops it into the /temp folder.
A sandbox analysis of the final dropped file can be seen here.
Browser plugins continue to be the Achilles heel of enterprise security. While enterprises struggle to ensure that browser plugins are up to date on all end user systems to prevent browser exploit kits from targeting known vulnerabilities, here we see yet another demonstration where even that is not enough. Attackers continue to identify and exploit 0day vulnerabilities in popular web browser plugins such as Adobe Flash, which unfortunately has a long history of dealing with such threats.
While we were doing our daily review of logs, we found a significant number of transactions related to this campaign. We specifically started looking for those compromised servers which have been mentioned in prior research. We began investigating all suspicious transactions which used a known compromised site as a referral location.
After some brief inspection of this location, we found not only the malicious .SWF, but also all other connected malicious files detailed in the analysis below. We will cover the dropped Flash file that exploits the vulnerability using an image that contained embedded shell code. This shellcode is then used to download the malware.
The Flash file was found to be encrypted using the DoSWF flash encryptor.
Upon throwing the Flash file into an ActionScript viewer, we immediately see the script shown below. The script tries to make a URL Request to a GIF Image file, which contains the embedded shellcode for an ROP exploit.
The script then checks the operating system version and in the case of Windows XP, further checks the OS language. Details of the OS language and version are then used to determine the base address for the exploit. In case of Windows 7, the script further probes for unpatched and outdated versions of Java (Web Start 1.6 and 1.7) or Microsoft Office (Sharepoint OpenDocuments 3 or 4).
Here we can see on XP, based on the version and language, the base address for the exploit is determined by the script. Then the ROP sled is built to carry out the exploit.
However, upon careful examination, we further see extra bytes appearing toward the end of the image as shown below.
A sandbox analysis of the final dropped file can be seen here.
Browser plugins continue to be the Achilles heel of enterprise security. While enterprises struggle to ensure that browser plugins are up to date on all end user systems to prevent browser exploit kits from targeting known vulnerabilities, here we see yet another demonstration where even that is not enough. Attackers continue to identify and exploit 0day vulnerabilities in popular web browser plugins such as Adobe Flash, which unfortunately has a long history of dealing with such threats.
