2015-09-17 - GUEST BLOG post BY HARDIK SURI - A CLOSER LOOK AT NEUTRINO EK

NOTES:

 

THE NEUTRINO EK EXAMPLE

This blog entry documents some of the techniques I use when digging into artifacts from exploit kit (EK) traffic.  Today, we'll look at the landing page, Flash exploit, ROP chain, shellcode, and Javascript used by Neutrino EK.

Neutrino EK has an interesting infrastructure in place to add/modify exploits to its arsenal.  Lets look at an example from Monday 2015-09-14 posted by Brad ( link ).  The landing page isn't complicated, with no obfuscated script and a link to one Flash file.


Shown above: Neutrino EK traffic from the pcap filtered in Wireshark.

 


Shown above: TCP stream showing the EK landing page and the Flash exploit

 


Shown above: Exporting the objects from the pcap in Wireshark.

 


Shown above: The EK landing page and Flash exploit from Wireshark's HTTP object list for the pcap.

 


Shown above: The EK landing page, highlighting the URL for the Flash exploit.

 

You can extract the Flash exploit from the pcap using Wireshark (in this case saved as: flash.swf).  Opening the Flash file using the JPEXS Free Flash Decompiler (FFDec) gave me some info about its nature.  Using FFDec, you'll find another Flash file embedded inside in the form BinaryData.  The four BinaryData streams can be used to construct a new Flash file.


Shown above: The Flash exploit opened in FFDec.

 

EXTRACTING THE SECOND-STAGE FLASH FILE

To manually extract the second stage file, I dumped all the important files (script and BinaryData) using FFDec.  Next, I added the following embed statement with corresponding BinaryData name to all files which extend ByteArrayAsset class.


Shown above: Text added to one of the class files (c.as) extracted from the Flash exploit with FFDec.

 

Loading another Flash file in memory involves creating a Loader object, then passing the Flash bytes to it using a method called loadBytes().  The trick is to write these bytes to a file before loading it.  This can be achieved by adding following lines:


Shown above: Text added to hvbfzupxggwpg.as, one of the files extracted from the Flash exploit with FFDec.

 

Compile the modified Flash code with MXMLC (Adobe AIR SDK 13).  Open the newly-compiled file using any version of Flash standalone binary.  You should see a dialog box asking to save the second-stage Flash.

Shown above: Using Flash player on the newly-compiled Flash standalone binary.

 

Open the second-stage file in FFDec, and you'll find the massive obfuscation technique Neutrino EK has deployed to evade detection.  The exploits are embedded inside this flash file as RC4 encrypted BinaryData.


Shown above: The decoded Flash file, opened in FFDec.

 

I was able to reproduce following exploits:

Now based on version on the victim's machine, the appropriate the exploit would be decrypted and loaded in memory using the same loadBytes() technique.

 

ROP CHAIN

Return-oriented programming (ROP) chains vary from exploit to exploit in this kit.  The chain may use VirtualAlloc or VirtualProtect depending upon the available gadgets.  One of the exploits uses pop-copy technique to place the real gadgets on the original stack from heap.  The chain pivots back to the original stack before calling VirtualAlloc.  This may evade some of the behavior-based solutions out there, which look for ESP out of legitimate range to confirm stack pivot.

 

SHELLCODE

Neutrino EK's shellcode has a common layout for all exploits.  It uses minimal APIs to get the shellcode going unlike other EKs.  First, it uses the JMP-CALL technique to locate itself in the memory, followed by decrypting the shellcode with one byte XOR key (97).

 

Next, the shellcode calls kernel32.GetSystemInfo to get the number of CPUs the victim machine has.


Shown above: Reviewing some of the Neutrino EK shellcode using OllyDbg.

 

This technique has been used by Neutrino EK for a long time to evade any virtual environment which has only one CPU.  The shellcode then subtracts 1 from the count and checks if it is zero.

 

Next, the shellcode calls kernel32.CreateProcess with complete Javascript as its argument.  This Javascript passed is responsible for downloading the payload.  The shellcode is pretty much over after this as the control is now passed to the Javascript file.

 

JAVASCRIPT PAYLOAD

Below is an image of the Javascript file used for this particular infection chain.

 

Next, the Javascript file is started with arguments.  The arguments passed follow the order:

 

In this particular case I got:

 

FINAL NOTES

This blog entry documents some of the techniques I use when digging into artifacts from EK traffic.  We looked at the landing page, Flash exploit, ROP chain, shellcode, and Javascript used by Neutrino EK on 2015-09-14.

 

Click here to return to the main page.