A look at a cross bred Neutrino EK–Rig EK Flash file

A recent post by Jérôme Segura of Malwarebytes https://blog.malwarebytes.com/threat-analysis/exploits-threat-analysis/2016/08/neutrino-ek-more-flash-trickery/

Although this post showed the flash file being sent from the compromised site rather than a “Gate” is interesting. What is more interesting is what is inside of this flash file.

After decompiling the the second level of this flash file the fist thing I noticed was the file structure.

Folderdiff-b

To me this folder structure and naming convention looked more like the Rig EK than Neutrino EK.

If we take a look inside this to find where the configuration file gets decoded we see this.

Config-Decode

Interestingly enough if we look at the Rig EK sample from Broad Analysis here http://www.broadanalysis.com/2016/08/15/rig-exploit-kit-from-185-158-152-195-delivers-zbot-banking-malware/

As we can see here.

Config-Decode-Rig

Besides the naming of the variables these two functions are the same, what they do after that is somewhat different though.

After beating my head against the wall for a couple of days trying to figure out these weird loops I finally broke down and  took a crash course how how to crash a flash debugger.

Ryan Chapman @rj_chap in his BSides presentation here was using FlashDevelop from Here http://www.flashdevelop.org/.  , so I decided to try and install it. After several try’s and Google I finally figured out how to get the the decompiled file to recompile with that program. After a few more hours of trying to figure out how to solve a problem of it throwing an error on readint() I finally gave up and abandoned that program. The break points didn’t break and a few other things about it makes me never want to try it again.

So I went back to the Free flash decompiler and figured out how to set it up to run as a debugger. That finally helped get me the last clues even though I was not able to step thru it like a normal debugger and see what all of the values were.

One thing this version did was, instead of using a normal RC4 Function like this.

RC4

They separated the functions inside to three different ones.

Exploded1

Our decode function from above will send the key in this part, build the SBox then it will be used in this section (below) for the final Xor.

Exploded2

It will then be returned to the original function and pushed as a string, basically to a list.

It will cycle like this several times, in this case 45 times.

A list of What? Well of replacements.

Decoder-b

And where are these used ?

UseConfig

And if we compare that to the last one I pulled apart.

UseConfig2

We can see here it is pretty much the same, but what are all of these values ?

Values1 

As it turns out this gets Xor’ed with a value from the embed binary data that gets the bytes reversed and converted to integer.

Values2

So if we Xor these numbers then we end up with something like.(The comment Values)

Values3

Which as it turns out does match up to the index values shown above in the decoder.

So how does this decode function work ? Lets look and the binary files and let them tell us.

BinFile-1-b

We skip the first 2 bytes, take the next 2 bytes and convert them to an Integer and that is how many times we will loop.

Next we skip 2 more bytes, take the next 2 bytes  and that is how many “Data Bytes’” we will take and add to the array of “Array Of Bytes” for later decryption.

Then skip 2 bytes again and repeat until you have looped thru the given amount of times.

In the Rig sample it was only 6 times.

I’m pretty sure I’ve seen this method used somewhere before.

Lets look at the Key file.

BinFile-2-b

And the number of bytes to get is called from this function.

Get16Bytes

Well that pretty much covers the bulk of this one.

So the question remains Which EK will this get identified with? This sample has both.

Is this just a trial run or a new way they will be built.

As it turned out my shiny new decoder did not work on the Rig EK sample even though they used the same method to pull the bytes.

The difference is however the Neutrino EK was running those bytes thru a RC4 decoder and the Rig EK sample was running them thru a AES decrypter.

So I guess I’ll have to build a new decoder for that one. Bummer.

This one is kind of short compared to the others but before I go 1 more thing.

While trying to update a new test system.

Windows7Update

Enough said.

Advertisements

About pcsxcetrasupport3

My part time Business, I mainly do system building and system repair. Over the last several years I have been building system utility's in vb script , HTA applications and VB.Net to be able to better find the information I need to better understand the systems problems in order to get the systems repaired and back to my customers quicker.
This entry was posted in Malware, security and tagged . Bookmark the permalink.

2 Responses to A look at a cross bred Neutrino EK–Rig EK Flash file

  1. Pingback: Pulling apart Rig Exploit Kit | PC's Xcetra Support

  2. Pingback: Neutrino EK: More Flash Trickery | Malwarebytes Labs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s