Flash Greets 2015 With New Zero-Day
Since January 20, we have obtained copies of malicious SWF files used by the Angler exploit kit via feedback provided by the Smart Protection Network. These samples were obtained from users in the United States; we believe that one of the samples we obtained is the same zero-day Flash exploit reported by the security researcher Kafeine, but from an infection chain different from the one reported by Kafeine.
The Angler exploit kit is believed to have been responsible for distributing this exploit. The past day has seen a significant uptick in the activity of the Angler exploit kit server related to the zero-day, as can be seen in the chart below:
Figure 1. Number of hits to the Angler exploit kit server landing page related to the zero-day
The graph clearly shows a significant increase in Angler activity in the past day, which is roughly the same time since the existence of this vulnerability was first revealed. Most of these users are in the United States, as the chart below shows:
Figure 2. Geographic distribution of users affected by Angler
Analysis of the feedback provided by our products suggests that malvertisements are being used to deliver these exploits to end users. While we have not completed our analysis of the exploit itself, it is clear that a current version of Adobe Flash Player is affected:
Figures 3 and 4. Infection chain of Flash exploit
Exploit Method and Obfuscation
Until a patch is issued by Adobe, we will refrain from discussing the details of the exploit. However, we do note that the overall method is similar to earlier Flash zero-days like CVE-2014-0515.
We also note that the samples we’ve seen are heavily obfuscated. Firstly, it uses the loadByte() function to load and execute an embedded Flash file. The function name loadByte is obfuscated using string operations, and the parameter (i.e., the content of the embedded Flash file) is also obfuscated using byte array obfuscation.
The embedded Flash file itself uses multiple control flow obfuscation techniques.
The Shell Code
The shell code in the sample enumerates the needed API function address first. It then creates a new thread to download the payload from exploit kit server.
The payload is encrypted, which the shell code will decrypt in memory. From the obtained API, we can see there is no CreateProcess and WriteFile. Thus, it will not drop the final PE file onto the disk like other exploit kits do. This is the typical behavior of Angler exploit kit.
Figure 5. Screenshot of function addresses saved in memory by the shellchode
Recommendations and Best Practices
In the absence of an Adobe bulletin, users may consider disabling Flash Player until a fixed version is released. We also note that Chrome’s version of the Flash Player plugin is sandboxed, mitigating potential effects to end users. Firefox is also immune to this threat.
For end users, our endpoint products contain Browser Exploit Protection, which helps provide protection against exploits that target browsers or related plugins. The existing Sandbox and Script Analyzer engine that is part of Deep Discovery can also be used to detect this threat, without any engine or pattern update.
We will update this post with further updates as necessary.
Additional thanks to Joseph C. Chen for providing the sample and additional data, as well as Brooks Li, Jack Tang, Moony Li, Michael Du, Peter Pi for further analysis.
Incoming search terms