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/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: