Showing posts with label SWF Debugging. Show all posts
Showing posts with label SWF Debugging. Show all posts

Monday, August 29, 2016

Neutrino Exploit Kit - SWF Analysis

Neutrino Exploit Kit is not new a member in the cyber space arena. The kit is now around for a while and has improved quite a lot over the months. This blog is a small walk through about the obfuscation methods employed by the kit.
A typical Neutrino Exploit Kit's SWF looks like below,



Neutrino uses RC4 algorithm for encrypting the inner SWF. The key and the encrypted SWF itself is embedded as binaryData in the outer SWF (as seen in the above image). To decrypt the SWF, you first need to find the binaryData that has the key and another binaryData(s) which holds the encrypted SWF. This can be achieved by looking at the actionscript, below snippet from actionscript reveals that the encrypted SWF spans across couple of binaryData files.



The decryption loop can be ported to a python script for repeated use. Pointing the script to the extracted binaryData files that has the key and the encrypted SWF's (binaryData files) will output the decrypted SWF file.

def decrypt(param1, param2):
    temp_ba1 = bytearray()
    temp_ba2 = bytearray()

    temp_1 = 0
    while(temp_1 < 256):
        temp_ba1.append(temp_1)
        temp_1 += 1

    temp_1 = 0
    temp_2 = 0
    while(temp_1 < 256):
        temp_2 = temp_2 + temp_ba1[temp_1] + param1[temp_1 % len(param1)] & 255
        temp_3 = temp_ba1[temp_1]
        temp_ba1[temp_1] = temp_ba1[temp_2]
        temp_ba1[temp_2] = temp_3
        temp_1 += 1

    temp_1 = 0
    temp_2 = 0
    temp_4 = 0

    while(temp_4 < len(param2)):
        temp_1 = temp_1 + 1 & 255
        temp_2 = temp_2 + temp_ba1[temp_1] & 255
        temp_3 = temp_ba1[temp_1]
        temp_ba1[temp_1] = temp_ba1[temp_2]
        temp_ba1[temp_2] = temp_3
        temp_ba2.append(param2[temp_4] ^ temp_ba1[temp_ba1[temp_1] + temp_ba1[temp_2] & 255])
        temp_4 += 1

    return temp_ba2

def main():
    param1 = bytearray(open("C:\\Temp\\binaryData\\2_c.fcvtaaslrv.bin", "rb").read())
    param2 = bytearray(open("C:\\Temp\\binaryData\\5_c.rkrzaajqnespsnx.bin", "rb").read())
    param3 = bytearray(open("C:\\Temp\\binaryData\\4_c.zkqctptzgek.bin", "rb").read())

    for byte in param3:
        param2.append(byte)

    data = decrypt(param1, param2)

    f = open("C:\\Temp\\binaryData\\decrypted.swf", "wb")
    f.write(data)
    f.close()

if __name__ == '__main__':
    main()


When loading the decoded file into decompiler, it reveals the true nature of the SWF.



The inner SWF also has a bunch of binaryDatas embedded. These binaryDatas are also RC4 encrypted and they can be decrypted by a pre-defined key specified in the inner SWF's actionscript block.



RC4 decrypting each of the embedded binaryData with the above highlighted key file reveals multiple other exploits. One such encrypted SWF inside inner SWF below.



Friday, July 29, 2016

Graphical representation of SWF - Dendrogram

Given the amount of obfuscation that's getting added to SWF files, it can be sometimes painful to analyze them. Going through a huge SWF file can be time consuming and irritating. A graphical representation can always give a perspective of what the SWF is all about and can give a head start during the analysis. In this blog post we'll see how can we create dendrogram graph out of a SWF file for the purpose of analysis.

For creating the dendrogram I first used the JPEXS FFDec library to decompile the file and fed it into a small python script that creates a CSV file. This CSV file can be further fed into "D3.js" to create a graphical representation of "intermodular" calls, "strings" in the class files along with the "imports" (We can add multiple other elements to this - but for now, this will do). Below is the CSV file that was created by the python script post processing each ".as" file from the SWF.


Feeding the CSV file to "D3.js" for dendrogram paints a graphs which can give us a little overview of what's going on with the SWF.


Looking at parts of the graph we can conclude that this SWF exploits CVE-2015-7645 - a Type Confusion vulnerability in Adobe Flash Player.



This exploit is dropped by Angler Exploit Kit - We can also find a key within the SWF that is used during the decrypting payload.



Analyzing the SWF further revealed multiple class files calling a specific module frequently - "class_2.method7". Looking into the source code reveals that this function helps during de-obfuscating strings during run time.


Representation of SWF in graph can be very useful in giving us a little insight about what we are up to. All be it, this doesn't provide a complete picture about the SWF, but nevertheless the output reveals more than useful information.

Thursday, June 9, 2016

CVE-2016-4117 hidden in binaryData

Loading the SWF into FFDEC looks like this


The flash file holds a binaryData which when decrypted becomes another flash file that exploit CVE-2016-4117. The logic to decode the flash file looks like below,


while(_loc6_ < _loc4_)
{
 _loc3_[_loc6_] = _loc3_[_loc6_] ^ _loc5_;
 _loc6_++;
 _loc5_ = _loc5_ + 17 & 255;
}

Simple porting of the above script script to Python for decoding the binaryData blob.


def main():
    data = bytearray(open("binaryblob.bin", "rb").read())
    length = len(data)
    key = data[length-1]
    for i in range(0,length):
        data[i] = data[i] ^ key
        key = key + 17 & 255

    f = open("C:\\decrypted.swf", "wb")
    f.write(data)
    f.close()

if __name__ == '__main__':
    main()

And the decoded file looks like,
  

The base flash file has additional code to confirm if it has decoded the flash file properly. It checks few decoded bytes to confirm if everything worked fine.


The base flash file also has another trick up its sleeves. It has function that does the shellcode substitution. This function searches the decoded flash file for "NOSP SLED" (9090909090....) and replaces it with the shellcode from the base flash file.


This probably is done by the attackers for speedy replacement of shellcodes without touching the concealed flash file. So the decoded flash file before and after replacement of the shell looks like below.

Thursday, April 21, 2016

Decoding Angler Redirect SWF using JPEXS FFDEC

Of late Angler Exploit is seen to use SWF that redirects an unwary user to Angler Exploit Kit gate website. This SWF is not highly obfuscated, but encodes the redirection HTML code using "base64" and has a little algorithm that decodes the string post "base64" decoding. Below is the decoding logic, the function takes 2 arguments, "param1" is the "base64" decoded string and "param2" is an integer that passed through "Flashvars" from HTML code.

"Base64" encoded string below which is later decoded and passed to "de" function above.


"param2" that's passed from HTML code,


Lets use FFDEC to get the HTML code. FFDEC now supports SWF file debugging. You can set breakpoints on the "actionscript" code and observe what's happening to the variables, stack calls etc.

In order to get the code that redirects to Angler Exploit Kit, place a breakpoint on "return _loc3_;" (that return the decoded HTML) line in the "de" function. Running the SWF after placing breakpoint will yield us the HTML code responsible for the redirection.

Note: You can use the edit function in FFDEC to replace "param2" with '3' (check value of param2 in below snapshot) as passed from the HTML code. Debugging the SWF should break at "de" function and display the HTML code as seen below.


Thanks to the developers of "JPEXS Free Flash Decompiler" for this wonderful tool.

Tuesday, October 20, 2015

RABCDASM Angler SWF

Angler SWF has long since started using SecureSWF obfuscator to obfuscate it's SWF exploits. Analyzing SWF files obfuscated with SecureSWF can sometimes be a painstaking job. A sample SWF obfuscated with SecureSWF when loaded in ffdec will look like below. ffdec can help rename identifier, but without that option this how the SWF looks.



SecureSWF substitutes the important strings used within its code with its own function. This function is responsible for then returning a meaningful value that later gets used in the code. A small fragment of the code from Angler Exploit Kit that's highlighted below.


When the code starts executing the code "§_a_-_---§.§_a_--_--§(-1820302794)" code gets executed and the returned value is assigned to the variable "_loc2_". Looking up and solving this manually can be very time consuming and at times (actually everytime!) very irritating. The function "§_a_-_---§.§_a_--_--§" is responsible for taking a single argument and XOR it and use it as a index to lookup into a ARRAY.

The trick here is to use RABCDASM tool, disassemble the SWF file, add the routines that's required for us to reveal the returned data from the function at "§_a_-_---§.§_a_--_--§" and repack the SWF again. Well it can sound complicated but it will become easy as it goes on.

First we disassemble the SWF. For this we execute couple of commands on the SWF.


After executing the above commands, we get a folder with the all the disassembled class files, in this case - "3-0".

To ease things we add an helper function to the mix. This helper function will aid in printing out the required output (in our case the function results of function "§_a_-_---§.§_a_--_--§"). This helper function either can be pushed into one of the existing "*.script.asasm" files or into a separate file. Below is the helper function, this function sends out a "HTTP" request to the localhost with the actual string that's deobfuscated (the index + the deobfuscated string. Well it's not actually obfuscated but I don't know how to name it >:(.


We compile this ActionScript and disassemble it. After disassembling this has to be included with the existing code. This can be done by just adding a "include" statement to the "main" script asasm file, in this case "3-0.main.asasm". Below is what the folder structure and the "main" asasm file looks like.


Now is the time we edit the "§_a_-_---§.§_a_--_--§" function to push the deobfuscated string. Code below helps us achieving this. This code is responsible for calling the helper function that sends out the HTTP request with the index and the deobfuscated string.



Following this all the class files needs to be compiled, this will yield us the edited SWF file. Below commands helps us get there.

We verify if everything has panned out as expected. Take a look at the SWF under decompiler now.



As it turns out everything worked as expected. We now load the SWF into the browser and voila we get the data we are after (with the dumbest possible way :). Take a look out Fiddler.


There are multiple other ways to dump the strings,

  • push it to a textbox
  • push it to SharedObject
  • push it to flashdebug log under debugger version of flash
and plenty more.

References:
http://h30499.www3.hp.com/t5/Security-Research-Blog/Playing-with-Adobe-Flash-Player-Exploits-and-Byte-Code/ba-p/6505942

Wednesday, June 27, 2012

Debugging SWF with Flash Debugger

Pretty much out of action for so many days now. This blog will discuss about the very widely used way of debugging SWF files. All you need is to download the latest version of "Flash Debugger" from Adobe download site and we are off.

After installing "Flash Debugger" there are configurations that need to be made so that the logs are directed to a text file. I'll not re-invent the wheel as Adobe has already explained it well here.

For purpose of demonstration we'll look into an SWF that's used in exploiting CVE-2011-2110. We'll not get into the details on the vulnerability but the malicious SWF that exploits this vulnerability uses the encoded PARAMETER passed to it to download the malware on to the machine. The request to the malicious SWF is seen in the below Wireshark request.


The SWF when loaded into the browser retrieves the value from the parameter "info" and decodes it to form an URL from where the end malware is downloaded. The decoding routine is fairly simple. At first the value is converted from hex to bin later an XOR ^ 122 is imposed on the converted data and the resultant  data is uncompressed. Part of the ActionScript that's responsible for decoding the value can be seen below.


The function "hexToBin" is a custom function and the ActionScript source for the same can be seen below.


We can rip these above mentioned code apart and put them into a "temp.as3" file. "As3compile.exe" from SWFTOOLS can be used to compile this ActionScript file. Analyzing the above code it's evident that the decoded URL is stored into "t_url" variable. All we need is to use the "trace" function which can be used to write the values of variables to the log file (either here -  "Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs\flashlog.txt,or here  "Users\username\AppData\Roaming\Macromedia\Flash Player\Logs\flashlog.txt,").

So the modified code looks something like below,


package test
{
                import flash.utils.*;
               
                public class Main extends flash.display.MovieClip
                {
                                public function Main()
                                {
                                                trace("Inside Main");
                                                var url:String;
                                                var t_url:flash.utils.ByteArray;
                                                var arg1 = "02E6B1525353CAA8AD4D48CAAAC9CEAA4949A84948AE0DAF51D3527B7A22A87CC1";
                                                t_url = hexToBin(arg1);
                                                trace(t_url);
                                                var i = 0;
                                                while (i < t_url.length)
                                                {
                                                                t_url[i] = t_url[i] ^ 122;
                                                                ++i;
                                                }
                                                t_url.uncompress();
                                                url = String(t_url);
                                                trace(url);
                                }
                                public function hexToBin(arg1:String):flash.utils.ByteArray
                                {
                                                var loc1 = null;
                                                var loc4 = 0;
                                                var loc2 = new flash.utils.ByteArray;
                                                var loc3 = arg1.length;
                                                loc2.endian = flash.utils.Endian.LITTLE_ENDIAN;
                                                while (loc4 < loc3)
                                                {
                                                                loc1 = arg1.charAt(loc4) + arg1.charAt(loc4+1);
                                                                loc2.writeByte(parseInt(loc1, 16));
                                                                loc4 = loc4 + 2;
                                                }
                                                return loc2;
                                }
                }
}

When the above ActionScript is compiled you get a flash file as output. Opening the flash file in Internet Explorer will print the result decoded URL into the log file. This malicious flash file after exploiting the vulnerability downloaded an EXE from http://208[.]98[.]62[.]21/E[.]txt (this is the decoded value from the "info" parameter passed to SWF) which at the time was writing wasn't reachable.