Skip to main content

Cryptodefense: Malware Analysis & Reverse-Engineering

I've been a computer geek for ages and here are my conclusions. I've been gathering as much information as I could during these days, and there are many variants of Ramsomware from apparently different authors. Some of them do not completely encrypt your files, except their first 512 bytes by which it's possible to decrypt with an easy-to-use tool voluntarily made by BleepingComputer programmers [Link]. There's another variant that entirely encrypts your files but, due to a failure in its design, it uses a much weaker 128 bits encryption instead which can be easily broken a standard computer in a matter of hours. [Link]

Then there's the newest, known as CryptoDefense that completely encrypts your files.

If you were unlucky enough to get in contact with the latter and if you want some more technical information about it, here's my analysis. 

1. Encrypted File Samples:



HEXCMP comes visually effective when comparing two binary files. These two encrypted files belong to two different computers that were hit by the exact same malware. As you can see, the first  !.c.r.y.p.t.e.d.!... string is the same in both files, except for the HASH-looking 32 characters string that goes after it. Is it perhaps MD5? If so, what is the purpose of using a HASH in each file? 

Note: It seems that the encrypted file data starts at address (decimal) 86

I first thought it was a checksum used to verify files' integrity after decryption until I found out the hash remains the same in every single encrypted file. The two files in the image belong to different victims but they have the same HASH in every single encrypted file. 

Coincidentally, the crooks' website that allows you to test-decrypt one file is able to tell whether the file you upload belongs to you or not.



Let's make some experimentation!

So, what happens if you upload someone else's file into the server?
Error reads: "You uploaded don't own file"

Interesting... How does their server determine whether it is your file or not? The answer seems to be in the mentioned hash string.

Now, what happens when you upload a random file? (ANY file)


Error reads: "CryptoDefense can not identify the encryption algorithm."
Error reads: "Unknown error"

How about tricking their server?

If we take a look at the crook's video on YouTube, he shows you how his own files are encrypted. This exposes something interesting...
The crook shows you an encrypted .txt file

Now, the first file (from someone else) we uploaded got rejected with "You uploaded don't own file". 

Now let's see what happens if we visit the server with '2g' ID and a corresponding HASH-looking string? Both the ID and the HASH-string are related after all, right? Let's find it out....

Here, we copy the HASH-looking data from the video...


At least I expect to get the webserver to decrypt the file, even if I end up with a corrupted file decrypted with the wrong key. Let's see...

Error reads: "Error while decrypting file"
Aha! that looks interesting. It did accept the file this time, but it seems that it knows whether decryption is right or not. Let's see now what happens if we change just ONE character from the file we recently uploaded:

Yet again the same error. It's official. The HASH string is used by the website to identify victim's ownership.


Now how does it determine whether the decryption is correct or not?

[To be continued, I am working on this. There seems to be -there must be- a checksum or something. To find it out, we need the executable files that decrypt the victim's data... ]


What is the server's (TOR'd) link again? 

It's https://rj2bocejarqnpuhm.onion.to/XXX where X is the ID of the victims. Now, if you start playing around with that ID, you will see the screen of many victims. 


Remember that the crooks uploaded a video in YouTube? 

Then he shows you his VICTIM'S ID: 2g
If you carefully watch it, you will notice that his ID is only 2 characters long (as opposed to other victims which is 3 chars long) which means his own infected machine (a Virtual Machine for sure) is one of the first ones in their database. 

If you add '?getpic' to the link, example:
https://rj2bocejarqnpuhm.onion.to/XXX?getpic, you will directly see the screenshot (after solving a CAPTCHA). Once you start playing around with screenshots, you will notice the following patterns:






Comments

Popular posts from this blog

Wana Decryptor / WanaCrypt0r

Alright, guys. This is a tough one: However, there's no reason to claim it's impossible to decrypt victims data. These idiots always let something slip through their fingers. Their servers might be found and keys restored to their respective victims. Errors might be found in their code, their key encryption scheme may have some weakness, etc. Let's just let the experts find a way out. By the way, if you want to temporarily protect your PC from this malware, you may do this.

Good News (part 2)

Hey guys! After some -lot of- research and reverse-engineering, I decided to create a video which explains how to recover the private keys via a sniffer. Mind you, in some countries (United States and the United Kingdom and some countries in the European Union), ISPs are requested by law to retain data for over a year or so. Therefore, the authorities are able to retrieve the information (metadata) you sent and received anytime, including the day you got infected. It isn't hard for them to do, but that of course implies a long judicial process. Instead of paying the crooks, try to get in touch with the police and point out the existence of this law. I am also working on a program to to brute-force the key based on  parameters found inside the victim's computer  which I won't disclose right now. It appears that although the 2048 bits is certainly strong, they used a weak seeding which is quite simple and a brute-force attack can be performed within an manageable...

CryptoDefense: Keys pair stored on disk!

This little detail slipped through their fingers... TOO LATE! (I actually hid this post when I understood that it might alert the crooks. But SYMANTEC did!) This is the exact path where your keys are: Windows XP C:\Documents and Settings\<USERNAME>\Application Data\Microsoft\Crypto\RSA\S-1-5-2... Windows 7 X:\Users\<USERNAME>\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21... (X stands for your hard-disk letter, which is commonly C in most computers)   HEXCMP highlights in red the differences whereas identical bytes remain white. TCP/IP dumped data is identical to the key found on Disk.  The private key is encrypted via  DPAPI (Data Protection API). There are many RSA keys in that folder though, but you can still find them by sorting these files by date. If you don't remember the date you got infected, see your screenshot at the crook's webpage or search for the oldest HOW_DECRYPT.TXT file in your system. I'll update this blog...