In the latest Profero report - Senior Incident Responder Brenton Morris states that RansomeXX decryptors have failed to encrypt different files for the victims that have paid for the ransom demanded by the Linux Vmware ESXI malicious attacker. Profero has found that this RansomExx organization does not lock Linux files appropriately, which might contribute to damaged data during encryption.
Following a reverse engineering process of the RansomExx Linux encrypter, Profero found that perhaps the problem was created by the inadequate encryption of Linux files. The encrypted file would have included encrypted data and unencrypted data afterward if the ransomware were to encrypt a Linux file simultaneously.’
RansomEXX encrypts the disc data and thereafter demands a ransom to acquire the key to decode. Encryption is arranged using the Open Source mbedtls package, so when the virus is activated, it produces a 256-bit key and encodes all the existing files in ECB mode using AES block encryption. Then after, each second, a new AES key will be produced, i.e. various files with different AES keys will be encrypted.
Each AES key is encrypted and connected to every encrypted file via a public RSA-4096 key included in malware code; the ransomware might purchase a private key from the victim for decryption.
"Some strains of Linux ransomware will attempt to acquire a file lock using fcntl while others will often not attempt to lock files for writing, and instead either knowingly choose to take the risk of corrupting the files or do so unknowingly due to lack of Linux programming experience," Morris told. "The Linux version of RansomEXX did not attempt to lock the file at all."
If RansomExx encrypts a document, an RSA encrypted decryption key will be added to each file's end. The person who collects a ransom provides a decryptor that can decrypt the encoded decryption key of each file and then use that to decipher the contents of the file.
However, since unencrypted material is annexed to the file end in these problematic encrypted files, the decrypter couldn't read the encrypted key correctly and the file will not be decrypted.
"Because the attackers provide paying victims with a decryption tool they must run to decrypt their files there is a risk that the decryption tool may be malicious. This requires affected victims to reverse engineer the provided decryption tool to ensure there is no hidden payload or malicious features, a time investment that can be problematic for some organizations during a ransomware incident," explains Profero's blog post.
Profero has published a RansomEXX open-source decryptor that can decrypt encrypted files with the file lock problem to assist its customers and the cyber security industry at large.
Victims still have to have a decryption key from the malicious attacker, although now they can take time to evaluate one given by actors who are confronted with it instead.
