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 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:, you will directly see the screenshot (after solving a CAPTCHA). Once you start playing around with screenshots, you will notice the following patterns:


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.

Working backwards to the seeds! (OUTDATED)

This article is technically accurate and it can be applied to rudimentary RSA implementations that only use time retrieval functions as seed as demonstrated by CS Students from Virginia University
However, CryptoDefense uses CrytoAPI which uses a robust PRNG based on process ID, thread ID,  system clock, system time, system counter, memory status, free disk clusters, etc. I dramatically changed the keys recovery approach as soon as I found out the keys were stored on disk. Why keep this article then? Oh, we wanted the crooks to think we were down the wrong path ;)

Do NOT use somebody else's decryption program!
The reason why each key is unique and why you can't use somebody else's decryption program is because this ransomware randomly generates the keys for each victim. If there was a unique private key for everyone, there would be no need to panic!

But the is a problem...

Software alone is technically incapable of generating random numbers in its truest sense. This exp…

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)

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 soon!