Flash forward – Angler, here we come
Posted by Tamas Rudnai on 27 January 2015 08:10 AM
As mentioned in the post, “Happy Nucl(y)ear - Evolution of an Exploit Kit”, we were planning to discuss the Angler exploit kit in detail in an upcoming post. However, the exploitation of a critical Adobe Flash 0-day vulnerability (CVE-2015-0311, now patched) via the Angler exploit kit has fast-tracked our efforts, and in this blog, we present the strategy adopted by the exploit kit to evade detection of the 0-day by security scanners. 0-days are valuable commodities, and the longer they remain undiscovered, the more value they appropriate for the attacker(s).
Just as defense-in-depth is used as a strategy in the protection scenario, layered obfuscation is its equivalent in the evasion scenario. The attacker is interested in adopting a defense-in-depth approach to protect his / her investment and get the most Return on Investment (ROI) from exploits. A parallel in the physical world is a medieval castle, which was protected by a multiple wall system, so even when the external wall had been taken down by catapults, the so-called inner castle was still standing strong.
The Angler exploit kit is probably the most sophisticated exploit kit out there today, and its authors are quick at adding new exploits to their arsenal, as well as using new approaches to evade detection. One of the advances the exploit kits authors have made is to be able to directly inject malicious code into the browser’s process memory, as opposed to dropping executables on the potential victim’s machine, thereby making it harder for traditional security products to detect exploitation.
Adobe Flash has always been a good investment for exploit kits, but with the recent decline in the number of Java exploits (because of various advances made by Oracle and the browsers in this regard), attackers seem to be re-focusing their efforts at finding vulnerabilities in Adobe’s products.
Here at Websense Security Labs, as per our estimates, we have blocked over 3 million attempts to more than 2500 URLs believed to be used in threats connected with the Angler Exploit Kit since September 1, 2014. As we can see from the graph below, we have also observed an increase in the amount of activity seen at the TDS (traffic distribution system) used in this campaign over the past few days:
The activity of the Angler exploit kit is depicted in the graph below:
Layers of obfuscation
Coming to the specific 0-day exploit used by the Angler kit, the flash SWF sample we analyzed contains an obfuscated ActionScript as the first-level wrapper. Obfuscation in ActionScript is similar to other scripting languages: it can be a combination of class, method, and variable name scrambling, string encoding, and even hiding of API calls by making them less obvious in some cases. ActionScript is compiled to p-code, and therefore its compiled code can be further tweaked by the malware writer to make disassembling and decompiling efforts harder. However, the specific sample that was analyzed did not do this.
As one can observe from the screenshot below, the names are quite meaningless, and just by looking at the decompiled code it is almost impossible to figure out the algorithm. Note that the random names used can be changed by the obfuscation tool to generate different source code with each run, thereby making static detection harder.
What is interesting to note is that there is a string that looks like a base64 encoded stream in there. This provides a hint about what could be done next in the analysis:
It did seem promising at first, but simple decoding of the base64 string only produced a scrambled binary without any patterns or hints about the possible encryption method used, or even a high-level idea of the format of the file.
When all else fails, we have no choice but to go back to manual reverse engineering. The objective was to find the decryption method and try to understand the mechanism used, to be able to proceed to the next step. Once that was complete, replacing the original variable and method names with more meaningful ones, the big picture was in front of us (see below):
Note that the variable "this.rtyr" in the obfuscated code holds the secret to the next step. It is the key used in the decryption method, and therefore we have renamed it to "key" above. From here on, it was relatively straightforward to go even further and turn this piece of code into a small script that let us figure out what the binary was doing:
As is clear from above – this is a zlib compressed Flash file (CWS file), which makes perfect sense. The 0-day vulnerability is in this flash file, rather than the “wrapper” host flash file.
Why did the exploit writers do this?
Most security scanners have the ability to scan only the “wrapper” host file. They cannot extract the obfuscated, encrypted, embedded malicious CWS file and scan it. There are too many variables involved to be able to do this on the fly in an automated way – including the keys used, algorithm used for encryption and obfuscation, and so forth.
To summarize, the exploit writers hid the malicious CWS file under the guise of a legitimate-looking SWF file and used multiple layers of obfuscation, compression, and encryption to evade security scanners. This scenario, while interesting, leads to a very serious question. How is one protected against such attacks?
Websense customers were already protected against this threat with ACE, our Advanced Classification Engine, at the different stages of the attack detailed below:
This case highlights the importance of defense-in-depth and the need to provide protection at multiple stages of the attack kill chain, because merely protecting the wrapper host SWF file would yield little benefit if the attacker changes one byte in the embedded malicious CWS file.
Security Researcher: Tamas Rudnai, Contributors: Amy Steier, Ran Mosessco, Rajiv Motwani
Read more »