new variant of STOP/DJVU left me SCARED

On Saturday, a client of mine arrived with a new variant of STOP/DJVU, this RANSOMWARE family is already old, generally its encryption is easy to break, and can even be broken by some decryption programs. However, these 3 new variants that I detected scared me, I have never seen anything at this level of encryption, simply with my 5 years in the market I had never seen this

 -0qaNHWQ.jpg   42.17KB   1 downloads
 

the 3 new variants that I detected of STOP/DJVU are files with extensions:

.AZQT ( v0790 ) .AZOP ( v0792 ) .AZHI ( v0793 )
 
 
I've been racking my brain over this for 3 days, these ransomware are increasingly complex, I don't know how far this will go.
 
 
I'm not going to boast about my decryption skills, I consider myself good at it, but I think I'll give up on solving this ransomware.
 
What do you think should be done? I'm almost recommending my client to pay the ransom amount to the kidnapping hacker

I attach a Google Drive link with 2 ransomware samples + the READ.ME file

https://drive.google.com/drive/folders/1KvO91tWBG1R4MhAs0Zu02dXy3mF6P1Tg?usp=sharing

Edited by priscilaspinelli, Today, 09:05 AM.

Crypto malware can be responsible for dual (multiple) infections since it will encrypt any directory or file it can read/write to regardless if previously encrypted by another ransomware or variant. Ransomware does not care about the contents of the data or whether your files are already encrypted...it will just re-encrypt (double-encrypt) them again and again if it has access. Even the same ransomware can encrypt data multiple times with different strains which may result in file corruption. 
 
That means dealing with all ransomwares, ransom demand payments and different decryptors in order to decrypt data if the encryption is caused by different ransomware families. 
 
Newer STOP (DJVU) Ransomware variants are known to cause dual (multiple) encryption with more than one or the same variant because the ransomware is loaded as a Scheduled Task and sets itself to run every 5 minutes. 
 
You are dealing with newer variants of STOP (Djvu) Ransomware as explained here by Amigo-A (Andrew Ivanov). Since switching to the new STOP Djvu variants (and the release of .gero) the malware developers have been consistent on using 4-letter extensions.
 
The .djvu* and newer variants will leave ransom notes named _openme.txt, _open_.txt or _readme.txt
 
Please read the first page (Post #1) of the STOP (Djvu) Ransomware Support Topic for a summary of this infection, it's variants, any updates and possible decryption solutions using the Emsisoft STOP Djvu Decryptor. See Post #2 for tools (JpegMedic ARWE, Media_Repair) which can be used to partially repair (not decrypt) JPEG and audio/video files (WAV, MP3, Mp4, M4V, MOV, 3GP) partially encrypted by ransomware.
 
In regards to new variants of STOP (Djvu) Ransomware...decryption of data requires an OFFLINE ID with corresponding private key. Emsisoft can only get a private key for OFFLINE IDs AFTER a victim has PAID the ransom, receives a key and provides it to them so the key can be added to their database.
 
If infected with an ONLINE KEY, decryption is impossible without the victim’s specific private key. ONLINE KEYS are unique for each victim and randomly generated in a secure manner with unbreakable encryption. Emsisoft cannot help decrypt files encrypted with the ONLINE KEY due to the type of encryption used by the criminals and the fact that there is no way to gain access to the criminal's command server and retrieve this KEY. ONLINE ID's for new STOP (Djvu) variants are not supported by the Emsisoft Decryptor.
 
The Emsisoft Decryptor will also tell you if your files are decryptable, whether you're dealing with an "old" or "new" variant of STOP/Djvu, and whether your ID is ONLINE or OFFLINE.
 
If you run the Emsisoft Decryptor for a new variant with an ONLINE ID, the decryptor will indicate there is "no key" under the Results Tab and note it is impossible to decrypt.

Error: No key for New Variant online ID ***************************
Notice: this ID appears to be an online ID. decryption is impossible

** If there is no OFFLINE ID for the variant you are dealing with, we cannot help you unless a private key is retrieved and provided to Emsisoft. This is only possible if a victim pays the criminals and shares the key with Emsisoft. When and if the private key for any new variant is obtained it will be pushed to the Emsisoft server and automatically added to the decryptor. Thereafter, any files encrypted by the OFFLINE KEY for that variant can be recovered using the Emsisoft Decryptor. For now, the only other alternative to paying the ransom, is to backup/save your encrypted data as is and wait for possible future recovery of a private key for an OFFLINE ID.
 
There is no timetable for when or if a private key for an OFFLINE ID will be recovered and shared with Emsisoft and no announcement by Emsisoft when they are recovered due to victim confidentiality. That means victims should keep reading the support topic for updates or run the decryptor on a test sample of encrypted files every week or two to check if Emsisoft has been able to obtain and add the private key for the specific variant which encrypted your data.
 
** If an OFFLINE ID is available for the variant you are dealing with and your files were not decrypted by Emsisoft Decryptor, then you most likely were encrypted by an ONLINE KEY and those files are not recoverable (cannot be decrypted) unless you pay the ransom to the criminals and receive the private key. 
 
You need to post any questions in the above support topic. If you have followed those instruction and need further assistance, then you still need to ask for help in that support topic.
 
Rather than have everyone with individual topics and to avoid unnecessary confusion, this topic is closed.
 
Thanks
The BC Staff

Note: If you are thinking about your client paying the ransom or negotiating with these types of criminals, (which is not advisable) you may want to read my comments about victim experiences in this topic (Post #16) first.