Published on July 10, 2016

The Evolution: from Locky Ransomware to Zepto

Locky is one of the most widely distributed and infamous threats in the ransomware landscape. First detected in February 2016 Locky has spread very quickly, proving to be both sneaky and effective. The usual dispatch chain took advantage of massive spam campaigns, leveraging freshly compromised domains to enhance its chances of passing under the radar of the various security solutions. With some surprise from the whole infosec community, the people behind Locky went dark in June only to resume their operations after 3 weeks. Our hypothesis was that of a potential connection with the arrest of 50 russian hackers made by the FSB or with the outage of the Necurs botnet, used as a dispatch network. Maybe a coincidence, maybe not, in any case during this “break” we detected only residual activity in the distribution of Locky.

When the operations were resumed, they did it in style: the first campaign we detected took advantage of 50 compromised domains, a trend that has been going on for weeks. This consistency is a sign that the people behind Locky have a clear plan and very good execution skills. What’s remarkable is that day by day the various payloads went almost completely undetected, not an easy feat for one of the most widely distributed pieces of ransomware. Locky continued to evolve after the break, adding at least one new client to their distribution operations and later on changing its extension from .locky to .zepto.
Has something changed before and after the break? Was the break due to the arrests or because of an overhaul of their code base? Did the Necurs botnet outage affect the distribution chain for the whole time? To try and answer these questions we decided to dig into the data acquired by our sensors, highlighting the differences and the evolutions of this ransomware from February until today.
Nowadays, for sure, Locky is one of the most infamous active ransomware spreaded in the wild. Locky, first seen on the half of February, encrypts your files with strong cryptographic algorithm (RSA-2048+AES-128) and asks for a ransom of ~0.5 bitcoin. Like for the major of the ransomware, it’s dispatched by massive spam mail campaigns with a zip archive in the attachment which contains the javascript downloader. More or less after a stops of 2 weeks, Locky is back to populate our inbox emails always through massive spam mail campaigns with a lot of compromised sites. In these months Locky is evolved and one of the most important and recent changes is the .zepto extension added to the encrypted file instead of the old one .locky (from which the named). Is this the new Locky? Are there differences in Locky’s dispatching chain between pre and post break in the end of May? In this blog post we have tried to answer to this questions, analyzing compromised sites, the javascript downloader evolutions and taking a look to the difference on modus operandi spotted from various actors for the different affiliation id.

Booby-trapped Emails

Locky’s dispatching strategy can be summarised in 3 steps:

  1. Compromise a legitimate webserver to host Locky’s dropper
  2. Generate a javascript payload to attach to the rigged and an email body from a template
  3. Take advantage of the Necurs botnet to dispatch the spam messages

No particular differences in the email’s bodies ca be spotted, as shown below:
Email sample 1

Dear [NAME],
Attached please find the documents you requested..
King regards
Kaitlin Walton
Financial Director – Multinational Group

Mon, 27 Jun 2016 20:16:52 -0200

Email sample 2

Hi [NAME],
Ive attached the report you asked me to send.
Dee Christensen

Director, Digital Communications

As well for the subjects. The last ones we have observed are:

FW:my photo
FW:my photos
FW:photo you asked
Final version of the report
RE:my photo
RE:my photos
RE:photo you asked
my photo
my photos
photo you asked


Attachment evolution

Locky ransomware is sold on the black market as a RaaS (Ransomware-as-a-Service), a model similar to that of the various app stores: the distribution platform gets a cut for every application that is sold. In case of Locky the affiliates will take care of the distribution, the authors will manage the backend infrastructure and they will get a cut when an affiliate’s victim pays the ransom. This structure removes a lot of friction since affiliates have to care only about the distribution strategy.
Each affiliate is identified by a number, so by tracking the different affiliates we can study how they operate. We didn’t notice any particular evolution or difference for any affiliate other than the number 1, which is thought to belong to the original authors. In this case we have observed a gradual evolution in the obfuscation techniques in order to reach a lower detection level against the various Antivirus engines as well as the loader capabilities.
It’s well known that Locky is sold in the black market like RaaS so there are different actors behind Locky itself (identified by affid parameter, which stands for affiliation ID). No differences were spotted about affiliation ID different to 1. About the affid=1 instead we have observed evolution on obfuscation technique to avoid detection and about loader capabilities.
One of the first javascript code found which leads to Locky ransomware was the one reported on this gist. It was a basic obfuscated javascript with a few commands just to download and execute the dropper. The evolution on the javascript lands to the one we spotted at the end of May.
After the end of May until the 20 June, Locky actors have stopped its spam mail campaigns. Anyway it’s curious that this was happened when in Russia there have been arrested, as reported in this Reuters’s article. By the way, the only difference which we have spotted in the Locky’s come back is the different parameter passed to the Locky dropper: from “123” to “321”, very little imagination after all.
Another interesting attachment changes is the one spotted in the wild in the first half of May when it was an HTA file. One sample can be found here.

Compromised domains

Each javascript downloads Locky’s dropper from compromised domains. The javascript is capable to contact one to three compromised domains, based on the spam mail campaign.
Thanks also to the Malware Corpus Tracker maintained by @h3x2b we have analyzed ~550 compromised domains. We have split the analysis in this manner:

  • compromised domains from March until ~30 May, which we have called Pre-Break
  • compromised domain from ~20 June until nowadays, which we have called Post-Break




One of the things which lead us to think that the actors behind Locky ransomware are the same is that we have noted that 36 compromised domains, used in the last campaigns, are the same used in the previous ones. Also, except for the argument changed, the javascript loader, the DGA algorithms (minor changes there) and the payload itself are basically the same ones of the last campaign tracked on May.

Affiliation ID differences

Tracking locky recent campaigns, we have observed differences from affiliation ID 1 and affiliation ID 3. These differences can be subdivided like so:

  • Javascript code;
  • Number and URL format of the compromised domain contacted;
  • Unpacking stage.

The javascript is completely different. The affiliation ID 1 has a javascript code obfuscated (2 obfuscation layers) like the one in this gist, on which an eval at end executes the obfuscated code at the top of it (if you want to know more about this topic, you can read our research here). The affiliation ID 3 instead spreads, through email attachment too, a javascript code like the one reported in this gist. For this last one there is only one obfuscation layer.
For affiliation ID 1 the javascript can contact 3 different compromised domains: when the first is unreachable, it will try with the second, and at least with the third one. When we consider the javascript spread by affiliation ID 3 campaign instead, we have noted that the javascript can contact only one compromised domain. Also differences in the URL format can be seen:

Affiliation ID 1
Affiliation ID 3


URLs inside the javascript – affiliation ID 1

URL inside the javascript – affiliation ID 3

About the unpacking stage, for affiliation ID 1, the unpacked code is obtained after VirtualAlloc and RtlDecompressBuffer API calls, then it jumps inside the allocated virtual memory to execute it. When the javascript for the affiliation ID 3 downloads and executes the dropper, this one performs unpacking stage through process hollowing of itself. Anyway the payload is the same of course. When it jumps inside the payload one of the first things that Locky does is decoding a data block to obtain the affid parameter (highlighted in red in the pictures below), C&C’s URI and addresses.

Data block decoded – affiliation ID 1

Data block decoded – affiliation ID 3

From Locky to Zepto

One of the recent biggest changes on Locky ransomware is the .zepto appended at the end of encrypted file, instead of the .locky old one.

Different extension – from .locky to .zepto

Changes also for the targeted extensions (182) can be observed: 31 file extensions added and 9 removed. Below the list:

.001 .002 .003 .004 .005 .006 .007 .008 .009 .010 .011 .apk .asset .bik .bsa .d3dbsp .das .forge .iwi .lbf .litemod .litesql .ltx .m4a .n64 .onetoc2 .pst .re4 .sav .upk .wallet


.7z .cs .db .gz .js .pl .rb .sh .vb

No other big differences spotted.