Demonslay335

Your files were encrypted by both LolKek (.MME) and GlobeImposter 2.0 (.xls). Both are not decryptable, and only the criminals (unclear if it is one TA or two) have your private keys in both cases.

No, he simply has "File name extensions" hidden in Explorer (it is highly recommended to change that...). You can see the "Type" shows as "DRUME File". As for the 404 error, it's an anomaly based on the files that were listed there. When the decryptor sees the STOP Djvu filemarker ("{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}") in a file, it takes the extension and asks the server "hey, is this Old or New Djvu?" (if it hasn't already asked for that extension). Apparently, those files had the filemarker, but no appended extension. There seems to be a security thing with the server engine that instantly rejects image extensions such as ".gif" for that parameter instead of letting my code handle it. I'll look into it, but it may be out of my control for the time being. Either way, it doesn't affect you much since those files were just in your Recycle Bin. As the decryptor told you for your .drume files, it is Old Djvu, and you need to follow the instructions for uploading file pairs as Amigo-A said. You specifically need to upload an encrypted/original file pair for either a DOCX/XLSX/PPTX, or ZIP file, as those all start with the same first 5 bytes (which is why it is telling you what they are). Edit: the 404 error has been fixed.

It's actually GlobeImposter 2.0 (identification on ID Ransomware has been fixed). Same outcome though, only the criminals have the private key(s) to decrypt your files.

@jaffar Thank you, I was able to confirm the key works for your files with that ID. I have added it to the server for the .rote extension. You may simply re-run the decryptor, and it should be able to decrypt some of your files now.

The FAQ already explains this...

No. Dharma is not decryptable without the private RSA key only the criminals possess. Restore from backups and stop exposing RDP to the web.

They are the exact same malware, just different names; the only thing that changed was the extension. The reason we are able to decrypt MegaLocker at all is because we acquired keys from the criminal's servers. Period. They then changed servers and locked it down better, and continued attacking victims. We do not have keys for victims encrypted after that date, as only the criminals have those keys. The crypto itself is otherwise secure and cannot be broken any other way without the keys.

As the FAQ and all you've read will already tell you, there is nothing we can do. It is impossible to decrypt, as only the criminals have your private RSA key that is unique to your files. Period. This ransomware is exclusively spread via pirated programs, so...

The encrypted files themselves are not infectious or anything. It's always recommended to archive encrypted files in that case in hopes of something changing in the future; unfortunately with STOP Djvu and the new variants with online keys, your only chance will be if the criminals are caught and their private RSA keys seized by law enforcement.

No. If your files were encrypted by an online key, then only the criminals have your key.

@abdi Read the FAQ... it is impossible to decrypt. Period.

The files that were decrypted would have been encrypted by the offline ID... as explained in the FAQ, the malware sometimes encrypts some files with an online key, and others with an offline key. Those 3 files just got lucky. The decryptor would not show the ID if it decrypted them; only if it could not decrypt the files.

Are you sure the file pair you are providing is good? It has to be the exact same file before and after the encryption. Any modifications between that and when it was encrypted would result in a bad pair. You can zip the files together and post them here if the forum allows (use a third-party sharing site if it doesn't), and I can take a look.

We will need the malware executable that encrypted the files in order to update our decryptor.

TXT files will not be possible with this method. The keystream generation depends on the first 5 bytes of the file - TXT files do not have a "standard", and thus will likely never have the same 5 bytes. Unless every single TXT file you have started with the same first word or two by chance...

Some extensions they re-use the same offline ID and corresponding key. In this case, .bboo, .ooss, and .mool all have the same offline ID.

That looks to be a good file pair. It may take a few days to a week to crack the password. I'll let you know.

You can zip the files together and use any third-party sharing site such as WeTransfer, SendSpace, Dropbox, Google Drive, etc. Just paste the link here.

Perfect. Confirmed that is the ransomware. Good news is we should be able to break it. It may take awhile though. Can you provide me with an encrypted file and it's original? Specifically an ".encryptedS" file please. Also, fun fact: the ransomware uses extension ".encryptedL" for files larger than 50,000,000 bytes, and extension ".encryptedS" for files smaller. Must stand for "Large" and "Small" respectively.

You can simply upload it to VirusTotal and provide the link here.

Keystream added to server. Should work for most of your other .mkv files. [+] ID: SinSPnFW89EGyfgIuac5Ym6CxpIkZ5ZjdYvgPcoV [+] Created keystream for files starting with: 1A45DFA3A3

It may be something new, I've not seen a ransom note use that type of victim ID pattern before. We would need the malware executable in order to analyze any further.

No... that's called a plaintext attack, and is not possible with New Djvu. Every file is encrypted with a unique (securely generated) Salsa20 key, which is then protected by RSA. Feel free to lookup the feasibility of breaking the Salsa20 algorithm (yes, the malware properly uses all 20 rounds) or RSA-2048.

No. Read the FAQ.

New Djvu, and that is an Online ID. Only the criminals have your key. Read the FAQ: STOP Djvu FAQ