Discover Top Posts Tagged with #exploitkit

An In-depth analysis of the Fiesta Exploit Kit: An infection in 2015

A while ago I blogged about the Fiesta exploit kit, this was back in September 2013 [Fiesta Exploit Kit analysis serving MSIE exploit CVE-2013-2551] in this blog I focused on the integration of the MSIE exploit and parts of the landing page.

At that time payloads were not encrypted, you could just see them pass by on the network level and spot the PE header. Nowadays these guys are encrypting the payload transferred to a client after successful exploitation of a browser-plugin or the browser itself. In this blog entry I'll go through the steps of how the Fiesta exploit kit works: how it redirects, exploits and infects clients. I'll follow a Flash exploit, Java exploit and a PDF exploit to, in the end, be able to decrypt payloads. Some weeks ago after encountering an infected client during work and not being able to automatically extract payloads from the network stream I decided to have a look at home. First step was infecting my virtual machine, luckily the redirect was still active. The redirect can be easily spotted on the index page of the site:

A small snippet was being injected in the main page just before the end of the page. A simple offset character scheme was used to obfuscate the snippet, decoding is simple:

The exploit kit is active on 'znaaok.myftp.biz' which at the time pointed to 92.63.87.16. Checking this IP in the VirusTotal passivedns database shows a lot of similar looking domains:

This specific campaign is active under no-ip DynamicDNS domains. All the used domains are quite shortlived and rotated often.

The landing page

Back to the analysis, the browser in the VM embeds the iframe in the page as per the JavaScript snippet indicated and gets exploited:

In this example the machine gets exploited with a Flash exploit, MD5 hash for the flash exploit: f77e25d5a04d8035d49a27d1b680e35d. At the time of submission it was only at 3 out of 57 antivirus products for detection on VirusTotal, rather low meaning its 'fresh'. Exploit kit controllers will rotate the flash exploit when it gets detected by AV engines to ensure 'FUD' spreading, in this case 3 out of 57 is not 'FUD' but close to it. From the Fiddler requests we can determine the following:

76: Client lands on the landing page

80: Client downloads the flash exploit

81: Client downloads the payload after successful exploitation

Lets start at the start, the exploit kit landing page. When opening up the landing page in sublime I immediately recognized it from the 2013 one. Except for the random text at the top (which I removed a bit from to show the code) the obfuscator for the JavaScript has remained the same:

To deobfuscate the landing I take a few steps:

I search for the string Decrypter (which is how this obfuscation works)

I decrypt all the used functions and words

Inline replace all once used variables

Remove values that have been split into one (like var a = 'from'+ 'Char' + 'Code' kinda things)

Clean up the code (remove unused variables)

Give it proper names so it makes sense (obfuscator removes sensible names so we pick our own based on context)

The first part is finding the string decrypter. Because I have already looked at Fiesta in the past immediately spot it. It has been split into two separate calls with a wrapper function:

The interesting fact is that because the obfuscator of Fiesta didn't change (as shown in the picture) the old string decrypter still works. The only thing that needs to be changed is the 'masterkey' which you can see in the 'messop()' wrapper function:

Now how does this string decrypter come together from the previously shown obfuscated code ? Simple, the top section of the decrypter function is in fact the (cleaned up) code from the 'bonyv()' function and the bottom section of the decrypter function is the (cleaned up) code from the 'seam9j()' function. I've cleaned it up a bit to give it sensible names of course.

We can now replace all the calls to the original wrapper function named 'messop()' with the real string using the decrypter:

As you can see most of the declared variables at the beginning of the document are global variables. After decrypting all the strings in the landing page we can start inline replacing these global variables (meaning something referencing 'lintl' will become 'window.document' as an example, this makes the code much more readable). After clean up, the landing page structure is clear; checks for plugins and such are now visible although the naming doesn't make much sense (yet). After changing the names based on context of the page we get a nice and clear picture of what the landing page does:

As I did in my previous blogpost you can spot the used CVE's just by comparing the version numbers being checked against known CVE's for the checked plugin. This gives us a list of the following software being targeted by Fiesta in 2015:

Adobe Flash

CVE-2014-8439: Adobe Flash Player before 13.0.0.258 and 14.x and 15.x before 15.0.0.239 on Windows and OS X and before 11.2.202.424 on Linux, Adobe AIR before 15.0.0.293, Adobe AIR SDK before 15.0.0.302, and Adobe AIR SDK & Compiler before 15.0.0.302

CVE-2014-0497: Adobe Flash Player before 11.7.700.261 and 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux

Adobe PDF

CVE-2010-0188: Adobe Reader and Acrobat 8.x before 8.2.1and 9.x before 9.3.1

Java

CVE-2012-0507: Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, and 5.0 Update 33

CVE-2013-2465: Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier, and OpenJDK 7

Silverlight

CVE-2013-0074: Microsoft Silverlight 5, and 5 Developer Runtime, before 5.1.20125.0

Microsoft Internet Explorer

CVE-2013-2551: Microsoft Internet Explorer 6 through 11

Something interesting to note about the Fiesta exploit kit landing is that it completely focuses on Internet Explorer. The way the presence of Adobe PDF, Adobe Flash, Java plug-ins is detected means it will only work with Microsoft Internet Explorer. It uses the ActiveX controls for all the plug-ins which is specific for the Microsoft browser. The last CVE from the list, the one for Internet Explorer self is also accompanied with a check to see if the system is 64bit by looking for 'x64' or 'Win64' in the user-agent. This is most likely due to the ROP chain used in the MSIE exploit.

Based on this information it means that the Fiesta exploit kit will not work on any other browser besides Internet Explorer. (This is unless the landing page is regenerated per type of browser on the server-side but I haven't seen it change).

Following the flash exploit landing page trail

From the network capture we were able to determine that my VM was exploited with a Flash exploit. By comparing the Flash exploit URL with those present on the landing page we can see that CVE-2014-8439 was used, this gives us a bit of a starting point. This CVE was originally spotted by @kafeine who found it was a 0day at the time used by the Angler exploit kit, read his post about it here: [CVE-2014-0569 (Flash Player) integrating Exploit Kit] He had an analysis done together with F-Secure: [Out-of-Band Flash Player Update for CVE-2014-8439]

After decompiling the ActionScript from the exploit we get a relatively small piece of script (largest part is a static block of encrypted data at the end, not in the screenshot):

After cleaning up it makes some more sense:

The script in the screenshot is not complete, there is a function I'm not showing which is the 'LoadComplete' function set as a listener on the complete of the 'loadBytes' function. This function is really small and looks like this:

What happens here is that the stage 2 data is appended as a 'child' of the root/main object, and stage 2 is in fact another flash file (hooray for obfuscation against detection...). Via the 'addChild' function the stage 2 flash file will become active. After dumping the decrypted stage 2 data from memory we can spot the Flash file header, highlighted inside the red box:

Decompiling this Flash file gives us an ActionScript file of about 820 lines. I'm not going to go into the exploit itself in depth, if you want to know how the exploit exactly works there is a great article written by Chun Feng from Microsoft. His article: [An interesting case of CVE-2014-8439 exploit]

Basically the ActionScript from the screenshots is the 1st stage and only functions as a packer/loader for the actual exploit. In the 2nd stage the actual exploit is used to gain control of execution. To gain control of execution the garbage collector is abused. Inside the garbage collector there is a pointer to an ITelemetry object which is used by the garbage collector. Via a specially crafted ITelemetry object that has a crafted VTABLE control is gained of execution. The modified VTABLE for the ITelemetry, instead of pointing to the valid ITelemetry functions, points to the shellcode. As said by Chun in his article, the control will be transfered to a set of ROP gadgets via the modified VTABLE entry for 'ITelemetry.IsActive()', this function is called when a garbage collection occurs.

After decompiling the embedded flash file (stage 2) we get a single action script file. In the function called on initialization of this flash file we find something interesting. The code starts referencing one of the variables given to the flash file on the landing page and later calls some function with this variable's data:

If we follow the function called with our landing page variable data called 'seatk' we hit something that looks familiar from the initial landing page. Its the string decrypter function although slightly modified:

It seems the Fiesta actors made one encryption/obfuscation scheme work and applied it to different aspects of their exploit kit. The ActionScript version is slightly different in implementation (this is also because of the fact that a decompiler doesn't bring back the original code) but it does have a similar structure as the other function. The decoded data returned from this function is the shellcode which is combined with the ROP chain to infect the host. Because this flash vulnerability (CVE-2014-8439) is quite recent and no POC is available I will not go into any details of the vulnerability (as I don't want to explain how to (ab)use it). Maybe at a later date I can revise this blog but for now I won't be handing out details of this one :). We've already learned some things about the way Fiesta currently uses exploits:

Landing page parameters are used for shellcode / payload download information

The exploits have a layer of packaging against detection (which can be swapped/changed quickly to become 'FUD')

The 3 stage exploit setup shows it to be a sort of framework in which individual pieces can be easily swapped out.

So, skipping from the Flash exploit let's jump into something a bit more easily readable and known in terms of exploits: Java. I agree this is a bit of a jump and I'm not going to go all detail into the Java exploit starting from the landing page like with the Flash one. I'm just going after the payload decryption.

Jumping into Java based payload decryption

The Java exploit is a sample for CVE-2013-2465:

5c6c4a6a4c5adc49edabd21c0779c6e3

. We can also find it in the landing page, the 'JavaExploit_CVE20132465' function shows the embedding of the Java applet.

Opening up the decompiled JAR file we get some slightly obfuscated Java code. One function jumps out as it seems to be dealing with execution of the downloaded payload, after cleaning up we get a clear picture of how the payload is downloaded:

First thing we can see at the top of the function is the fact that it seems the Java exploit for Fiesta seems to support download and execution of multiple payloads.

After downloading a payload the first 256 bytes are read, these actually contain the XOR key for the rest of the payload. We can actually spot the 256 bytes difference in size by looking at the payload dropped my virtual machine and the one downloaded over the line:

The important section of the shown Java code is the 'Decrypt' function. Here a block of encrypted data is decrypted with the 256 byte XOR key. After deobfuscation it looks like this:

The first part uses two indeces which increment for every byte that is decrypted (and is masked with 0xFF to stay inside the 256 byte block for indexing). The values of the key located at the two indeces are swapped, summed and again masked to form the final key location for the XOR operation.

This XOR decryption is performed on the whole PE data retrieved which gives a clean binary. From the previous segment of code we can also see the payload filename on disc is numeric and based on the current time of the machine.

After converting the Java code to Python we can decrypt the payload easily, success:

Were done it seems, we can successfully decrypt the dropped payload for Fiesta. Lets try this on the payload from the flash exploit which we looked at earlier:

Seems it doesn't work... Decrypting the payload for either Flash, Adobe PDF or Silverlight exploited machines gives the same failed results. It seems exploits which use shellcode based execution control, rather than the plain Java code, use a different encryption scheme, annoying. We can see that there's a different size for the original 256 byte XOR block previously seen from the decrypted payload on disk and the payload transferred over the line for any shellcode based exploits:

We need to look at a shellcode based exploit. We've already had a look at the Flash exploit but stopped at the point of exploitation, followed a Java exploit and were able to decrypt this payload now its time to look at another type: Adobe PDF.

Diving into an Adobe PDF exploit

The sample for this one is: f4346a65ea040c1c40fac10afa9bd59d. For PDF analysis I'll grab peepdf a tool developed by a colleague of mine, Jose Miguel Esparza (I also have to thank him for helping in the shellcode analysis later on in this blog entry, thanks Jose!!). Lets open up the PDF and look at the initial information we get:

Peepdf tells us there's an AcroForm and some JavaScript. If we take a look at the AcroForm we can see the Form actually uses the JavaScript, its invoked upon initialization. First follow the object relationships until we hit the form (XFA):

If you scroll down into the actual AcroForm script we can find the initialization setup and the actual (obfuscated) JavaScript for the exploit:

Lets clean up the code and get to the final 'stage' where exploitation happens. In this piece of JavaScript a malicious image object is created with some shellcode in it:

Extracting the 'expl_imgdata' value before assigning it to the image we can decode it (base64) and have a look at the shellcode. In this shellcode we find the actual decryption function and its completely the same as the one from the Java exploit, so what is happening ? A bit before the 256 byte XOR key there are 16 (extra) bytes which hold information. In the shellcode the payload is downloaded, then the first 16 bytes are used to determine the actual payload size amongst others, these size values are XOR'd however. The first 4 bytes is a XOR key for the next 12 bytes. A visual explanation:

To decrypt this payload we can skip the first 16 bytes and it will be exactly the same as before... right? Well, there's a bit more decrypted output data than expected, 25 bytes more to be precise. After these 'extra' 25 bytes the normal MZ header begins and we get the valid PE. So what is in there ? More information needed to drop the file on the system! The data before the MZ header is the filename size, the filename on disc as well as the actual payload size:

By stripping this information we get a fully working PE file, finally we've decrypted the payload by Fiesta for all types of exploits! The fix for shellcode based exploits is to skip 16 bytes, remove the first 25 bytes of the decrypted output as well as the last byte of the decrypted output. The final output comes with one nullbyte extra at the end. The decrypted sample from this run is 31af1a5656ce741889984e8e878c7836 you can download a copy of it from malwr [ here ]. To conclude this blog, I've written a Python script that decrypts any Fiesta payload extracted from network data, I've tested it against the last 10~ Fiesta EK hits published by Brad on malware-traffic-analysis.net and it works flawlessly! It takes two arguments, input filename (1st) and output filename (2nd). It will output valid PE files for shellcode based exploits as well as non shellcode based ones. The script is available from Github, it is part of my tools repository: https://github.com/0x3a/tools/blob/master/fiesta-payload-decrypter.py

Of course due to this publication and tools the guys from Fiesta might change their tactics, if the tool doesn't work anymore let me know! Hopefully you've enjoyed reading this rather lengthy blogpost, if there's any question you know where to contact me ;)

#exploitkit

Trending Tags

Recently Viewed Tags

#exploitkit