Old Tricks Die Hard, Malwares No Exception (Part 1)

I haven’t updated this blog with some malware analysis for a little while, nothing interesting has come to my attention really, I do only have a limited field of view too as I am a student and not an AV. I found this peice of malware that I am about to show a little funny, some simple tricks that malware authors use that they just can’t shake off, one of them being the use of UPX. And yes, this did have a digital signature with it.

I don’t exactly know the origins of this file as I got it from a malware sample website, I don’t think this could pass off as an Email client from Microsoft, but that’s just me I guess? 🙂

So I unpack the UPX file and look at the resource section of the executable. I find a value called “KIT” which has what seems to be some other packed or encrypted data. What I find out is this is a DLL file.

I survey what imports this peice of malware has in IDA I then use Immunity to debug the application, looking at the executable in the debugger I can see that CreateProcessA is going to be used. I breakpoint here to see what’s being created and find that a simple command line arguement is being used to launch the same process with just the additional arguement. The arguement is funnily enough called “launch”.

Running through the program a little bit until we get to an interesting part where the register shows the all too common “PE” string right before allocating some memory. I follow to the dump to see what is there and am shown what seems to be a exe or dll. Remember the “KIT” that we saw a few pictures back? Seems like we’ve found the unpacked version here.

I select all from the dump and save to file, I can edit it later with a hex editor (HxD) to take out the parts that aren’t to do with the DLL. The DLL is initially packed with UPX which is obviously again, trivial to unpack. A little look at my trusty Exeinfo confirms it is indeed a DLL we have extracted. As we can see the malware has used UPX quite a lot, this is mostly because it wants the smallest size possible for it’s executable and DLL. I’ve said this before on the blog, UPX can bring detections to an executable and so a user would have to crypt which would probably inflate the file again. Ah, the problems of malware hey? I’d also like to say that the exe name wasn’t the malware authors choice, that was me who named it simply “ok.exe”, I’m imaginative I know.

Another easy trick that the developer has done is implement base64 to make sure some strings are obfuscated somewhat, as we all know, base64 is also quite trivial to decode. Most of the strings were API’s, they also base64’d the dll’s they were to import too. Funnily enough, the server ip to send information to wasn’t encoded or encrypted in any way, which I guess is fine. Most likely so researchers and AV’s can’t see the imports straight away.

A short little loop to decode the base64 strings which is shown here after adventuring into the DLL a little bit.

A little after we have found and decoded all the strings we need to load the decoded DLL’s so we can call the API’s and get down to business. A similar sight for anyone who has looked at malware before.We begin to start putting stuff into buffers seems like we’re going to create a file with some information and contact home soon,  we’re wsprintfa heavily in this section of the code. The host seems to be down, I don’t know how fresh the samples are.

The malware checks if a file called test.1 is available at C:\ which it won’t and then proceeds to search files in the directory it’s currently in, it also goes and attempts to adjust it’s token privileges allowing it to have more control. It will then create a mutex with a M contactenated with the IP address and port it is supposedly going to connect to, a bit different.

It has also been checking for Readme.txt in the directory and eventually creates a randomised folder name as shown here. This is where I’m guessing the malware will choose to reside and check again whether it has a running instance already on the computer.

When I mean random there is nothing random on a computer, essentially it is though. Here I show the function the malware uses to create directories and files. It has an interesting pool of characters to choose from, I’ve simply highlighted a loop for you, the pool is very different from others you may see.

It proceeds to create what seems to be randomised folder names and finally creates the file Readme.txt, it then moves the exe from it’s original location to here. It has changed the folder “vv71” attributes to hidden, like most malware, so it’s harder to find. After it’s moved all the files, it wishes to sleep for 5000ms, this is quite common in malware as AV’s may pick up suspicous activity and begin to monitor it. After this, it launches the process in it’s new location to verify it’s made it, after it can verify all this, it will begin to start using the good ol’ WSA_STARTUP.

We obviously need some information we want to send back home and one of them is the version of the operating system. Interesting to see how low this malware had on it’s list such as NT and 2000.

The malware creates threads and sets the timeout as infinite which is annoying, there is no response as the ip is dead so it is a bit of a job modifying all the values allowing me to carry on analysing this. But almost all of the techniques used in this malware are very simplistic, although written in C++, this may be the developers first or one of the first peices of malware written.

In the threads there is one function which is seperate to the base64 function we looked at previously, it ends up being a common registry value for the startup. From what I can see, this particular strand of malware only creates one startup registry key.

A really interesting part of  this malware is that it may of originally of exploited predominantly Japan, it ends up attempting to redirect a few .jp domains to a different IP. Although it’s placed in a different file from the original etc/drives/host file, so cannot confirm, it seems this is what the intended behaviour is though.

That’s all I have time for now, interesting to see the differences in malware and techniques, but in this particular strand, it seems like the old tricks die hard. Very generic.