Dealing With Script Kiddies - Cryptear.B Incident
Two days ago, Securityweek reporter Eduard Kovacs contacted with me and asked if I heard about the Cryptear.B incident. Well I wasn't aware of that. I read the Trendmicro's post . It seems another group used my Hidden Tear code and caused some trouble again. In Trendmicro's article they claimed that the file recovery is not possible because the ransomware also encrypts the decryption key.
Another point which makes this attack unique is the fact that the generated key is lost within the valid file. The generated decryption key is saved inside a .txt file. Once dropped in the desktop folder, the malware starts encrypting files. Like other crypto-ransomware, this makes it very difficult to recover the files, even after the victim pays the ransom.
I sent them few mentions and told if they send me the malware maybe I can crack it because I had serious doubts about they didn't even try for it.
Anyway I believe I can decrypt it if @TrendMicro team send me the malware
— Utku Sen (@utku1337) 14 Ocak 2016
They didn't send me it. However, another security researcher Yonathan Klijnsma sent me the sample even if he is seriously against the Hidden Tear project. In this article he says:
“There is no educational purpose for releasing source code for a piece of ransomware,” Klijnsma told SecurityWeek. “Cryptographic implementations to secure files, sure, ransomware no. We have too much to deal with already, you really don't want to help anyone in that business.”
I already explained the security flaw in Hidden Tear in this article. You can check it if you don't know about it.
So I decompiled the ransomware to check the codes. It appeared to a fork of Hidden Tear Offline Edition . Offline edition was coded for the computers which has no internet access. You can read the details in this post
Let's check some piece of codes from the Cryptear.B
They didn't even change the project name. Let's check if they fixed the security flaw or not.
They still using the .Net's Random Class which is seeded with Environment.TickCount (gets the number of milliseconds elapsed since the system started) . Which is reduces the surface of brute forcing and beyond that it’s easy to predict.
Let's check AES function.
They didn't change it a bit. It still using static salt for encryption and reuses the IV.
Understanding The Process
Cryptear.B works almost same with the Hidden Tear Offline. So let's talk about basic features of Hidden Tear Offline. It's designed for running inside a USB stick. When an attacker runs the ransomware inside a USB stick the basic workflow is:
- ransomware clones itself to computer
- creates a random encryption key
- copies the key to usb stick and computer
- waits for a specific time
- encrypts files and drop a ransom note
- removes key from computer.
So let's look at how Cryptear.B works. I recorded a video in my VM.
When you run the ransomware the basic workflow is:
- It creates a random encryption key
- Copies itself
- Drops the encryption key to Desktop
- Waits for a specific time
- Changes the background
- Encrypts the files
As you can see in the video, the encryption key is dropped to desktop before it starts to action. However most of people won't catch it.
The other silly mistake is when you run it for the second time, it gives an error and terminates before encryption. We can see the created key. However, this key is not same with the first key. So it won't help us. I just wanted to show how it's bad implemented.
And the Trendmicro was right. It doesn't send the key to a server and it just encrypts the key file. Even the ransom is paid, attackers can't recover the files. If it doesn't have a security flaw of course..
Recovering the Files
As I said before it still has the same security flaw with Hidden Tear. But it also have a flaw that Hidden Tear doesn't.
Remember that we need to have at least one plaintext version of an encrypted file in Hidden Tear's recovery process. Because the process was basically like this:
- Decrypt the encrypted file with a key
- Decrypted text == our plaintext?
- If yes, we got the key
- If no, try it with another key
In Cryptear.B we don't need to have a plaintext file. Remember that we have a encrypted text file in desktop which is includes the key. Plaintext version of the text file is in this format as you saw in the video:
"computername randomkey" | "dene-pc asjasblablabla*"
So the recover process will be:
- Decrypt the encrypted text file with a key
- Decrypted text == computer name + key?
- If yes, we got the key
- If no, try it with another key
Again, all we need to do is finding the seed. We can get it from timestamp of encrypted text file with File.GetLastWriteTime Method. Then we convert it to Environment.TickCount to get exact integer.
Let's check if we can find the encryption key first. Here is my Poc (note that "s1fGvX/XFh?QImK" string is generated by Cryptear.B):
Ok we got the key but there were to many tries. It was around 30 in Hidden Tear recovery
The reason is: It takes current system time as seed, generates a random key with it and waits for a long time. After then it encrypts the files. So when we get the file's last write timestamp, we have bigger time gap comparing to Hidden Tear. But still, it's not a huge gap.
Ok we know that our method is still working. So let's focus on a real scenario. We can recover the key file with this Poc. It works with the process which I described above:
I don't know why these kiddies used offline edition. Maybe they thought that Hidden Tear is backdoored but offline edition wasn't. Anyway, it was more easy to deal with.
I think the Trendmicro guys didn't even try to crack this ransomware. Because it's so easy to do. Remember how Bitdefender lab defeated the Linux Encoder. It will be better if the Trendmicro uses the same approach on bad implemented ransomware incidents.