A new version of the Rig EK

It looks like the developers of the Rig EK have been busy.

In my last post Pulling apart Rig Exploit Kit we see the way the decompiled flash file looked. It used several action script files and used 2 different configuration/replacement arrays to do its work. They used a combination of RC4 and AES to decode the embedded binary’s to get the arrays.

The first sample of this new version I have found is 2016-09-08 – EITEST RIG EK FROM 185.117.73.140 from Brad @malware_traffic and found here http://malware-traffic-analysis.net/2016/09/08/index2.html . If you read that article you see the the EITest campaign was back after a short pause.

If we take a look at the flash file from 2016-08-31 – EITEST RIG EK FROM 185.117.72.99 Here http://www.malware-traffic-analysis.net/2016/08/31/index2.html and do a quick check with SWF Investigator we see this.

OldRigSWFI

Here we have multiple Action scripts and 5 defined binary data items.

If we look at the new version we see this.

NewVersionSWFI

This one only has 2 action script files and 1 defined binary item.

The first few that I looked at had the same “Names” but after that I have seen a change.

So what in the world did they do here.

Lets open this up in “JPEXS Free Flash Decompiler” from Here and see what we find.

Overall1

We can see here that is has changed and starts out with a with the check for.

SecCheck

Next we scroll down to the the decoding function for our embedded byte array.

Code-1

and here

Code-2

Do you notice anything strange about this ?

There are several “this.init” assigned the same name. So what gives.

If you didn’t notice in the above screenshot this flash is obfuscated by the DoSwf tool.

If we go to their site then we see this.

DoSwfMain

And on another page we see this.

DoSwfRename

So that explains it.

After an Issue was submitted on the “JPEXS Free Flash Decompiler” site in their issue tracker, within a few days there was a new version available that can help with this problem.

So thank you Jindra Petřík (aka JPEXS) for fixing this so quickly. I’m sure most issues don’t get fixed as quick though.

So what does it look like afterwards.

Before setting the checkbox to auto rename  classes  we can see the name are not readable.

BeforeRename

After

Overall2

And a closer look at the code.

NewCode1

If you notice now there is an index number on the end of the names to make them distinguishable. Now that we have an idea of what goes where lets take a look at the embedded binary.

Bin1

Ok so how do we read this ?

If we take a quick look at the SWF File Format specification then we see this about bytes and unsigned integers.

SwfSpec

So we read the bytes like so.

bin1-b

Now we can look at our code again.

NewCodeVals

The first thing this does is pull our data bytes out. “_loc2_” will be our new byte array formed from the last “init#24”(0x5640) length bytes from the embedded byte array.

While less than this length it will do a nested while on lengths of “init#27” (0x14)  Xor’ing the byte at the index position by “init#26”(0x60) , each loop it will add 7 to the index.

Once it completes this loop it will then do a Un-compress. One thing to note is that this is using the ZLIB version not the same version that Neutrino was using.

So what do we get when we get done ?

Decodedbin 

As is, this will not load in a decompiler do to what ever it was that the DoSWF has done to it.

If we scroll down our code more we have an idea to help us to figure it out.

NewCode3

Looking at this it tells us it is taking the first byte and reading it in as a Boolean value. If True it will just go to the function  “this.garbageBytes#23” and create a garage Swf byte array.

If false then it will continue on and check the next byte which in this case appears to result in “True” .

Next it will take the next 4 bytes to get the length in LittleEndian byte order for a new Flash byte array.

That is about as far as I have gotten on this right now.

As you can see there is more research to do here and time to dig back into the SWF File Format specification to see if I can find a way to get this to load into a decompiler.

That it for this one I hope it helps someone.

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, Networking, security and tagged , , . Bookmark the permalink.

3 Responses to A new version of the Rig EK

  1. Vinod Yadav says:

    Thank a lot for such a detailed analysis of SWF file. I do have question that how you get the value for below functions as the commented value in the binary named 65531 as commented below
    this.pieceLen = _loc1_.readUnsignedByte() – 1; (init#27=15)
    this.isAS3 = _loc1_.readUnsignedByte() – 5;(init#26=65)
    this.pieceLen = _loc1_.readUnsignedInt() – 7;
    this.bytesLen = _loc1_.readUnsignedInt() – 3;

    can you please explain a bit more here that how to get these values

    Thanks in advance.
    Vinod Yadav

    • These are the bytes from the embed binary. I stepped thru with a debugger to verify Which byte was used in order. you take the bytes and subtract that amount and then that is what the final value is.

      These amounts are then used in the script below that function.

      They have changed again and are no longer using this type in the samples that I’ve looked at.

  2. SecPistol says:

    Thank you for the detailed and enriching content.
    If you need help with opening the inner flash file don’t hesitate to contact me through the email

Comments are closed.