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: