Angler Exploit Kit – Operating at the Cutting Edge
Posted by AToro on 05 February 2015 02:30 PM
As we promised in one of our previous blog posts about exploit kits (Nuclear EK), we are going to take a more in-depth look at Angler Exploit Kit. Angler EK is possibly the most sophisticated exploit kit currently used by cyberciminals. It has pioneered solutions that other exploit kits started using later, such as antivirus detection and encrypted dropper files. In addition, Angler tends to be the quickest to integrate the latest zero days, such as the Adobe Flash zero day (CVE-2015-0311) from a few weeks ago, and it employs a notably unique obfuscation. Finally, Angler runs the dropped malware from memory, without ever having to write to the hard drive; this unique technique among exploit kits makes it extremely difficult for traditional antivirus technologies to detect it as they rely on scanning the file system.
While Angler is the most advanced exploit kit in today's threat landscape, Websense customers are protected from this threat with ACE, our Advanced Classification Engine, at the following stages:
Angler's landing page consists of four basic parts. Firstly, there is some visible English text, which is used to make the victim of the exploit kit believe they have browsed to a legitimate page. Secondly, it has various deobfuscation routines to deobfuscate the actual malicious scripts. These scripts are located within p class tags and they are encoded as base64. Decoding the base64 strings reveals the actual obfuscated exploit kit code. And finally, the landing page contains several encrypted strings, which contain various URLs leading to the various exploits (Flash, Silverlight, Internet Explorer) included in the kit.
Samples from Angler landing page
Deobfuscated Exploit Code
Once the landing page is deobfuscated, the true nature of the code is revealed. Angler, just like Nuclear and various other exploit kits, uses a very basic second layer obfuscation to make detection by security products even more difficult.
It also uses antivirus detection in addition to detecting various virtualization solutions (VMWare, VirtualBox, Parallels) as well as a web debugging proxy called Fiddler, which is widely used by security researchers. Implementing these measures makes it very difficult to observe and investigate this exploit kit in the wild, as most security researchers often rely heavily on these tools.
Detecting various .sys and .dll files which belong to AV and virtualization software
VMWare, VirtualBox, Parallels detection as well as Fiddler web debugging proxy
The most unique feature of Angler is the use of these encrypted URL paths. It uses a simple transposition-based cipher (in layman's terms: scrambling the letters) to encrypt and decrypt this data.
The decryption routine is embedded within the obfuscated part of the exploit kit.
Decryption routine as found in the kit
Decryption routine formatted and commented
We will use a very simple example to demonstrate how the decryption works. Suppose our cipher text (encrypted data) is "TEER CSURH TO PLTAOEL IX TP" and our decryption key is "OBFUSCATE". What Angler does is, it takes the alphabetical order of the letters in the key and rearranges the cipher text based on that. For example:
OBFUSCATE → 6,2,5,9,7,3,1,8,4
This gives us the order of letters in the cipher text. Using this we can easily decrypt it by rearranging the letters.
And finally whitespaces are removed from the decrypted string . Obviously, this is an extremely rudimentary form of encryption and would be very easy to crack even without the key if (such as in the above example) the plaintext consisted of actual words. However, Angler uses highly randomised URLs so this kind of encryption is more than sufficient to hide the true nature of these strings and the actual URL paths from various security products.
The rest of the deobfuscated code follows usual exploit kit patterns: there are various plugin detection and version check routines so the exploit kit 'knows' which exploit(s) to fire on the target. There are also quite a few shellcode builder routines as Angler uses a multi staged shellcode, where various stages are encoded and get decoded by the previous stages. It also includes a hardcoded encryption/decryption key for the dropper file.
Encryption key for payload
Multi stage Shellcode
If the exploit succeeds, Angler's payload is dropped on the victim's system. As the payload travels through the network it is still encrypted and gets decrypted later by the final stage shellcode. This technique is used to make detection of the malicious dropper very difficult for traditional intrusion detection systems (IDS). As we mentioned before, Angler uses 'fileless' droppers, which mean that they are run directly from memory. The dropper used by Angler is called Bedep, which is actually only a downloader - that is, it is not malicious per se, but it is used to download and execute various different malware.
The payload consists of a combination of shellcode and the Bedep DLL. If the first few bytes of the payload are "909090" (NOPs or No Operations in x86 assembly) the DLL will be loaded from the memory, otherwise it will be written to the disk just like a normal dropper file. The shellcode is responsible for running the DLL from memory.
The shellcode resolves APIs such as kernel32.dll and wininet.dll
Angler Exploit Kit is no doubt one of the most dangerous exploit kits out there in the wild today. It has various techniques in its arsenal to defeat traditional detection methods such as:
In addition Angler is often the first to adopt the latest exploits, which include zero days from time to time. The constantly evolving nature of Angler also highlights the need for security solutions that provide protection across the entire kill chain instead of only focusing on just one stage of it.
Read more »
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 »