Nuclear is one of the most sophisticated EKs out there in terms of obfuscation and exploit delivery mechanism.  [Editor's note: I would argue Angler is more sophisticated, but Nuclear is very interesting.]  In recent times, this kit has been aggressively adding newly patched exploits and even zero-day exploits to its infrastructure.  Let's look at an example from Monday 2015-09-22 posted by Brad ( link ).

Nuclear has done a good job in obfuscating the landing page.  No matter how obfuscated the page looks, finding the key functions does the trick.  In this case, I found a function containing the magical document.body.appenChild() statement.  This function is used to load new content into the parent body.  Putting a breakpoint before the statement should give you the de-obfuscated content passed to this function.

Shown above: Exporting objects from the pcap file.


Shown above: Selecting the landing page to export.


Shown above: Searching the landing page to find a function with document.body.appenChild().


Shown above: Snippet taken from the landing page.



Before we look into the content from the above step, let's first look inside the Flash exploit served by Nuclear.  I extracted the Flash file from the pcap and used JPEXS Free Flash Decompiler to review it.  Surprisingly, the file is quite readable ☺ (I was hoping secureSWF encryption).  Randomly browsing the Flash file got me to an interesting code snippet.  The snippet has some interesting strings.

Shown above: Code snippet from xbBEtmA.as (click on the image for a full-size view)


The highlighted portion is nothing but loadBytes string.  As mentioned in my previous blog entry on 2015-09-17 ( link ), this function is used to load the embedded Flash exploits in memory.  To find where this variable is being used, I used the same technique documented last time to save the bytes.

Shown above: Code snippet from qeCDpOUu.as loading the embedded Flash exploit in memory (click on the image for a full-size view)


The parent Flash contains two exploits.  Based on the version found, the appropriate exploit is loaded.

Shown above: Version check to load the correct exploit.


You should have both the exploits saved if you followed the previous blog closely.  Now let's dig into the contents loaded by the landing page.  One of the extracted files is an HTML loader for the parent Flash file.  The HTML looks something like this:

Shown above: HTML loading the parent Flash (click on the image for a full-size view)


The encrypted string passed to "exec" parameter is used by the second-stage/exploit files.  The exploit contains a simple substitution function which takes this "exec" parameter and converts into a hex string which is later used in the shellcode.

Shown above: Code snippet responsible for decoding the string passed to "exec" parameter.


Output from above function is shown in the image below:


The string is nothing but hex characters, though they don't make any sense right now.  The string is appended to the end of the shellcode.  Later during exploit execution, the shellcode is decrypted using a one-byte XOR key 0x5c.



That previous ASCII string when XOR-ed with 0x5c gives us some readable information:


In the above image, each sub-string separated by semi-colon defines the shellcode behavior.  The second sub-string is the XOR key to decrypt the payload while the third sub-string is the payload URL.

The first sub-string is the execution type opcode.  This defines how the shellcode should execute the payload.  It can take three values: 1, 2, or 9.

Shown above: Code snippet in shellcode checking the execution type.


The APIs/techniques for downloading the payload are not affected and follow the same routine in all three cases.

Shown above: List of APIs used in downloading the payload.


CASE 1:  The shellcode treats the payload as an exe file.  The dropped file is then executed using CreateProcessAsUser as shown below:

Shown above: Reviewing some of the shellcode using OllyDbg.


CASE 2:  The shellcode treats the payload as a DLL and loads it by creating a thread to loadlibrary() with the path to the DLL as thread parameter as shown below:


CASE 9:  I think this is the debug mode of the shellcode.  In this mode, the payload is downloaded and written to the disk but never executed.  Maybe, the exploit author added this feature to test part of the shellcode.

This flexible execution model is similar to Angler EK.  Angler goes a step ahead by adding a file-less infection option; however, Nuclear EK has this impressive setup which allows quick addition of new exploits.



Nuclear EK is striving to be more complex and sophisticated.  As shown below, the EK's authors also have a of sense of humor ☺.

Shown above: A message from the Nuclear EK authors.


Click here to return to the main page.