{
	"id": "76f417f7-ab64-4b49-9910-975251c78aa1",
	"created_at": "2026-04-06T01:30:14.880962Z",
	"updated_at": "2026-04-10T03:20:56.400684Z",
	"deleted_at": null,
	"sha1_hash": "94ded86266a9e8b56da2f6e35c5f18be3b894d35",
	"title": "DcDcrypt Ransomware Decryptor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1732607,
	"plain_text": "DcDcrypt Ransomware Decryptor\r\nPublished: 2022-09-26 · Archived: 2026-04-06 00:23:52 UTC\r\nWe at K7 Labs came across DcDcrypt ransomware sample, that had infected a user machine and encrypted all user\r\nfiles. Usually the chances of getting back the encrypted files in such a scenario is 0, given the level of\r\nsophistication involved in the encryption. Also paying up the ransomware does not guarantee the files be\r\ndecrypted as “promised” in the ransomware note. Usually the ransom notes and the encrypted are only left behind\r\nin a victimized system, the ransomware sample usually gets self-deleted. This case wasn’t so, the ransomware\r\nbinary was available and naturally we had a closer look at it. Turns out we were able to decrypt the user files after\r\nhaving looked at the malware. The malware and the decryptor would be henceforth discussed.\r\nAnalysing Ransomware\r\nThis is a basic ransomware written in C#. It encrypts the user files and writes a ransom note in every directory. It\r\ndoes not delete backups, does not create persistence,does not even self-delete(like we mentioned earlier).\r\nUpon execution, this ransomware first checks for a file named “ID.cl”. If the file is not present in the same\r\ndirectory, it creates the file and writes a randomly generated ID (used as Victim ID in this case) into it and also\r\nstores the ID for further use in a variable named userID. If the ID.cl file is already present in the same directory it\r\nwill read and store the content (ID) into the same variable userID as shown in Figure 1.\r\nFigure 1: Creating a userID for the victim\r\nThis ransomware then asks the user to write yes and press enter to continue the encryption through the command\r\nline. Once obliged before the start of the encryption the ransomware first uses the userID and a hardcoded salt to\r\ncreate a password. It uses the method GetHashCode of passwordHasher class which is then stored in a variable\r\nnamed password as shown in Figure 2.\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 1 of 10\n\nFigure 2: Generating a password\r\nGetHashCode method just adds the userID and salt and sends it to another method called Hasher which will\r\ncreate a Sha512 hash of the added userID and salt. Then the sha512 hash is converted into base64 as shown in\r\nFigure 3. The resultant value is stored in the variable named password of the class CoreEncrypter.\r\nFigure 3: GetHashCode and Hasher method\r\nAfter generating the password, the ransomware starts encrypting the contents of the  current directory as shown in\r\nFigure 4. Enc method takes the current directory path as an argument and starts encrypting the files within,\r\ntraversing all the folders inside the current directory. This ransomware does not encrypt anything other than the\r\ncontents of the current directory it has been run from.\r\nFigure 4: Enc method being called with the current directory path as argument\r\nThe Enc method contains two “for” loops, Figure 4: Enc method being called with the current directory path as\r\nargumentone to traverse the sub-directories within the current directory using recursive call to Enc method and the\r\nother one to encrypt the files of the current directory. Before encrypting the file, it first checks if the file name\r\ncontains any of the following strings: \r\n‘.[Enc]’ which is present in the extension of the encrypted file.\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 2 of 10\n\n‘.hta’ which is the extension of ransom note,’ID.cl’ is the userID file that ransomware creates in the\r\nbeginning.\r\n’desktop.ini’ is a configuration file. \r\n‘Encrypter.exe’ is the name of ransomware. \r\nIf any one of these strings is present in the filename then the ransomware won’t encrypt that file. Check Figure 5\r\nfor details.\r\nFigure 5: Implementation of Enc method\r\nEncryptFile contains the encryption routine which is being called in the For loop 1 with the filename as an\r\nargument as shown in Figure 5. Let’s analyse this method so that we can figure out how the encryption is done.\r\nAs we can see in Figure 6 EncryptFile method uses Rfc2898DeriveBytes to generate bytes using a password\r\n(generated previously using userID and salt) and a salt which can later be used to derive the key and\r\nIV(Initialization Vector) for the encryption algorithm. This ransomware uses Rijndael as encryption algorithm\r\nwhich is the predecessor of AES algorithm, at default block size (128 bytes) and in cbc mode it works like AES\r\nitself.\r\nMicrosoft declared this algorithm as obsolete and suggests using AES instead.\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 3 of 10\n\nFigure 6: Encryption routine and ransom note\r\nThe password that is generated using userID and hardcoded salt remains the same for the same userID (check\r\nFigure 2 for reference)  and since the password is the same, the key and IV generated using Rfc2898DeriveBytes\r\nalso remains the same for the same userID. Rijndael is a symmetric algorithm so the Key-IV pair used for\r\nencryption can be used for decryption also.\r\nAfter initialising all the variables related to encryption, it writes a ransom note in the current directory. Then the\r\nransomware checks for the file size. If it is less than 1000000 bytes, it will create a new file with the same name +\r\nencryption extension and then encrypt the original file and put the encrypted content in new file and deletes the\r\noriginal file but if it is larger than the mentioned size it will just XOR the 1st byte of the file with 255 and renames\r\nthe file with original name + encryption extension, where the encryption extension is .[Enc]\r\n[dc.dcrypt@cyberfear.com And dc.dcrypt@mailfence.com (send both) ATTACK ID = %userID% \r\nTelegram ID = @decryptionsupport1].\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 4 of 10\n\nFigure 7: Checking file size encrypting file\r\nFigure 8: XORing 1st byte of large files\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 5 of 10\n\nFigure 9: Ransomware execution\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 6 of 10\n\nFigure 10: Ransom Note\r\nDecryptor Internals\r\nAs we already know the ransomware generates a password using userID that it created randomly and a hardcoded\r\nsalt, since every infected user have a unique userID and we know it will be stored in a file called ID.cl so in our\r\ndecryptor, instead of creating the userID we would instead read ID.cl file to get the userID and use the same\r\nmethod for generating the password (GetHashCode in Figure 3) as ransomware did to generate the password. \r\nFigure 11: Generating password with userID\r\nAfter that this tool would scan all the drives for any encrypted files, all the encrypted files have .[Enc] in their\r\nextension hence  identifying the encrypted file wouldn’t be too hard.\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 7 of 10\n\nFigure 12: Scanning all drives\r\nFigure 13: Checking file name for .[Enc] and sending it for decryption\r\nSince the ransomware used built-in classes and methods provided by .Net for encrypting the files\r\n(RijndaelManaged) we can use the same for decrypting the files. We will generate the Key and IV same way\r\nransomware generated with the password using Rfc2898DeriveBytes.\r\nFigure 14: Initialising Key and IV for decryption\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 8 of 10\n\nIn order to decrypt the file size is checked if less than 1000000 bytes then the tool would proceed to decrypt it.\r\nRansomware uses rijndaelManaged.CreateEncryptor to create encryption stream in the same manner we can\r\nuse rijndaelManaged.CreateDecryptor to create the decryption stream it would use the Key-IV generated before\r\nfor decryption.\r\nFigure 15: Decrypting file\r\nAfter decryption, we will write the decrypted bytes into a new file and keep the encrypted file as .[backup] in case\r\nthe file is not decrypted correctly. For files above 1000000 bytes we will XOR the 1st byte with 255 again to get\r\nthe original byte and rename the file as the original name (without encryption extension).\r\nFigure 16: XORing 1st byte with 255 for larger files\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 9 of 10\n\nFigure 17: Decryption Tool\r\nWe at K7 Labs provide detection for the DcDcrypt ransomware and all the latest threats. Users are advised to use\r\na reliable security product such as “K7 Total Security” and keep it up-to-date to safeguard their devices.\r\nIndicators of Compromise (IOCs)\r\nFilename Hash  Detection Name\r\nEncrypter.exe 1A5C50172527D4F867951FF73AB09ED5 Trojan(0001140e1)\r\nReferences\r\nhttps://docs.microsoft.com/en-us/archive/blogs/shawnfa/the-differences-between-rijndael-and-aes\r\nhttps://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rijndaelmanaged?view=net-6.0\r\nSource: https://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nhttps://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://labs.k7computing.com/index.php/dcdcrypt-ransomware-decryptor/"
	],
	"report_names": [
		"dcdcrypt-ransomware-decryptor"
	],
	"threat_actors": [],
	"ts_created_at": 1775439014,
	"ts_updated_at": 1775791256,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/94ded86266a9e8b56da2f6e35c5f18be3b894d35.pdf",
		"text": "https://archive.orkl.eu/94ded86266a9e8b56da2f6e35c5f18be3b894d35.txt",
		"img": "https://archive.orkl.eu/94ded86266a9e8b56da2f6e35c5f18be3b894d35.jpg"
	}
}