Wednesday, April 22, 2015

Hit by Coinvault?

Kaspersky Labs devised a tool to recover files without charge. Click here.

It's good to know that for every gang of cybercriminals out there, there's good people willing to help you out.


Keep in tune! there are more news yet to come! The fight goes on!

Wednesday, June 11, 2014

Update: CryptoDefense rebranded to CryptoWall

After the fortune they reaped with CryptoDefense, not only did the crooks buy more computers from a botnet. They also rebranded it to 'CryptoWall' and made considerable changes to its website:

+ Multilanguage Support
+ Slight color changes in their website. Now it looks nicer, I confess.
+ Support (You can message them in case you need help) 

- Their English sucks, so I haven't noticed any improvement in this area.

* Ransomware notes are now named as:
What does it mean to 'buy computers'?

Most computers that were hit by this nasty ransomware had been previosuly infected by a botnet. A botnet is a network of infected computers that can be spied and controlled by their masters (those who own the botnet network). 

These computer programs are usually used to gather users' credentials to home-banking and to perform DDoS attacks on websites, etc. (Yes, you can pay these crooks to bring down your competition's website).

One of their businesses consists of selling a certain number of infected computers so that the buyers can install whatever they want in them. In this case: CryptoDefense/CryptoWall. It's not a big issue for them to sell these computers because most of them are not used for homebanking anyway. So, they remain rather useless. Now, thanks to ransomware, they no longer have to wait until they get a bank account. They just encrypt their files and get paid via Bitcoins.

Is there a chance to get my files without payment?

Maybe, I can't tell. The reason why the first 'lucky' victims that were hit by the earliest version of CryptoDefense could recover their files was because its earliest version had a faulty implementation of CryptoAPI (needed to encrypt your files). 

If someone gets access to their hidden servers that provide the decryption tool and verifies the payments, all keys might be released.

Will they go to jail?

I very much hope so. CryptoLocker author has been identified and charges were pushed against him. CryptoLocker is way smarter than this Kiddo ransomware and the author still got caught. So, let's just be patient.

Is this information useful to you? Write me an email or consider a small donation. Any amount will be greatly appreciated!

If you have the virus samples, you can send them. (Place them inside a .zip / .rar file) and use 'infected' as password.

Sunday, April 13, 2014

It's been awhile

I am glad to announce that we were featured on PCWorld, one of the greatest computer magazines in the world.

My old computer screen is dead, and I am using my phone to reply emails and update this blog. That's why I can't always reply quickly and why I ask for donations. Anyway...

Cryptolocker and CryptoDefense have proven to be a highly profitable business warped around the anonymity of cryptocurrencies and the TOR network. You can expect more of this resurgent type of malware to sweep the Internet and spread as wildfire and, as you are reading this article, someone is writing the next cryptovirus that will enter the scene tomorrow; and I am not joking. The only fireproof measure against these nasty threats is backup using non-rewritable media such as DVD-R's and Blueray disks. Cloud storage such as Dropbox seemed safe at first glance but vĂ­ctims also reported they have lost their files there.

To make matters even worse, some victims also reported being hit by two cryptoviruses. This means that they had to pay twice to get their files back. Can you imagine what will happen when more of these viruses emerge in the near future? Go figure...

There is little (to say the most) Antivirus software can do once your files have been encrypted simply because removing the malware will not return your data to its original form unless you have the key. So, better be prepared than sorry: Backup tour files.

I'll update this blog soon... Keep in tune!

Friday, March 28, 2014

You infected the wrong fool!

Yeah, I recovered all my files. ALL and EACH one of them without paying a PENNY. If that wasn't enough, we are also helping victims to recover their files without payment. 

Dear CryptoDefense Authors, if you are reading this: SCREW YOU. Your awful script kiddie skills led our team of true experts to THWART your evil plans, even though you used state-of-the-art RSA encryption. What a bunch of fools! that's like loosing a football match having Lionel Messi, Cristiano Ronaldo and Xavi on your team.

Next step is to report all your domain names (that you lamely use to infect more and more victims).

Now, if you are a victim, feel free to write us at

Tuesday, March 25, 2014

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

Monday, March 24, 2014

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 explains why the concepts of pseudorandom numbers generation (PRNG) and true random number generation (TRNG) exist and radically differ in the fields of computer science. The second is only -and better- securely employed through specialized hardware, which is not built-in in most desktop and laptop computers in the general consumer market. For the first one, however a strong random number generation algorithm is essential throughout the entire process of public key cryptography. 

Most PRNG's use the system clock as parameter (seed) to generate the pair of keys, and this is evident due the use of GetTickCountQueryPerformanceCounter and GetSystemTimeAsFileTime found in the executable samples of this malware.

For example, TrueCrypt  (a disk encryption program) significantly circumvents the boundaries of Software PRNG by prompting the user to aimlessly move the mouse around the screen and to type any keys in the keyboard in the meanwhile during key generation. This well-recognized Open Source Software highlights the importance of secure PRNGs.
[See Official Documentation]

This pretty much emulates TRNG to considerable degree of cryptographic security.

Crypto Defense Ransomware does not meet this security criteria; not only because its deterministic PRNG is predictable, but rather because it generates a text file ("HOW_DECRYPT.TXT") shortly after it encrypts the first directory it finds during execution. This file's time stamp betrays fundamental information that potentially exposes the key generation phase to timing attacks that can be executed within a computationally reasonable amount of time. (Outdated)

It's important to note that this project does not seek to attack the (yet) undisputed mathematical strength of the RSA-2048 algorithm, instead it exploits its PRNG with essential seed parameters that are known in order to reduce the key-space in which the brute-force software will operate to manageable calculable levels.(Under development)

Testing the Malware (Timing)
* Where does the Key Generation take place?

1. 11:27:25 (00 seconds)
The precise execution time, which is often found in the following registry key:
2. 11:27:45 (20 seconds)
First TCP connection to the Control Server is retrieved via a TCP/IP Sniffer
3. 11:27:48 (23 seconds)
Locally generated Private Key is SENT. (Again: TCP/IP Sniffer)
4. 11:27:51 (26 seconds)
First HOW_DECRYPT file is created.

Maximum Time Range (from 1 to 4): 
26 seconds (26,000 milliseconds)

Removing File Timestamp date (leaves 3-4)
(HOW_DECRYPT can't logically exist without the keys)
Reduces the workload by 3 seconds = (3,000 microseconds)

Note: This test was thoroughly run inside a Virtual Computer on Windows 7 64-bits edition. The Host computer's CPU is an Intel i7-4770. Thus the aforementioned procedures would be executed in less time, further reducing the time space to start brute-forcing. 

RSA-2048 benchmarks from
(Click to enlarge)

And based on these benchmarks, it takes a Intel(R) Core(TM) i7-2637M CPU 9.98 seconds to generate a key.

Doing 1024 bit private rsa's for 10s: 39652 1024 bit private RSA's in 9.98s
Doing 1024 bit public rsa's for 10s: 607674 1024 bit public RSA's in 9.98s
Doing 2048 bit private rsa's for 10s: 5544 2048 bit private RSA's in 9.98s
Doing 2048 bit public rsa's for 10s: 179596 2048 bit public RSA's in 9.98s

These two sites will give you an rough idea about how long your CPU would need to generate RSA-2048 keys. I said 'rough' mainly because interpreted languages runs slower than machine code: 

Based on these time measurements, it all indicates that the keys are generated before the second connection with the control server is established [11:27:45]. Otherwise the timelines would illogically overlap onto each other.
Now we can rule out the two last stages. This by itself reduces our brute-force framework by at least 6 seconds (6,000 milliseconds) leaving just 20 seconds work for the cracker. 

This is good news, because between stage 2 and 3, additional seeding from the server might have potentially occurred, thwarting our efforts to brute-force the key within manageable levels. (Uploading .RAW TCP/IP data soon). 

Additionally, we only need to generate the public key given the mechanics of this cracker. Not only does it generate faster (on some processors), it also serves the purpose of encrypting original file samples whose results will be later compared with the encrypted sample. 

Fortunately, this was just a challenge response authentication. Further Replay Attacks will confirm this information.

To generate the Private and Public Keys Pair, it takes 10 seconds each. 
(On Intel(R) Core(TM) i7-2637M).

Way to go!

Now, let's set up the CryptoDefense Cracker execution flow and let's check the requirements to start cracking the PRNG seeds:

Parameters needed

1. Oldest HOW_DECRYPT time stamp.
Can be found by searching HOW_DECRYPT in the entire system and them sorting the results by Date. 
2. A small file that was never encrypted. The smaller, the faster it will go through the cracker.
One can easily find them inside any ZIP or .RAR file that was uncompressed into a folder, leaving the compressed backup intact.
3. The encrypted file version (point 2).
This file is required to compare the previous encrypted file with the output. Once the CryptoDefense Cracker finds a match: KEY FOUND!

Hardware needed:

Now, this is where it all becomes hard though not impossible.  Using the Intel  i7-2637M, we can calculate one key every 10 seconds (Remember we only need to generate the public key). This multiplies per millisecond (10,000). Which results in 100,000 seconds, i.e: 1666 minutes or 27 hours.

That is 166 minutes and roughly 2:45:00 

Is this over? NOT YET!

We still have to process the SAMPLE FILE with the ENCRYPTED FILE through the cracker using the generated keys and then compare the results. This is completely relative to the file size and other factors. Currently, I can not yet make time estimates though it would undoubtedly increase the amount of time needed per test.

Last but not least: The QueryPerformanceCounter API can retrieve the current time in up to microseconds and even nanoseconds resolution .If this is the case, the aforementioned estimates would multiply by 1000. That is about 2776 hours or 115 days. Those 2776 hours would multiply again by 1000 if microseconds were used:  2,766,666 hours = 115,277 days or 320 years only to generate the public key! (On one Intel(R) Core(TM) i7-2637M)

In such case, we plan to use OpenCL and CUDA in order to use GPUs (which are way faster than CPU performing parallel tasks) to further accelerate the cracking process. If it isn't fast enough, we may also add a distributed computing module, so that many computers can work together to crack a group of keys within a manageable amount of time.