I’ve spent the last few days going from top to bottom of 3 different Neutrino EK infections.
The one I will show here is from Broad Analysis @BroadAnalysis from their site http://www.broadanalysis.com/2016/08/08/new-c2-neutrino-exploit-kit-via-pseudodarkleech-hopto-org-gate-delivers-crypmic-ransomware/
You can download the pcap of the traffic from there.
Any one that has read any of my post before know that I prefer to do static analysis when ever possible. When facing a new piece of malware for the the first time it is like finding a piece of cipher text that needs decrypting.
Neutrino EK is similar to the complications of the Angler EK except they use so many flash files to hide what they are doing versus just scripting and encoding/encryption.
There are many great articles out there that have already covered most of what I could write so I will concentrate mostly on understanding the code and how to follow it. I will post a few of the links to some good articles that have help me put the pieces of the puzzle together at the end of this post.
By doing static analysis and creating most of my own tools I can change them and adapt them myself for what ever changes the malware authors may make.
The Neutrino EK is comprised of what I call 4 levels, 5 if you count the original flash file.
We will first need the JPEXS free flash decompiler which for me worked flawlessly in a VMware virtual machine using a never before used copy of 32bit Windows XP Pro that I have been saving for a rainy day since the sp2 version was still new. Trying it in Windows 7 64 bit kept crashing.
Once we extract/decompile the flash file we have a folder structure like this.
If we export everything then remove what is empty then that is what is left.
The first thing we will want to look at here is the scripts folder. The “binaryData” folder is the binary files we will have to work with later.
Here we see we have two action scripts outside of the other 2 folders.
I’m no action script Guru but this appears to be the entry point into this rabbit hole. It is creating a child or running the object referred to here which is the other file out side of the other 2 folders. So what is in that ?
Here we see that this is importing several items to use in the script we have 3 that start with “flash” so those are the native flash functions that are getting imported, but what are the ones starting with the “r’ ? to answer that question we go back to the the symbols file and look at it.
If we look at this and then look in the binary resource folder the names after the “r” match those files, so we figure the “r” is for resource , the last one on the list is our first file we looked at.
In the screenshot above we see in the red there is a variable but if we trace it down it is not used anywhere. They add a lot of code that does not do anything in order to help hide the small parts that do. In the blue we see more variables that are declared and set but never get used.
In the green though, it is setting “e” to the value of the function “m” which is the RC4 decoding routine, and passing 2 of the embedded binary resource files. After decryption, it is next sent to the “to string” method then splits it in to a “String Array” with the character “%” to be use later for replacements.
As you can see at the bottom this.e would equal, starting with index 0, “stage”.
(I missed separating the two at that one point in the screens shot above)
Here in the red box is yet another variable that is declared but not used.
In the blue box we see where it is assembling the byte arrays from the embedded resources. It is next run thru the RC4 decryption with the key and it returns another flash file as a byte array.
It then passes on to the “s” function where it pulls another byte array from the binary resources and passes it to the function “et” in the launched second level flash file.
What does this last part do ? it is the most important part of the whole operation. This is, once it get decrypted is the configuration file.
Fast forward to extracting the second level and locating the function “et”.
This passes the last byte array from the first level as param1 here and sets “s=s” to “param 1” and then it will call the function “s9s” if it has a event listener or it will add the result of that function call.
The main part we are concerned with in this one is it sets the value “s0s” to a string, does some check and will bail if they don’t pass and not decrypt the config. file.
We can see that the name of this function gets called from the last one if it is not found.
And what does the config file look like for this one after getting decrypted?
Or using a JSON Viewer it looks like this.
Here we can see that they can call out to several locations depending on what the result of the fingerprinting of the system is. It can give you nothing or the malware payload.
This is what my binary resource folder looks like after doing the decryption and decompressing.
The 3 new flash files only gets RC4 Decrypted and again depending on what the fingerprint is they get served up. The 3 html files and and the java script file each gets RC4 decrypted and and then have to get decompressed. This is a case where I made my own tools to work with these files in order to get the plain text.
The main fingerprint file to the best of my knowledge is the JS file. The only problem is it looks like this.
In order to decode it we have to take this function and the the var”v” and decode this into an array of string, which is what was show by @BroadAnalysis on a twitter post earlier today.
The very first time I worked with this I did all 70+ var replacements by hand , I’ve created a new tool to help with that now.
Here is what it looks like after the replacements. This code may not run but at least you get an idea of what is going on.
At this point we have a pretty good idea of how to decode this for each new level that is presented but what if we wanted to search around to see what connects to what.
I was having a problem where a tool I created some time back to look for stings in file was not finding the values as displayed by Notepad ++
As you can see here they are using some strange characters for names of the functions and classes. If you try and copy paste one of these in anything else and do a search for that string it does not find it.
I finally open one of these up in a hex editor and paid closer attention to the variable names and I seen this.
As you can see that looks different so what is up with that? As it turns out the answer came in the way I have been extracting the html pages. I had discovered on the first file I ever worked with that you can not just open the decoded/decompressed byte array with a hex editor and copy the string part to a text file because it can leave extra escape chars in it, that gets real confusing and a pain to clean.
This file above is actually one of the Action Script files that the flash decompiler extracted.
So based on the idea from the html files I use another tool I built a while back that will convert the hex bytes to a string using any supported encoding on the system, in this case it was normally UTF8 and after discovering this problem I found that UTF 7 would display what was in the hex file correctly. So I opened the Action script file in a hex editor and copied the bytes to this program to be converted using UTF7.
Now I can copy paste those names into my search tool and can find them anywhere in the sub folders to see what connects to what.
Before we move on to the level 3 code lets take a quick look at the script to decode a binary resource file.
As you can see there is a lot going on here to just load this iframe.
This is already getting long so lets move on to the last thing I want to show you that I have not seen mentioned before.
References to ‘MAC”
By this there appears to be checking if it is a “MAC”, there is one more flash file for a level 4 that can be decrypted. In 1 other sample I had worked with I found references to “MAC” in the extracted files, so I’m not sure if this will work on a “MAC” also or not. I’ve Never used one and have no way to test it.
As we have see here it can get quite confusing and difficult to travel thru these extracted files to see what does what.
After you learn the tricks and have the tools you can completely decode one of these in a matter of a few hours or less.
The analysis of all of the extracted code could take considerably longer though.
Well that’s it for this one , if you made it this far thanks for reading.
This helped with the last piece of the puzzle, the config file.
And this one.
Talks about an exploit added after someone published a POC
I’m sure there are plenty more good ones out there .
Let me know and I’ll try and add them.