Wednesday, July 27, 2016

Feedly:Understanding Java Code and Malware | Malwarebytes Unpacked. From Locky with love – reading malicious attachments



from Understanding Java Code and Malware | Malwarebytes Unpacked

The common way of malware distribution, used i.e. by Locky ransomware are downloader scripts. They are spread in massive spam campaigns – attached to e-mails. Using simple social engineering tricks attackers try to tempt recipients into running the attached file, that leads to downloading and deploying malicious payloads.

Those scripts are most often obfuscated, using various tricks they try to hide the URL from where they get the payload.

This time we will present some of the latest downloaders used to deliver Locky ransomware and show how to statically decipher their hidden URLs.

Analyzed samples

JS

WSF

scripts

Inside

#1 SHEET0000105526932.js

The script contains lot of redundant variables and obfuscated functions. But the thing that is interesting for us – the URL of the payload to be downloaded – is obfuscated very slightly. We can spot it easily by the pattern “http://” left at the beginning:

unicode_link

No real encryption is involved. It is just a text in Unicode, that can be made readable using simple tools (ie this online Unicode Escaping tool). It turns out to be the following text:

converted

It still have some urlencoded characters. After decoding them and concatenating with remaining parts of the address, we get full URL from where we can fetch the payload for further analysis.

url1

The content turned out to be a PE file (md5=9017a6d7eea1f36145701ab99a14a9aa). It is an offline variant of Locky ransomware (can encrypt without downloading a key from C&C server), adding .zepto extensions to the attacked files.

#2: account_report dc0.wsf

After unpacking the original ZIP we can see the following obfuscated JScript:

script1

It consist of several segments. First one is empty. Second – contains function named bar that is defined as a wrapper for standard function eval (used to execute the given code). Third contains a variable filled with an obfuscated content. Fourth contains a small routine used for decrypting the content stored in that variable. And finally, in the fifth segment, the prepared code is executed.

Using some online tools for testing scripts (i.e. this one), we can run the deobfuscating code and display the result instead of executing it, i.e:

elements

That’s how the second layer gets revealed. This part is also contains obfuscation (see the full script on Github).
Content is unreadable: we can see many small functions with meaningless names. Also, all used strings are split into chunks. Each chunk is stored in a variable with some random name.We can start deobfuscation from searching elements that potentially can lead us to the URL – for example “GET” that is probably used to make a HTTP request:

var HTb = "GET" + "";
var BMy = "open" + "";

It is referenced in the fragment of code that. most probably, is the entry point of the execution

The lines:

            Yr2[BMy](HTb, VVq[Vc6++ % VVq[Ep + (function VSc8() {
                return Nt;
            }())]], false);
            Yr2[Cp + CMj8]();

Look much more meaningfil after simple substitution of the variables by it’s values:

            Yr2["open"]("GET", VVq[Vc6++ % VVq["length"]], false);
            Yr2["send"]();

The context signifies the variable VVq must store an array of URLs to be opened.

That’s how the mentioned variable looks in the obfuscated code:

There are many elements concatenated together, and small inline functions, which role is nothing more but to return a previously defined value.

After substituting those parts, we get:

That turns out to be a list of 3 URLs :

"http://ift.tt/2aa0wXs;,
"http://ift.tt/2axftpI;, 
"http://ift.tt/2aa0rDb;

They are used as alternatives for downloading the executable:

mal2

The fetched payload looks valid, but yet it doesn’t run. We can expect that distributors of the malware used a common technique of requiring a parameter at runtime, to make analysis more difficult. This parameter will be passed by the script. The aim of this trick is that only a victim, who got infected by the downloader can get the payload deployed – and not an analyst who try to run the file as standalone, in controlled environment.

We can go back to analyze the script in order to find out the parameter’s value. Deobfuscated fragment is listed below:

As we can see, the script downloads the file from one of the hardcoded URLs, saves it in the %TEMP% folder (under the name “sioLzkk2X.exe”) and then executes. In the line responsible for running the downloaded file we can see that indeed a parameter is given: “321”.

Knowing this we are able to deploy the file and use it for further analysis. It turns out to be Locky – (md5=19f9a448efdad967894574f85987acb3). Like the previous case, it is an offline variant, producing files with extension .zepto.

Conclusion

This type of downloaders are automatically generated by spam factories (similar to Bombila described here). At first, their content may look unreadable and complicated, but usually it is enough to just find and follow familiar patterns to easily deobfuscate the crucial part of the script and to retrieve the malicious URL.

Appendix

http://ift.tt/2amqitQ – analysis of a malicious DOC

http://ift.tt/2a9zfDN – deobfuscating malicious documents

 

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: http://ift.tt/1R6Y8zL.

Web Analytics