We at K7 Labs came across DcDcrypt ransomware sample, that had infected a user machine and encrypted all user files. Usually the chances of getting back the encrypted files in such a scenario is 0, given the level of sophistication involved in the encryption. Also paying up the ransomware does not guarantee the files be decrypted as “promised” in the ransomware note. Usually the ransom notes and the encrypted are only left behind in a victimized system, the ransomware sample usually gets self-deleted. This case wasn’t so, the ransomware binary was available and naturally we had a closer look at it. Turns out we were able to decrypt the user files after having looked at the malware. The malware and the decryptor would be henceforth discussed.
Analysing Ransomware
This is a basic ransomware written in C#. It encrypts the user files and writes a ransom note in every directory. It does not delete backups, does not create persistence,does not even self-delete(like we mentioned earlier).
Upon execution, this ransomware first checks for a file named “ID.cl”. If the file is not present in the same directory, it creates the file and writes a randomly generated ID (used as Victim ID in this case) into it and also stores the ID for further use in a variable named userID. If the ID.cl file is already present in the same directory it will read and store the content (ID) into the same variable userID as shown in Figure 1.
This ransomware then asks the user to write yes and press enter to continue the encryption through the command line. Once obliged before the start of the encryption the ransomware first uses the userID and a hardcoded salt to create a password. It uses the method GetHashCode of passwordHasher class which is then stored in a variable named password as shown in Figure 2.
GetHashCode method just adds the userID and salt and sends it to another method called Hasher which will create a Sha512 hash of the added userID and salt. Then the sha512 hash is converted into base64 as shown in Figure 3. The resultant value is stored in the variable named password of the class CoreEncrypter.
After generating the password, the ransomware starts encrypting the contents of the current directory as shown in Figure 4. Enc method takes the current directory path as an argument and starts encrypting the files within, traversing all the folders inside the current directory. This ransomware does not encrypt anything other than the contents of the current directory it has been run from.
The Enc method contains two “for” loops, Figure 4: Enc method being called with the current directory path as argumentone to traverse the sub-directories within the current directory using recursive call to Enc method and the other one to encrypt the files of the current directory. Before encrypting the file, it first checks if the file name contains any of the following strings:
- ‘.[Enc]’ which is present in the extension of the encrypted file.
- ‘.hta’ which is the extension of ransom note,’ID.cl’ is the userID file that ransomware creates in the beginning.
- ’desktop.ini’ is a configuration file.
- ‘Encrypter.exe’ is the name of ransomware.
If any one of these strings is present in the filename then the ransomware won’t encrypt that file. Check Figure 5 for details.
EncryptFile contains the encryption routine which is being called in the For loop 1 with the filename as an argument as shown in Figure 5. Let’s analyse this method so that we can figure out how the encryption is done.
As we can see in Figure 6 EncryptFile method uses Rfc2898DeriveBytes to generate bytes using a password (generated previously using userID and salt) and a salt which can later be used to derive the key and IV(Initialization Vector) for the encryption algorithm. This ransomware uses Rijndael as encryption algorithm which is the predecessor of AES algorithm, at default block size (128 bytes) and in cbc mode it works like AES itself.
Microsoft declared this algorithm as obsolete and suggests using AES instead.
The password that is generated using userID and hardcoded salt remains the same for the same userID (check Figure 2 for reference) and since the password is the same, the key and IV generated using Rfc2898DeriveBytes also remains the same for the same userID. Rijndael is a symmetric algorithm so the Key-IV pair used for encryption can be used for decryption also.
After initialising all the variables related to encryption, it writes a ransom note in the current directory. Then the ransomware checks for the file size. If it is less than 1000000 bytes, it will create a new file with the same name + encryption extension and then encrypt the original file and put the encrypted content in new file and deletes the original file but if it is larger than the mentioned size it will just XOR the 1st byte of the file with 255 and renames the file with original name + encryption extension, where the encryption extension is .[Enc][dc.dcrypt@cyberfear.com And dc.dcrypt@mailfence.com (send both) ATTACK ID = %userID% Telegram ID = @decryptionsupport1].
Decryptor Internals
As we already know the ransomware generates a password using userID that it created randomly and a hardcoded salt, since every infected user have a unique userID and we know it will be stored in a file called ID.cl so in our decryptor, instead of creating the userID we would instead read ID.cl file to get the userID and use the same method for generating the password (GetHashCode in Figure 3) as ransomware did to generate the password.
After that this tool would scan all the drives for any encrypted files, all the encrypted files have .[Enc] in their extension hence identifying the encrypted file wouldn’t be too hard.
Since the ransomware used built-in classes and methods provided by .Net for encrypting the files (RijndaelManaged) we can use the same for decrypting the files. We will generate the Key and IV same way ransomware generated with the password using Rfc2898DeriveBytes.
In order to decrypt the file size is checked if less than 1000000 bytes then the tool would proceed to decrypt it. Ransomware uses rijndaelManaged.CreateEncryptor to create encryption stream in the same manner we can use rijndaelManaged.CreateDecryptor to create the decryption stream it would use the Key-IV generated before for decryption.
After decryption, we will write the decrypted bytes into a new file and keep the encrypted file as .[backup] in case the file is not decrypted correctly. For files above 1000000 bytes we will XOR the 1st byte with 255 again to get the original byte and rename the file as the original name (without encryption extension).
We at K7 Labs provide detection for the DcDcrypt ransomware and all the latest threats. Users are advised to use a reliable security product such as “K7 Total Security” and keep it up-to-date to safeguard their devices.
Indicators of Compromise (IOCs)
| Filename | Hash | Detection Name |
| Encrypter.exe | 1A5C50172527D4F867951FF73AB09ED5 | Trojan(0001140e1) |
References
https://docs.microsoft.com/en-us/archive/blogs/shawnfa/the-differences-between-rijndael-and-aes
