NEWS FROM THE LAB - 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)