Most Recent News from the Lab

Friday, August 22, 2014

Ransomware Race (part 5): SynoLocker's unkept promises Posted by Artturi @ 12:44 GMT

We believe you should never pay a ransom to online criminals. The reason is quite simple. File-encrypting ransomware holds the victim's personal files "at ransom" until a payment is made. For the scheme to work, the victim has to believe that paying up will help. However, the only certain outcome from paying criminals is to encourage them to continue their malicious activities: paying the ransom might not actually get you your files back. Case in point, a recent ransomware family commonly known as SynoLocker.

SynoLocker targets network attached storage devices manufactured by Synology. Once a device has been infected with SynoLocker, the malware will proceed to encrypt files stored on the device. It will also present the victim with a ransom message demanding payment in return for decryption of the files. Here, however, the criminals behind SynoLocker make a false promise. In many of the cases we have observed, the decryption process didn't actually work or the decryption key provided by the criminals was incorrect.

Even after being double-crossed by the criminals, all hope is not lost. If a victim is able to obtain the correct decryption key, the files can still be restored. For this purpose, we are today releasing a small tool, a Python script, written by us. This tool can be used to safely decrypt SynoLocker-encrypted files as long as the correct decryption key can be provided. The tool does not in any way break the encryption of files created by SynoLocker and it does not attempt to bruteforce the decryption key. It will only work, if the decryption key is already known.

Screenshot of encrypted and decrypted file headers
On the left, the beginning of a file encrypted by SynoLocker and, on the right, the beginning of the same file decrypted.

Another use case for our decryption tool is a situation where a user has paid the ransom but can't use the decryption key as they have removed the SynoLocker malware from the infected device. Instead of reinfecting your device with the malware (which is a bad idea), you can use the key together with our script to decrypt your files.

By releasing this tool to the community at large, we hope that we can contribute to undoing the harm caused by these criminals.

We never recommend anyone to pay a ransom.

Our decryption tool, as well as installation and usage instructions, can be found here.

Post by Artturi (@lehtior2)


Wednesday, August 20, 2014

Data vs. Metadata Posted by Sean @ 13:10 GMT

Google uses HTTPS for all search queries. That's good, because it means that all of the questions you ask (a.k.a. your data) will be encrypted. However… regardless of HTTPS, inferences about your searches can still be made by somebody with access to your network traffic. For example:

Network Traffic Analysis, Google to AA

In the screenshot above, a popular "packet analyzer" displays DNS queries (a.k.a. metadata). We first connected our test device to and performed a search — and then we clicked on the top search result link — and connected to

The deductive reasoning skills of Sherlock Holmes aren't required to figure out "alcoholics anonymous" was searched for. And even if used HTTPS encryption (it doesn't), using DNS metadata, we can still infer the contents of the search data. The connections made offer all the evidence needed.

And that's why metadata matters.


Friday, August 15, 2014

Ransomware Race (Part 4): Adult Content, Browlock's Staying Power Posted by Patricia @ 14:51 GMT

Lately, our eyes have been caught by the rise of Ransomware families. It is very evident that the bad guys are constantly developing this type of malware family as seen in our previous posts about CryptoWall and CTB-Locker and Synolocker. In addition to these families, we have also been observing a rather simpler type of Ransomware, yet pretty active and very much alive since it was first encountered in 2013 - Browlock.

Compared to other Ransomware families, Browlock does not encrypt the victim's files, and does not add nor run any files on the victim's machine. It only scares the user by “locking” the browser with an alert that claims to be from the police or authorities, stating that the victim has committed a crime by viewing child pornography website or downloading pirated software. It prevents the user from closing the browser, but terminating the browser process using task manager, for example, resolves the problem.

The following are statistics taken from Browlock hits in our telemetry from June onwards.

HitCount2 (51k image)

According to our statistics, the target victims were users visiting adult sites. More than half of them were redirected to Browlock pages after going to adult-related websites. Others were redirected through the use of ad networks. We didn’t notice any adult website that stood out from our data, however, for the ad networks percentage, almost 60% were from alone.

referer (63k image)

Browlock's landing pages have different IPs and URLs from time to time. You may see more observation of this from malekal’s website . The URLs may look random, however it has noticeable patterns. Below are some examples:

 •   http:// alert. policecoin. info/ FI/cls.php
 •   http:// alert. porschepolice. net/ FI/cls.php
 •   http:// alert. xraypolice. com/ FI/cls.php

 •   http:// alert-police. barbrastreisandagent. com/
 •   http:// alert-police. estateagentsolutions. net/

 •   http:// attention.starpolice. biz/FI/cls.php
 •   http:// attention.starpolice. co/FI/cls.php

 •   http:// police. grantscards. com/
 •   http:// police. redunderground. com/

 •   http:// security-scan-nuqbqakx. in/
 •   http:// security-scan-jdytiujg. in/

 •   http:// system-check-abevbrye. in/
 •   http:// system-check-ipxmjdry. in/

 •   http:// security-akechksv-check. in/

 •   http:// security-zxqkcohl-chk. in/

 •   http:// law-enforcement-tqvrlbqb. in/
 •   http:// law-enforcement-icgkjyrr. in/

From the month of June, we have observed the following most reported URLs in our upstream, with its corresponding IPs where it is hosted:

IPtable3 (62k image)

The graph below shows the duration of these URL patterns being actively reported in our upstream. It seems that on average, Browlock was able to keep a single URL pattern of its landing pages for about two weeks to a month long.

ip_graph2 (92k image)

We have also noticed that United States, United Kingdom, and countries in Europe were the most affected.

top5countries (8k image)

We’ve seen this operation going on for quite a while now, wondering if the bad guys are really getting money from this very simple mechanism. We don’t really know for sure how many victims have given in into paying a ransom from its fake alert message. But what we know for sure, is that while we see this ransomware families being active, we will keep our eyes open to keep protecting our customers from this threat.


Thursday, August 14, 2014

Testing the Xiaomi RedMi 1S - now with OTA update Posted by FSLabs @ 05:42 GMT

On August 10 Xiaomi addressed privacy concerns related to the MIUI Cloud Messaging function of its smartphones by releasing an OTA update intended to make this an opt-in feature, rather then a default one.

Since we already had the phone set up, we downloaded and applied the update to the same Redmi 1S phone we used in the previous testing:

xiaomi_otaupdate (48k image) xiaomi_phone (124k image)

Then we factory reset it. Once the phone restarted, we noted that cloud messaging is now by default set to Off under Settings:

xiaomi_phone_settings (42k image)

We then went through the following steps:

   • Add a new contact
   • Send and receive an SMS message
   • Make and receive a phone call

During these activities, we did not see any data being sent out from the phone.

Next, we activated the cloud messaging function and logged into the Mi Cloud. At this point, we saw base-64 encoded traffic being sent to

for_xm_cropped (181k image)

Note that this is now over HTTPS rather than HTTP, as seen in our previous testing. We had to use a HTTPS proxy in order to view what was being passed:

traffic_cropped (33k image)

This was a quick test to check if the update had addressed points highlighted in various media reports. Xiaomi VP Hugo Barra has also posted more details of the MIUI Cloud Messaging implementation.


Wednesday, August 13, 2014

Ransomware Race (Part 3): SynoLocker Under The Hood Posted by Artturi @ 13:17 GMT

Last week we wrote about a new ransomware family called SynoLocker that was targeting network attached storage devices manufactured by Synology. Initial rumours suggested SynoLocker might be related to the infamous CryptoLocker, so we decided to dig deeper.

On the surface, SynoLocker and CryptoLocker share many similarities, not the least of which are a similar name, similar choice of encryption algorithms and the idea of extorting money from victims. Under the surface however, the similarities quickly end. When first infected with SynoLocker, a unique RSA key pair is generated for the victim. The private key never leaves the malware operator(s) but the public key is stored onto the victim device. This public key can be used to encrypt data in such a way that it can only be decrypted with the associated private key. As long as the malware operator(s) are in control of the private key, they can deny the victim access to their encrypted files.

For encrypting the actual contents of the victims files, SynoLocker uses AES. First an initialization vector (IV) is generated from the size and name of the file to be encrypted. This IV is later used by the encryption algorithm, but it is also used, combined with a randomly generated string, to generate the actual encryption key. Next, the contents of the original file are encrypted. Simultaneously, a so-called keyed-hash message authentication code (HMAC), commonly used to verify the integrity of data, is also generated from the unencrypted data. Finally, the random string used to generate the key is encrypted using the RSA public key. This ensures, that the only way to regenerate the key for decrypting the data, is by first decrypting the random string using the RSA private key.

Diagram of the encryption process and resulting file
Diagram of the encryption process and resulting file

Once finished with the encryption of a file, SynoLocker will replace to original with a new one. To the new file, SynoLocker first writes the RSA-encrypted random string. Next, it writes a marker string "THE_REAL_PWNED_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_1337" (for those counting, there are 40 Xs) which it uses to identify files it has encrypted. After the marker, the IV used in the encryption process is written. Next, the encrypted version of the original file contents is written to the new file. Finally, the HMAC generated during the encryption process is written to the end of the new file. All this is done by SynoLocker in such a way, that were anything to fail or go wrong at any point during the process, the original data would not be lost. Only once everything is done, will SynoLocker replace the original file with the new one. Finally, it will also attempt to overwrite the original file with random data to make recovery more difficult.

File encrypted by SynoLocker, as viewed in a hex editor
A file encrypted by SynoLocker, as viewed in a hex editor (Arrows pointing to beginning of marker string)

When attempting to decrypt files, the above described process is essentially reversed. First SynoLocker obtains the random character string by decrypting it with the victims RSA private key. Next, the string is used together with the IV obtained from the encrypted file, to generate the actual AES key. Finally, the file data is decrypted using this key. At the same time, SynoLocker generates a new HMAC from the decrypted data. Finally, the HMAC of the original data is compared with the newly generated HMAC and only if they match, is the decryption process deemed successful. Again, this ensures, that if anything goes wrong during the process, existing data is not lost.

In addition to the encryption methods used by SynoLocker, we were also interested in finding out more about the infection vector(s) used. Despite our best efforts, we have so far been unable to identify the exact infection vector used by SynoLocker. It is however clear, that SynoLocker is more a collection of files uploaded to the device through the infection vector, rather than just a single malicious binary. These files all have specific purposes and are often dependent on each other to fully function. A list of SynoLocker related files is available at the end of this post.

While analysing the SynoLocker binaries, we have also continued monitoring other aspects of the operation, and it seems the operator(s) are on the move. Recently, the website where victims are instructed to go to for payment instructions, has been updated. The page now includes the notice "This website is closing soon...". The operator(s) also claim that they are still in possession of over 5500 private keys but that they are willing to sell the entire collection for 200 bitcoins.

Recent screenshot of SynoLocker website
Recent screenshot of SynoLocker website

Whether the operator(s) follow through with their plans and what that might entail for victims will remain to be seen.

List of SynoLocker related files:
/etc/synolock/decrytped.log (spelling mistake in SynoLocker)

Sample hashes:
9ccd05d4afe6bedac7aa6695c78d5475df5f9b0d (server)
c160c1fd18841ebb5e4186ef5ac7ef223b688bc4 (synosync)

We detect these as Trojan:Linux/SynoLocker.A

Post by Artturi (@lehtior2)


Tuesday, August 12, 2014

Timo Discusses Dynamic Analysis of Flash Files Posted by Sean @ 13:24 GMT

Senior Researcher Timo Hirvonen presented at Black Hat USA 2014, and publicly released a tool which enables dynamic analysis of malicious Flash files. He spoke about it with SC Magazine's Adam Greenberg last week:

Video source

Download the tool from GitHub: F-Secure / Sulo


Thursday, August 7, 2014

Testing the Xiaomi RedMi 1S Posted by FSLabs @ 03:42 GMT

Xiaomi phones have made the news off and on in the last few months for their cheap, value for money phones and corporate moves. More recently, there were also reports that these popular devices also silently sent out user details to a remote server. That news came on the heels of other reports of smartphones being pre-installed with suspect apps.

We thought we'd take a quick look into this, so we got our hands on a brand new RedMi 1S:

xiaomi redmi

We started with a "fresh out of the box" test, so no account setup was done or cloud service connection was allowed. Then we went through the following steps:

  •  Inserted SIM card
  •  Connected to WiFi
  •  Allowed the GPS location service
  •  Added a new contact into the phonebook
  •  Send and received an SMS and MMS message
  •  Made and received a phone call

We saw that on startup, the phone sent the telco name to the server It also sent IMEI and phone number to the same server:

xiaomi data

The phone number of the contacts added to the phone book and also from SMS messages received was also forwarded.

Next we connected to and logged into Mi Cloud, the iCloud-like service from Xiaomi. Then we repeated the same test steps as before. This time, the IMSI details were sent to, as well as the IMEI and phone number.

At this point, this was just a quick test to see if the behavior being reported can be confirmed. In response to the reports, Xiaomi itself has released a statement addressing potential privacy concerns (In Chinese on the company's Hong Kong Facebook page, with an English translation linked).

Updated to add:

Hugo Barra, a vice president at Xiaomi, posted this on August 10th: MIUI Cloud Messaging & Privacy.