On August 4th 2020 JAMESWT @JAMESWT_MHT posted on Twitter here about malware spam hitting Italy using ursa loader.
I mainly look at the obfuscation and this vbscipt looked rather interesting. Little did I know what I was in for.
So I start by downloading the vbscript bypassing the extraction from the msi file and find this.
Let’s format this a little to be easier to read.
I also renamed some parameters to make it easier to follow since the names were to similar.
We have 3 values that get calculated and used in the decoding function. It will also take the first letter and subtract the value of val-1 from it to use later in the calculations.
After a bit of trial and error I was able to work out how these strings decoded.
After formatting the output and removing the extra “:” which I believe are being used as a new line split point we see this.
Next we need to locate a sample where we can continue to follow along with so we can search ANY.RUN @anyrun_app for a sample.
Mikhail Kasimov @500mk500 post a link to here on anyrun where you can see the request of q=1 .
Then you get a response of another large encoded string.
Once decoded you get this.
For those eagle eyes you will notice the encoded string is different for both of those screenshots but the output decoding is almost exactly the same.
You may notice the encoded section at the bottom of the screenshot labeled “wCnfg”.
After decoding it we see this.
If we format it a little better we can see the same names get repeated several times.
One other thing we will se as we scroll down the script is it will use WMI to get various bits of system information and use that to test if it is running in vm of some sort.
At this point I stopped looking into it. I got the script decoded and passed on the information.
On August 7th 2020 JAMESWT @JAMESWT_MHT posted again here that it was again hitting Italy .
Then I started digging in deeper to try and understand it better. The trip down the rabbit hole was about to get rough. We have to find a sample and start from the beginning.
NOTE: There are a few sample runs the have a very explicit NSFW picture which will be in the “no threats detected” ones because it mainly just returns the picture.
So we have to start with a sample that has the MSI that gets downloaded here .
After downloading and extracting the sections using 7Zip we see the original vbscript that get run that we have seen.
Next we have to try and find something that picks up where the first one left off. I chose this one here.
To get an idea of what order things get done in we need to download the pcap and follow along in order.
If we just do a filter of “http.request or http.response” we still have a lot of background noise. So let’s build a new filter just for this.
(http.request or http.response) and ip.addr == 104.44.143.28
Now we can see which urls are getting called from the first large script.
In packet 34 we see the request and in packet 38 we see the response with a short encoded string.
Here are my decoding notes. We have the encoded , decoded. and some notes about the use.
Our next request is packet 504 for a file named “lp1a1.bd2” and the response is in packet 7016 . looking at it we have a PK/ Zip file being downloaded.
Once we decompress this we see this.
The file appears to be encoded in some way. Back to the main script.
After doing some string replacements and following the trail of the url that was called we end up with this decoding function.
So after careful study of the function I built a Windows application with 2 textboxes.
After fixing a off by 1 bug. (I was adding 255 instead of 256) I finally get something besides an error or garbage.
If you look close at the output you can see the first 2 bytes decoded to 0x4D5A (MZ).
The size of the encoded file is 0x6A6801 (6,973,441) bytes, a very large File. Do to the size it can take over 15 minuets to decode a file because of all of the string manipulation that need to be done. So I wrote a new one the will take a file as input and write the decoded file to the same folder. This one works almost instant.
It looks like this extracted file is a Delphi C++ with 2 exe embedded in the resources.
I’m not sure what it does.
Sha1 : 06D2E4EC20053ABDBE76E94F71966235BB9FAA56
Sha 256 : 58EA17C1572275B930A56FE1EBBF4156B84932C7F89E883994B941A6B6F7DD44
MD5 : 77ACA543DBD3D3C32A2A335975A5FB1E
Our next request is in packet 7271 and the response in packet 7273.
Another short encoded string.
Our next request is at packet 10045 for /lp1asq.bd2 and the response is in packet 12594.
This one is encoded also. After decoding we get this.
Another PK / Zip file. And after unzipping it we get.
It appears it is an open SSL Library.
Our next request is in packet 15083 for /lp1asl.bd2 and the response is in packet 15945
Another encoded file.
Decoded is another PK / Zip file.
Looks like another open ssl library.
Our next request is in packet 16013 for /lp1ass.bd2 and the response is in packet 16270.
Another Encoded file.
Another PK / Zip file after decoding.
And yet another Open SSL library.
Our last request we have is in packet 16402 for /lp1aai.bd2 and the response is in packet 16996.
Another Encoded file.
Another Compressed file.
Now this last one the the pcap is real interesting. As you can see it is an AutoIt executable for running AutoIt scripts and Compiled binary’s.
This pcap seemed to be the one with the most packets. I can only assume the reason there are not more is because the sandbox ran out of time to process everything.
Although we have extracted everything we can from the pcap we still have not went back to map the request/ response to the Script that called them. I’ll leave that for a later exercise.
And for those interested here is the list of unique UA string found in this pcap.
UA = Index Location: 0xE31
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko UA End
UA = Index Location: 0xC7DD
Microsoft-CryptoAPI/6.1 UA End
UA = Index Location: 0x4D4EA7
Mozilla/5.0 (Windows NT 6.1; rv:68.0) Gecko/20100101 Firefox/68.0 UA End
Now that that is done let’s crawl out of this rabbit hole and look into another.
On August 7th 2020 lc4m @luc4m had created their own decoder for the scripts and had extracted the urls in the vb script.
A search of “hxxp://104.44.143.]28/m/” resulted in finding an open directory. See the twitter thread here and another part of it here (that will giveaway what I find)
They were kind enough to send me a copy.
Upon looking at 1 of the many files in the directory we look at one of them and see this.
This appears to be encoded in some way. So on a guess I tried the tool to decode these like I did from the packets with the same extension.
And it did indeed decode to a PK / Zip file.
At first I thought that this might be encrypted in some other way and posted a screenshot on Twitter and marc ochsenmeier @ochsenmeier suggested here it looked like a Autouit file. I didn’t even notice a AU3 on the second line.
I then tried the AutoIt decompilers I had and they would not work. So back to Google search for a few hours.
I finally stumbled on to this post that listed the AutoIt header bytes Locate Here by doing a search for the first bytes of the file.
It turns out this file is of type A3X binary format. it is a stand alone compiled file that can be run with AutoIt3.exe binary. We seen it downloaded last in the section above.
So the next Question is how do we decompile this. After more time searching I find this project called “myaut_contrib” located here on github.
After downloading and extracting this to my vm and then installing it for a right click menu (which only works with an exe file extension). I open up the myAutToExe.exe and drag-n-droped the .A3X file into it and click on the scan file at the top and then ran it in auto mode.
Here is the output.
We can see several files it dropped but most importantly it dropped a .au3 decompiled Script file.
After Cleaning hex string and dropping it into a hex editor we can now save the file.
Here is what we end up with. There was no detection on VT for this since it gets loaded to memory so I uploaded a copy here . For those that don’t have VTI access I also uploaded it to Malshare here .
That is about as far as we can go with this rabbit hole without digging into the file itself.
Let’s climb out of this one and find another one.
Googling for this loader I’m not finding a lot of information about it.
Going back to anyrun we do a search using the tag ‘ursa” and we find there are 3 pages of files to look at.
my interest here is to see how far it goes back and see what differences there are in the older version and the new version.
So we go to the last page and scroll to the bottom and see that it was run on August 31st of 2018. So this have been around at least that long. So we will go to that here and see what we have.
This one appears to start out with an executable so let’s download this and take a closer look.
We can see here this is a dot net program. So we can decompile it. I did, and dumped it as a project to be able to do better searches for information.
If we look at form1 we see encoded strings like in the first part from the vbscript files. Decoding this we see that the vbscript was encoded and put into the dot net binary to be run from there. Strange but ok, it works.
So we next need to go to the pcap and see what comes next.
Like the first one we will set a filter of
“(http.request or http.response) and ip.addr ==104.245.88.63” to narrow down on just the information we want.
As we can see there is not a whole lot going on in this one.
Let’s start with the first packet at 90 which is a post.
In the first example it posted q = 1 and here it is c = 55 . Is this a possible campaign ID ?
So we get the response in packet 151 and get this large encoded blob.
After decoding this we see something similar to what we have already decoded in the first part but all of the string data here was encoded also.
If we continue on to packet 157 we see a request for /njy4rs33/ny3a.php but there was no response so we move to the next request in packet 160 for /njy4rs33/m/ny337.aj6 .
Notice here the file extension is different that the more recent first one we looked at.
In this case it is a PK / Zip file.
Once we unzip it we have a executable.
I’m going to stop at this point due to the length already.
Some more observations I made was the file extension does not mean it is encoded or compressed.
Going thru various samples and decoding them from the pcaps I was able to get, it may be a executable also with the same file extension.
So don’t trust a file extension.
That’s it for this one.
I hope you learned as much as I have.
Article Link: https://pcsxcetrasupport3.wordpress.com/2020/08/10/ursa-loader-and-the-many-rabbit-holes/