It has been awhile since I have written up anything on this exploit kit since it had moved to the background more and I have not seen as may samples as I used to.
It has gone thru many changes since I have first seen it and started learning how to disassemble it to lean how it works.
What sparked the interest this time is a series of reversing videos released by Vitali Kremez @VK_Intel and 0verfl0w @0verfl0w_ of SentinelOne . You can find the tweet reference here. https://twitter.com/VK_Intel/status/1172345642796011521
This post will focus on the .saz file from the video #3 on Rig EK. @VK_Intel was kind enough to give me a copy of the saz file so I could do this write-up of an alternate method of extracting the exploit code. The method used in the video was using the debugger in Google Chrome. I personally dislike that debugger so use a copy of IE9 in a VM when I actually need to run html/Script in a debugger.
So lets first take a look at the file in Fiddler.
There is limited traffic here to work with. We start with a redirect to the Rig EK landing page which we can see on the right. Lets extract this page. I generally dump everything as raw to a folder and then look thru it for what I want but Vitali demonstrates another way in the video that is more precise to only extract what you want/ need.
So here is what the landing page looks like. If you zoom in and out it appears as if everything is running together and difficult to understand.
Here it is after doing some JS Pretty / Formatting.
Now that this is formatted, you should be able to zoom in on the picture and see that there are 4 script blocks on this page each has it’s own code and exploit it is targeting to attempt to download an encoded file to decode and run on the system. The downloaded file / malware will very on the campaign.
So lets take a closer look at each section to see what they look like.
If you look close you can tell this is base64 encoded.
In past version of this there was string replacements in the base64 string itself but now they seem to just put it in the string of letters for the base64 alphabet in the decoder for what ever reason.
So all we are going to do is extract the base64 string from this section and use a different tool to do the decoding.
This section has no tricks so we can just copy paste the base 64string into the decoder and decode as UTF-8
Here is what the whole thing looks like normally after base64 decoding.
Um , we can do better so lets format it. Unfortunately the formatted version takes forever to save a screenshot of so lets just look at the most interesting parts of this one and I will Include the decoded files and my tools on my Github.
In previous samples I have pulled apart over the years I have taken the many hours it takes to decode these by hand to see what the functions do and how they work.
This code also looks allot like what you would have seen in Angler EK.
In this part we see the Shellcode.
Lets copy this shellcode over to another page and then we can look at it in a hex editor.
Notice the first part of this shellcode here.
Now Lets drop this into CyberChef X86 disassembler Here
We can see here that there is an “Xor” by 0x84 being used. So lets try that.
Above you can see I just decoded the entire encoded shellcode by 0x84 and where it is highlighted you can see the decoded script. So lets extract and format it for a closer look.
Does this Look Familiar to anyone ?
Basically all of this trouble to hide what is going on is boiled down to “It just passes parameters and downloads an encoded file , decodes and runs some malware”.
But what are those parameters. In some older versions it was was hidden inside the insane encoding but now it is as simple as looking at the bottom of the page.
This is the url that gets passed and the RC4 decoding key that is used with the exploit downloader.
Now lets take a look at section-2.
As we can see here this section is shorter than the first but there is one thing they do here that they didn’t do in the last section. They split the base64 string by using double quotes and the plus symbol. So lets clean this up and base64 decode it to see what is happening.
Here we can see this one is using Flash to download the sample. There have been several different exploits used with flash in order to run the final payload. So lets take a closer look at this one.
This has several script in this that do various things but what catches my interest is this familiar looking shellcode that I have not seen previously in a Rig EK flash file.
Notice anything here ? It looks pretty much like the first one.
So in this case instead of a flash exploit they are using this one ? I’m not sure but the people that can ID exploits used will have to determine that.
So this section will pass what parameters ?
If we look at the traffic, the only thing we have is the traffic associated with the flash download.
In this case the first part of this will be where it will call out to download the flash file from.
The second part after the highlighted function name is where it will download the encoded file/malware from and the last part is the key that will be used to decode the downloaded file.
There are 2 more section that will decode pretty much as the first and I will include them in there own sub folder at each stage of the decoding.
But this is as far as we can go with this sample.
Since this does not have the frame with the encoded malware lets try another sample from “malware-traffic-analysis.net” located Here.
So if we open the pcap and set a filter of “http.request or http.response” we see the familiar patter as the last in the .saz file.
But in this case we have an extra download after the flash file download.
So lets set a filter for the landing page and see what frame/packet number it is in and extract it.
As it turns out it is packet-112.
Lets take a quick look at the flash file since we can see that it gets downloaded.
As we can see here that the flash in this one is more “old style” and it will do some decoding inside of the flash code.
One thing to note is that if you attempt to just use the “Export all parts” then it does not properly export with this version of FFDec and you have to painstakingly copy paste each of the scripts to a folder.
Notice the auto generated message vs the generated code in the decompiler.
As we extract and look at each script this may be using multiple exploits ?
Going thru this source I’m not seeing how this would even trigger the download based on past work with these. Perhaps I’m just forgetting something or missed what I was looking for?
So the final question is, how do we know which of these sections/scripts downloads the encoded binary ?
The answer is in frame 196.
It tells us the download is the result of the request in frame 132.
Now after extracting all of the request from the sections we can compare which ones match and that will tell us what exploit was used.
In this case it was section 4. and here is the script.
Frame 196 contains the encoded binary and after RC4 decoding we discover that the data in this PCAP was truncated and we didn’t get the full binary.
One other thing to note is the RC4 routine here uses “And 255”
where others may use “MOD 255”.
In conclusion we see that they are using a scatter approach using multiple exploits and scripts on the landing page. Perhaps just one was meant to work while the others are experiments or possibly they are used as fill to waste time of researchers or to send “false flags” on what exploit was used ? Looking at some of the code you can see it “does not work as expected” so only they can answer that question for sure.
That is it for this one I hope I was able to show a viable other way to see what is happening rather than trying to step thru in a debugger.
Link to Twitter post for the Tutorial that started this HERE.
Link to Malware Traffic page HERE
Link to my Tools used here and the files on Github HERE