In the last post, A look at a cross bred Neutrino EK–Rig EK Flash file we see where the two exploit kits were merged into one.
This one is pure Rig and looks the same on the surface as other samples I’ve looked at.
The sample used here is from Brad @malware_traffic
The main differences between Rig EK and Neutrino EK are the the Neutrino EK uses a layered approach with multiple flash files and embed binary files that get decoded as needed. The Rig EK uses more of a scattergun approach. they use 1 flash file and multiple embed binary resource files.
They also split the functions into many classes, functions and parameters to make it more difficult to follow along. Some parameters/vars just get passed to a new ones and not used right away.
Note: My hats off to the person(s) that made the obfuscation tool the exploded this thing into 20 different files. That said I hope whomever it was is turned into a babbling idiot after writing it. I almost was trying to follow along with this crazy maze. I feel better now.
As mentioned above they are splitting everything into 20 action script files and are using 5 different embedded resource files.
They are using 2 different Xor functions to calculate the index value for the extracted replacement values.
They are also using the RC4 encryption for one set of replacements and AES 128 ECB for the other set of replacements for a total of 25 different values decoded for use as replacements throughout various parts of the code.
If we look at what the files look like in the folder normally after decompiling we see this.
But if we let it do a rename for us we see this.
That’s much Better and if we look at the Second file that it calls.
And after renaming it looks like.
If this looks familiar then that is because it is the same function from the last post. The difference is, instead of leading to the RC4 decrypter it is leading to a very well exploded self contained version of the AES decryption routine. It will work the same way passing the values to get decrypted.
I believe that they may have done it this way so there would not be a call to the built in crypto provider to raise a flag on what was used, or what they wanted was not available.
This version is only extracting 6 byte arrays to decrypt and 1 key. The last byte array is 2528 (0x09E0) bytes long and is listed as the shell code.
They do several things to this “Shell Code” byte array before it gets used anywhere. It gets sent to string, has another string tacked onto the end of it, get turned back into a byte array, gets reversed (littleEndian) , and that’s all I can remember off hand.
In this view of class_12 (file) we can see there is allot going on.
If you look close at the two “Calculate replacement index value”, you will notice that they are calling two separate classes. Although they are two separate classes the number that those values gets XOR’ed with is the same number. The class_14 gives you the value for the index number to calculate in the RC4 decode, the class_2 is the extracted and reversed binary value and converted to Integer to get the value to XOR with, that is for the AES decode.
Here we see the the start of the RC4 decode routine with the value (var_78) that is used to do the XOR to get the index value.
and here is the XOR routine.
I the screenshot above I was comparing the the values from the the RC4 and the AES to verify they were the same.
Using a tool I created for working with Angler EK to calculate the XOR 32 bit values we can verify what the results are. Using Calc.exe on a 64 bit system gives a different result.
So here is the list of RC4 replacements.
Here is the AES replacements.
Well that it for this one.
There is allot more that could be said about this one but tracing the code can be difficult at times. I traced the AES function across 4 class files and multiples functions and variables.
Thank you for reading.