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 220.127.116.11 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 18.104.22.168 Here http://www.malware-traffic-analysis.net/2016/08/31/index2.html and do a quick check with SWF Investigator we see this.
Here we have multiple Action scripts and 5 defined binary data items.
If we look at the new version we see this.
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.
We can see here that is has changed and starts out with a with the check for.
Next we scroll down to the the decoding function for our embedded byte array.
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.
And on another page we see this.
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.
And a closer look at the code.
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.
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.
So we read the bytes like so.
Now we can look at our code again.
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 ?
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.
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.