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.

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.

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.

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

SMILEY SWF to Exploit

Recently came across an interesting SWF that uses inventive ways of hiding exploits. This SWF was hiding the exploit very well inside completely legitimately looking SWF. The SWF was ofcourse coming over ADs from p0rn sites. What's interesting is how far deep inside the exploit was hidden within the legitimately looking SWF. Below is a snap from FFDEC when the SWF is loaded.

As seen the first level malicious SWF is hidden within the "DefineBinaryData" tag. This tag can hold multiple data blobs ranging from SWFs itself to JPG, MP3 etc etc. FFDEC helps loading the SWFs within "DefinBinaryData" tag directly. Loading so leads us to another SWF which again looks legitimate on the outset. Below is a snap of the same.

As seen there's a JPEG file embedded within the SWF. This JPEG file is whats hiding the SWF that triggers and exploit the vulnerability in Adobe Flash Player. Looking at the AS inside "prok" it becomes clear how the hidden SWF inside JPEG file is loaded into the memory.

Initially there are version checks for Adobe Player and OS. Based on the versions the script continues or aborts. Further into the script there are calls to the embedded JPEG file which is fed into the array and processed to form a SWF file.

And the data past the EOF JPEG file.

And the JPEG file itself.

The encoded SWF as seen above is decoded using a simple XOR key. Below script is what creates the key for decoding the encoded data.

And the decoded data as seen below forms a LZMA compressed SWF file. In the below snapshot the 1st XOR bytes corresponds to the bytes from the key and the 2nd XOR bytes corresponds to the bytes from the encoded data.

FFDEC snapshot of the decoded SWF.

VT scan results for the decompressed SWF file.