- Author: Mehardeep Singh Sawhney
- Editor: Benila Susan Jacob
Research indicates that a Ransomware attack occurs every 11 seconds roughly translating to an approximate 3 million attacks throughout the year. Ransomware attacks are no longer reserved events. Companies are at a constant threat to their revenue, data, brand, image, and subsequent shutdown of the business.
Redeemer ransomware was initially identified in June 2021, and since then, four public versions (1.0, 1.5, 1.7, and 2.0) have been released. This article contains the technical analysis of the Redeemer ransomware and its various features.
Evolution of the Redeemer Ransomware 2.0
The threat actor, Cerebrate operating on a cybercrime forum named Dread has been actively promoting the Redeemer ransomware. They have recently started operating on the Breached forum and have released its latest version (version 2.0) on the same.
Redeemer has gone through four version changes since September 2021. The latest version includes improved graphical features such as a GUI builder interface, an icon change for encrypted files, a detailed instructions list, etc. The threat actor also claims to have added support for Windows 11 along with few cryptographic changes to the latest version. The image below describes the features added with each version release of the Redeemer ransomware.
|Using the builder executable, the attacker creates a ransomware executable.|
|The attacker specifies an RSA private key file, email address for contact, XMR amount and the option to disable ‘melt’, if a crypter is being used to encrypt the ransomware. Enabling ‘melt’ will make the ransomware executable delete itself and relocate to a random directory on the system, and execute from there in a hidden state.|
|Using the Generate Key Pair option, an RSA private key is generated which is sent to the Malware author (Cerebrate) along with the encrypted public key generated by the ransomware executable. The public key is received from the victim.|
|The Malware author (Cerebrate) will share the master key only upon having received 20% of the collected ransom amount. Thus, the victim can only decrypt their files once 20% of the ransom payment has been made by the affiliate attacker.|
Related Read Technical Analysis of Emerging, Sophisticated Pandora Ransomware Group
Details of the Ransomware
- This Ransomware is written in C++ and comes with a builder and decrypter executable.
- It uses the following encryption algorithms:
- AES256 is used to encrypt the files on the victim’s computer
- RSA is used to encrypt the key
- The ransomware clones itself with the name of a system executable file (eg. conhost.exe), and creates a hidden folder for itself in the Windows directory.
- It terminates all the running processes and executables which may pose a threat to the encryption routine.
- It deletes all shadow copies of files and clears all event as well as application logs using wevtutil, vssadmin, and wbadmin.
- It uses multithreading in order to enumerate the filesystem and encrypt files. It creates 35 different threads that point to the same encryption routine.
- It also modifies the Winlogon registry value and sets it to display the ransom note. Thus, when a user logs into the machine, the ransom note is displayed.
The signature of this executable shows us that it is written in C++. When conducting the string analysis, multiple Base64 encoded strings were observed, some of which get decoded to the public key used for encryption, and powershell commands. Upon decoding one of these strings, the following translation was obtained: ‘Redeemer Ransomware – Your Data Is Encrypted’.
Stage I – Pre-Encryption Operations
Upon execution, Redeemer first hides its console window by using a call to the ShowWindow Windows API. It then creates a Mutex, called the RedeemerMutex, in order to make sure that multiple instances of the ransomware are not running on the same system.
An RSA public key, ransom amount, and contact email ID are then loaded as Base64 values into memory and decoded for further usage. This Ransomware heavily uses Base64 for string encoding purposes.
Stage II – Preparing for Encryption
The second stage of the ransomware is dictated by the transfer of control to a specific logic section that is controlled by the argument count value. This is done by moving itself under a different name to a world writable directory as shown in the image below.
A new instance is spawned that does the encryption. The name of the newly spawned process will be randomly chosen from the list shown in the image above. The entire process breakdown is covered in the following section:
- The ransomware randomly chooses the directory and executable names by using the logic shown below. It also sets the directory attributes to hidden using the SetFileAttributes Windows API. In this case, the directory selected is C:\Windows\SQL and the executable name is taskmgr.exe.
- Now, the ransomware executes its copy using the
ShellExecuteWWindows API, while taking the path to the old exe as an argument. This is done in order to delete its old copy and continue running as an imposter system executable, which will commence the encryption.
- The routine for directory enumeration and encryption will begin only after the above argument condition is met. A check is implemented for the same by counting the number of arguments passed to the executable.
- The new executable then runs the Windows Event Utility (wevtutil) commands using CMD in order to clear important event logs. The vssadmin and wbadmin commands are used to delete all shadow copies, backup catalogs, and system-state backups in order to make file recovery impossible.
- The ransomware terminates executables and services (including security applications) which might hinder the encryption operations. The code for this is hardcoded in the program as Base64 strings which are decoded using the taskkill and net stop commands. (Refer to the List of Executables & Services Terminated by the Ransomware)
- The ransomware also edits the
Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon</strong> registry key, modifies the
LegalNoticeTextvalues, and sets them to the ransom note. Thus, when a user logs in, the ransom note is displayed.
- The ransomware also creates an exception list so that it does not encrypt the following:
- System and OS directories
- Redeemer ransomware (i.e itself)
- Ransom note
- Already encrypted files
Related YourCyanide: An Investigation into ‘The Frankenstein’ Ransomware that Sends Malware Laced Love Letters
Redeemer is capable of enumerating and encrypting both local files and network-attached drives.
It enumerates local drives using the following
GetLogicalDrives Windows APIs:
- For the local files, it uses
- For network assets, it uses
It executes these operations using a loop with
It should be noted that this ransomware uses multithreading for encryption, which makes it efficient in terms of CPU usage. It creates 35 different threads, each pointing to the encryption routine.
It initializes the ransom note in Base64 and writes the decoded value to a file named
Read Me.TXT. The encrypted files are saved with the
- When an encrypted file is clicked by the user/victim, the following message is displayed.
- The ReadMe.TXT file containing the ransom note is displayed in the image below.
- To decrypt their files, the victims are asked to pay the demanded ransom amount in Monero.
- Once the ransom payment is verified, the victim receives a decryption tool and a key which allows them to restore their files.
Read Also Analysis and Attribution of the Eternity Ransomware: Timeline and Emergence of the Eternity Group
List of Executables & Services Terminated by the Ransomware
|Executables to be terminated|
|Services to be Terminated|
Indicators of Compromise (IoCs)