Friday, April 20, 2012

RansomCrypt: an analysis of its crypto routines.

About a week ago, I noticed a new crypto ransomware (remember gpcode?): W32/RansomCrypt. The news came from the F-Secure website. So, as soon as I gathered a sample I started my analysis, but just when I was about to finish it... A twitter update told me that F-Secure had already done the work with the decryption script!Anyway here you can find some additional details about the encryption/decryption and the way it works.The first executable I came across was coded in Visual Basic and was packed with a modified UPX version.After unpacking the sample, I started searching for standard encryption routines, but nothing caught my attention. However the sample did contain encrypted data, and debugging some routines that looked like home made decryption code, I ended up finding a second encrypted executable within the first one.Luckily, this second executable wasn't coded in Visual Basic (if you have tried to reverse some VB executable you know what I mean!), this one was also packed, but with standard UPX. Again, I unpacked it and began searching for some encryption routines. I found three candidates: a 16-bytes xor, and two TEA routines (both encryption and decryption).(If you haven't ever reversed TEA, here's a little trick to recognize it: in most cases you just have to look for the magic constant 0x9E3779B9 and the work is done.)

I also noticed some interesting APIs: FindResource, SizeofResource, LoadResource, LockResource. They made me look into the resources of the file, where I found an encrypted block. Once decrypted, this block revealed the malware configuration.

To decrypt the configuration, I debugged this decryption routine and found out that the first 16 bytes of the resource were the key for the decryption of the configuration block. The decryption algorithm was the 16-bytes xor routine I had noted earlier.

Then I noticed a loop scanning for all the files in the system, and I thought that it was probably the same that also encrypted them.

I set a breakpoint there, and followed the key generation algorithm: the malware uses the same key employed to decrypt the configuration block, but it changes the endianness of every dword.

Finally I noticed that the malware doesn't encrypt the entire file, but it skips the first 0x47 bytes. I believe that this is done because the first bytes of a file usually contain a header (depending on the type of the file), and these headers may contain predictable data that may allow known plaintext attacks.

We have gone through the encryption: they key is generated starting from a static seed, and then TEA is used, so if you have been infected you can generate your decryption keys and get your files back.

You can use the python script from F-Secure, which performs the decryption automatically. However, users should note that they should NOT rename the encrypted files: the encryption key is generated combining the static key with the first character of the filename, so changing the filename of an encrypted file may cause incorrect decryption.

Alternatively, the malware prompts the user for a code that if inserted will cause the malware to decrypt all encrypted files and then remove itself. The code will be sent of course only after a user sends money to the malware author.

Can't we just get this code? Does it really work? I tried forcing the tool to accept any code (I cracked it, if you want to put it that way), and the malware did decrypt the files and remove itself. So having the code may solve the problem immediately.

Unfortunately, the code is checked pretty heavily: the string you insert is hashed five times with MD5 (the hash is performed through Windows Crypto APIs) , and then checked with a hash that is hardcoded in the configuration; something like this: