PrincessLocker - ransomware with not so royal encryption

PrincessLocker – ransomware with not so royal encryption

PrincessLocker ransomware has appeared some time ago and has drawn out attention by using the same template of the site for a victim as Cerber did. It is not a widespread ransomware, so it has taken some time before we got our hands on a sample. In this article, we dig deeper and try to answer questions about its internal similarities with Cerber (and other known ransomware).

Described version of the PrincessLocker ransomware is found decryptable. You can read details about file recovery here.

Analyzed sample

Behavioral analysis

Once executed, Princess Ransomware runs silently. It does not delete the original copy, but just encrypts all the data in the background. After finishing the encryption, it pops up a default browser and displays the ransom note. It drops notes in three file formats: HTML, URL shortcut, and TXT.

Notes have a name following the pattern: !_HOW_TO_RESTORE_.

ransom_note

The ransom notes guide the victim into the Tor-based page, which is intended to give more instructions about the payment and data recovery:

vicim_page

Names of the encrypted files are not changed – only new extensions are added at the end, which are randomly generated on each run.

files

Every file is encrypted with the same key, which means the same plaintext produces the same ciphertext. The file’s content has high entropy and no patterns are visible, which suggest a strong encryption algorithm, probably AES with chained blocks. See an example below:

square.bmp : left – original, right encrypted with Princess

enc_square1

“>

Network communication

During the encryption process, the application communicates with its C&C, that is hosted on a Tor-based site:

conn

Connections list:

connections

First, the malware queries the legitimate address, myexternalip.com/raw, in order to fetch the victim’s external IP. After that, requests are sent to the Onion-based C&C. It sends sets of Base64-encrypted data.

Example 1:

In the request to n.php, the ransomware posts a set of encrypted and Base64-encoded data:

n_php
QQ8EZkZ_dnFldWFKCVxyWFppe2QCcFFyd15XSxRSDHxcHHNdRVtFWEBGQhRHDAMHBgsHCQABAAoVQw8GWgJXRQUDBgULF1sOBQQdAAMBHwcdCQMVXg8FHwMdBgQDABRFDEcDWlBeAEdWBkFBXRRADAEHCQQVXQ8CAQYGF1cOSUBdUgoVRA9ndGFnfHNweXt9dB9HVEFHVEA= 

Decoded to:

decoded_n

Example 2:

In the request to f.php, the ransomware periodically posts smaller chunks of Base64-encoded data:

f_php

After decoding the data, we can see that it contains two values: One is the victim ID and the second is the number of files encrypted at that time.

Content from the above example:

dj11MGtibTF1ZTdzcmwmZj0xMTQw 

Decoded to:

v=u0kbm1ue7srl&f=1140 

Inside

Like most malware, Princess comes wrapped in the encrypted layer—a tactic that protects the malicious core from the detection. The dropper loads the core module into its own memory (self-injection):

self_injection

The core module is a DLL with two exported functions:

princess_dll

The export table reminds us of another ransomware: the Maktub locker:

maktub

This suggests that the threat actors behind both of them are somehow connected or used the same template to build their product.

The unpacked DLL is not independent. It needs to be loaded via a dropper, because it calls a function from the dropper module during execution:

called_outer_module

By this way, authors of this ransomware wanted to make analysis tougher.

Attacked targets

This ransomware attacks following drive types: 2 -removable,  3 – fixed, 4 -remote:

drive_types

Encryption

The key is generated only once before the encrypting loop is deployed. First, a random Unicode string is generated. Then, it is hashed using SHA256 algorithm:

crypt_hash_data

Below is a sample set of random data that was generated during one of the test sessions:

key: SHA256(L"3igcZhRdWq96m3GUmTAiv9") ID: wjn6kdbblpiu  extension: zzqeb 

The result of the hashing function is used to derive an AES 128 key:

derive_key_ida

The derived key is used to encrypt content of each file in 128-byte long chunks:

128_chunk

Chunks are encrypted using the function CryptEncrypt from Microsoft Crypto API that is loaded dynamically during execution:

where_encrypts

Conclusion

Comparative analysis of the code with Cerber has proven that although both families share the same template for the Onion page, they do not have any significant internal similarities. PrincessLocker is way simpler, the mistake committed in the implementation allowed us to write a decryptor. It suggests that the authors of this malware are not as experienced.

It is possible that this ransomware has been built using some fragments of other ransomware that authors got access to rather than being a work of the same authors as Cerber or Maktub.

In order to not give any hints to the threat actors behind the PrincessLocker, we decided to not disclose some parts of the analysis, which could suggest how to fix the discovered bug.

Appendix

http://www.bleepingcomputer.com/news/security/introducing-her-royal-highness-the-princess-locker-ransomware/ – Bleeping Computer about Princess Ransomware


This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.

ABOUT THE AUTHOR