ZIP’d WSF File Retrieves Locky Ransomware

IOCs:

82.197.131.109 – imex.atspace.com – GET /sxqtddp?VlwYKkCOYvI=axCugUhsM
213.205.40.169 – archiviestoria.it – GET /waotorf?VlwYKkCOYvI=axCugUhsM
69.195.129.70 – tlehsdy.biz – POST /data/info.php

Hashes:
SHA256: 010b6da42c0b377f4b28fbcaa1268f046eeb403a3eb79dfb395fc3c2c0daa85e
File name: xVTvTcaaG1

SHA256: 4baf40fe1c7fafd89befe4f2e2bd36aefc8a4faf395631d8bac20e09e372725b
File name: xVTvTcaaG2

SHA256: 72d9cbdec23f9c4f95ce8fb1217ef67c979957c58b4fb7c8fe98ac8cec62aca7
File name: xVTvTcaaG2.dll

The infection starts with a user getting malspam. This email is coming from a iCloud account and it contains a zipped Windows Script File (.wsf):

A couple months back the threat actors behind this campaign started using zipped Windows Script Files. Windows Script Files allow them to mix multiple languages (JScript, VBScript, etc.) within a single XML formatted file. This file format allowed them to easily repackage their existing JScript code into a .wsf container [1][2].

Once the .wsf is executed the code retrieves Locky from distribution sites.

The .WSF Code:

There is a lot to unpack when looking at the code (which I am dubbing “chikabombomchika” since it sounds funny and because it’s being used everywhere for obfuscation), however, if we look at the code we can see how the HTTP requests are generated.

The following two pictures are unedited. They show the original encoding and obfuscation techniques used by the criminals:

Notice that the string “HROMOSOM” is added to some base64 encoded strings.

After decoding and deobfuscating some of the code we are left with something like this:

All strings proceeding the identifier called “tiiimayooo” will be decoded from base64. All strings matching “HROMOSOM” are removed during decoding.

Here is what the code looks like when it’s partially de-obfuscated and decoded:

The code appends both “http://” and “?VlwYKkCOYvI=axCugUhsM” to complete the full URL.

You can also see var HORDA17 = “xVTvTcaaG”. That string represents the filename downloaded by the host.

Just to double check I looked at the traffic in Wireshark and it matches:


The first distribution site in the array is imex.atspace.com, which returned a 404 but created xVTvTcaaG1 in %TEMP%.

The second domain in the array (www.archiviestoria[.]it) returned the file xVTvTcaaG2 and then appended the file with .dll creating xVTvTcaaG2.dll.

My coworker ended up doing an awesome job fully decoding, deciphering and de-obfuscating the code. He also added some very helpful annotations. Here is a snippet of his work:

Once the .wsf has been executed and the GET requests are generated you will notice the files appearing in the user’s %TEMP%:

After infection I captured POST requests to tlehsdy.biz/data/info.php, which is resolving to 69.195.129.70.

Files are encrypted, renamed and appended with .zepto. Ransom notes then begin to drop and open in the usual locations:

References:
[1] http://www.bleepingcomputer.com/news/security/zepto-ransomware-locky-variant-being-distributed-via-wsf-attachments/
[2] https://blog.cloudmark.com/2016/07/18/locky-actors-shift-to-wsf-attachments/

malwarebreakdown

Just a normal person who spends their free time infecting systems with malware.

One thought on “ZIP’d WSF File Retrieves Locky Ransomware

Leave a Comment

%d bloggers like this: