Read The Manual Locker: A Private RaaS Provider

By Max Kersten · April 13, 2023

The underground intelligence was obtained by N07_4_B07.

Another day, another ransomware-as-a-service (RaaS) provider, or so it seems. We’ve observed the “Read The Manual” (RTM) Locker gang, previously known for their e-crime activities, targeting corporate environments with their ransomware, and forcing their affiliates to follow a strict ruleset. Is this yet another ransomware gang, or is there more to this gang and their locker than meets the eye? This blog investigates the actor, along with a technical deep dive into their Windows ransomware executable.

Executive summary

The “Read The Manual” Locker gang uses affiliates to ransom victims, all of whom are forced to abide by the gang’s strict rules. The business-like set up of the group, where affiliates are required to remain active or notify the gang of their leave, shows the organizational maturity of the group, as has also been observed in other groups, such as Conti.

The gang’s modus operandi is focused on a single goal: to fly below the radar. Their goal is not to make headlines, but rather to make money while remaining unknown. The group’s notifications are posted in Russian and English, where the former is of better quality. Based on that, it isn’t surprising that the Commonwealth of Independent States in Eastern Europe and Asia (CIS) region is off-limits, ensuring no victims are made in that area.

Lifting RTM’s veil

The RTM Locker gang’s panel provides a look into their rules, targets, and modus operandi. These provide an insight into the group’s targets, and their way of working. Additionally, some estimated guesses regarding (a part of) the group’s members’ geographic locations can be made based on the available information.

The gang’s panel and tactics

The panel’s login page requires a username and password combination, along with a captcha code to prevent brute force login attempts by other actors and researchers alike.

Within the panel, affiliates can add ransomed victims. This shows how the group’s methods are aligned with the current of standard behavior of ransomware gangs: the intent to extort their victims twice. Once by encrypting files, and once by naming and shaming their victims by publishing stolen and exfiltrated data. The image below shows the panel’s page to add victims; note the data release timer which is to be set by the affiliate.

An excerpt from the ransom note provides further evidence of the strategy: “All your documents, photos, reports, customer and employee data, databases and other important files are encrypted and you cannot decrypt them yourself. They are also on our servers!” The complete ransom note is listed in Appendix A.

Affiliate rules and exceptions

The affiliates need to remain active, or their account will be removed. Any affiliate who is inactive for 10 days without providing a notification upfront, will be locked out of the panel.

Aside from avoiding lurking researchers within the group, this shows the gang’s posture is professionally oriented with a clear hierarchy. This structure is further seen in the rest of the rules, which are clearly spelled out for affiliates, ensuring that the gang’s remains under the radar of the prying eyes of security researchers and law enforcement.

To stay off the radar, CIS countries are excluded, as well as morgues, hospitals, and COVID-19 vaccine related corporations. The specification with regards to hospitals is rather distinct, as a dentist’s office is named as an applicable target, unlike an actual hospital.

This rule ties in with the rule which states that headlines are to be avoided, meaning that vital infrastructure, law enforcement, and other major corporations are to be excluded from attacks, as these garner unwanted attention to the group. If such a case does occur, all traces to the RTM gang are to be removed, and the negotiation is to be held via a separate platform, thus ensuring that those who obtain access to the negotiation chatroom via the sample do not see the ongoing discussion.

Within this private environment, a decryptor is likely provided to ensure the victim can silently recover the encrypted machines and resume their operations normally, although other ransomware cases have proven that even with a decryptor, companies aren’t always likely to resume their day-to-day operations in a blink, as the ransomware’s echo can last weeks or months, if not longer.

Linking any negotiation chat publicly is prohibited and warrants the affiliate to be banned. Even though this is more a statement rather than a fact, all chats are allegedly encrypted. The stolen data is also allegedly stored on a different server, even though the RTM Locker website is only accessible via the TOR network, the actors seem to be cautious.

Their cautious attitude is not without reason, aside from the obvious implications of their illegal activities. Other ransomware gangs have gotten to the point where they caught the attention of the mainstream media, making them a priority for law enforcement and security researchers alike. An example of this is the DarkSide gang in 2021, after the Colonial Pipeline debacle attracted attention across the globe.

RTM Locker malware builds are to be kept private, indicating that the actors want to ensure the builds are not analyzed for as long as possible. As will become clear in the technical analysis, samples contain a self-delete mechanism which is invoked once the victim’s device is encrypted. This further strengthens the stealthy nature of their operations. Affiliates who do leak samples risk a ban, based on the affiliated ID within the locker.

Redistribution of the RTM Locker by outsourcing the job to other self-hired affiliates is also forbidden, thus attempting to limit the amount of people with access to the samples.

Finally, all communication with the RTM gang is to be done via the TOX messenger, and in no other way.

Geographic location

Per the RTM gang’s updates, there was an internal conflict due to the ongoing war in Ukraine, which ultimately lead to data leakage. The screenshot below shows their update.

The screenshot reads: “In connection with the current situation between Russia and Ukraine, there was an incident due to the fault of one of the participants about the drain of one of our servers, work is underway to transfer and restore data. The bleeds of the new software will be made for some time by several of our experienced negotiators. We apologize for the inconvenience!”

Based on this, one can speculate that there are supporters and opponents of said war within the RTM gang, making it likely that one or more of the group’s members reside in Russia, whereas other members who oppose the war are likely located in different geographical areas. This is further supported by the avoidance of CIS countries when the gang’s affiliates look for victims.

Technical analysis

Even though the ransomware is not obfuscated, it does not contain symbols. The renamed functions and variables within the analysis are given during the analysis. The ransomware follows a clear execution flow, as shown below.

In the next sections, the locker will be examined in detail, along with code excerpts. The table below provides the hashes of the analyzed sample.

Elevated privileges

To cripple the targeted system more effectively, the RTM Locker encrypts as much files as possible. To ensure the required permissions are acquired, the ransomware checks if it has administrative permissions on the built-in system domain, which provides unrestricted access to the device.

RTM Locker does not utilize an exploit to obtain these permissions, it simply launches itself with the required permissions, resulting in a User Account Control dialog popping up. If the victim approves the execution, the new process instance is launched with the requested administrative permissions, and the current locker instance shuts itself down. If the victim rejects the prompt, the locker continuously requests it, until the permissions are granted. The image below shows this process in pseudo code.

Debugging console

Within the locker’s main function, right after the elevated privilege check completed, the command-line arguments are checked. If there is a sole argument which equals “-debug”, the console output is set. This allows the locker to print debug data, calls to do so are encountered throughout the ransomware’s code. The screenshot below shows the check of the command-line argument, as well as the call to the function which sets the console output.

Environmental awareness

The locker’s next step is to ensure it can maximize its impact by terminating processes which can either block a file (such as Office applications), or which are used during the analysis of malicious files, such as x64dbg. The pseudo code below shows the iteration over all the running processes, and the stopping of selected processes.

As soon as the currently iterated process’ name is within the process list within the locker, the process is terminated with exit code 9. Note that the previously acquired administrative privileges on the system aid the locker’s attempt to close all processes which it considers detrimental to its existence.

The following processes are checked for by the locker: sql.exe, oracle.exe, ocssd.exe, dbsnmp.exe, synctime.exe, agntsvc.exe, isqlplussvc.exe, xfssvccon.exe, mydesktopservice.exe, ocautoupds.exe, encsvc.exe, firefox.exe, tbirdconfig.exe, mydesktopqos.exe, ocomm.exe, dbeng50.exe, sqbcoreservice.exe, excel.exe, infopath.exe, msaccess.exe, mspub.exe, onenote.exe, outlook.exe, powerpnt.exe, steam.exe, thebat.exe, thunderbird.exe, visio.exe, winword.exe, wordpad.exe, and notepad.exe

The locker’s next step is to stop all services present within an embedded list. The pseudo code below shows the iteration over and stopping of selected services.

The targeted services are responsible for anti-virus protection and back-ups, as can be seen here: vss, sql, svc$, memtas, mepocs, sophos, veeam, backup, GxVss, GxBlr, GxFWD, GxCVD, GxCIMgr, DefWatch, ccEvtMgr, ccSetMgr, SavRoam, RTVscan, QBFCService, QBIDPService, Intuit.QuickBooks.FCS, QBCFMonitorService, YooBackup, YooIT, zhudongfangyu, stc_raw_agent, VSNAPVSS, VeeamTransportSvc, VeeamDeploymentService, VeeamNFSSvc, PDVFSService, BackupExecVSSProvider, BackupExecAgentAccelerator, BackupExecAgentBrowser, BackupExecDiveciMediaService, BackupExecJobEngine, BackupExecManagementService, BackupExecRPCService, ArcSch2Svc, AcronisAgent, CASAD2DWebSvc, and CAARCUpdateSvc.

Another check which the locker performs, is the CPU’s capabilities to perform SSE2 related operations, which are, later on, used for cryptographic operations.

Setting the stage

Prior to starting the encryption process, the locker empties the recycle bin (without asking for confirmation, showing the progress on-screen, or playing the completion sound), and it deletes the shadow copies. This ensures that victims cannot restore files directly from the recycle bin or via the shadow copies after the locker has taken the device hostage. The image below shows the related pseudocode.

Next, the machine’s volumes are iterated, where non-used volume letters are assigned a mount point for unmounted partitions on all volumes. A maximum of 26 drive letters are used within the locker, as can be seen in the pseudo code below. Note that the order of the drives is based on the QWERTY keyboard lay-out. This might indicate the locker creator(s) used such a lay-out during the development.

The iteration happens by looping over the drives array, where each drive’s type is checked. If the drive type indicates that no volume is mounted for the given drive, it is stored in a different array, named “unmountedDrives” in the pseudo code below.

The machine’s first volume is then iterated, and partitions on it are mounted to unused drives if possible. Note that the array’s iteration starts at the end, meaning that the first new drive to be created, is “M:\”.

The reason to mount all partitions on the attached volumes is to increase the number of files which can be encrypted by the locker, as all attached volumes are iterated upon, or until all drive letters are in use.

File encryption

Once all partitions are mounted, the iteration over all drives begins. This time with the intent to encrypt the encountered files, barring some exclusions. The pseudo code below shows the differentiation between remote and local drive types, after which the folder parsing function is called.

A folder separating backslash and a wildcard are appended to the provided path, after which the first file at the given location is searched for. If there is no such path, the function returns. If there is, a check is performed if the excluded folder list contains the current name. If this is the case, a check is performed if the given file is a file or a folder. When the path refers to a folder, the function is called recursively, thus including subfolders. If the path refers to a file, which is not equal to the name of the ransom note, nor has an extension that is 65 characters long, the file specific encryption function is called. The pseudocode below provides an overview of the process that is described above.

The excluded names are the following: windows, appdata, application data, boot, google, mozilla, program files, program files (x86), programdata, system volume information, tor browser, windows.old, intel, msocache, perflogs, x64dbg, public, all users, default, ., and ..

The encrypted file gets a random 64-character extension based on 32 randomly generated bytes, where each byte is displayed using two characters. The previously mentioned 65-character extension check is due to the return value of PathFindExtensionW, which returns a pointer to the extension’s dot, thus adding a character to the extension length.

The random data is generated using the RtlGenRandom function, which is an undescribed import which is to be manually resolved from advapi32 under the name of “SystemFunction036”. The pseudo code for the random data generation is given below.

The encryption of the files on the victim’s machine happens in a multi-threaded fashion, maximizing the impact by minimizing the time which is required to encrypt all files on the disk. There is, however, more to the multi-threading within this locker than simply iterating and encrypting files in multiple threads.

The locker uses Input/Output Completion Ports (abbreviated as IOCP), allowing multiple threads to work with the same file at the same time, based on signals that are sent between the threads. In this case, different types of threads are used for the encryption and the IOCP, as can be seen in the pseudo code below where the two types of threads are created. Note that this code is called earlier on but is only discussed now as it is relevant from here on out.

The system information structure is filled by an earlier call to GetSystemInfo. The number of processors is used multiple times. First, to create IOCP threads, which number equals to twice the amount of the number of processors in the system information structure. It is then used to create encryption threads, one for each processor in the structure. Additionally, the number of processors is stored in a global variable, which is used to, atomically, keep track of the amount running encryption threads.

The encryption thread opens a file with direct access, as it excludes buffers. The “FILE_FLAG_OVERLAPPED” flag is required to use a file with IOCP. A check is then performed if the given file’s size is 512 byte or more. If the file size is less, it is not encrypted. The custom structure which is used in the communication between the encryption and IOCP thread pair is then set up, where the action key defines the action which should be taken. The used actions within the locker are given below.

The above-described actions are shown in the pseudo code below.

The original name, as well as the new name, is stored in the custom structure, after which an IOCP is created, which is then posted, thus notifying the paired IOCP thread.

Within the IOCP thread, multiple actions can be performed, based upon any of the aforementioned action key values. Each action code sets the next code, thus moving through the process step-by-step. The read action is shown in the pseudo code below.

The next step is to encrypt and write the file’s data to the file.

The last action key is moving the file within the same folder, essentially changing the file’s extension.

The final encryption thread will change the wallpaper of the machine, which is yet another sign to the victim that the device is compromised, along with the ransom notes and the encrypted files. Note the atomic check if the local drive letter is below “Z”, which is the highest drive value that is possible. The starting value of 0x40 is one less than the capital letter “A”, the lowest possible drive. The pseudo code below shows the wallpaper change.

The new wallpaper is shown below.

Waiting for the encryption to finish

Once all threads are running, the main function continues, as it calls a sleep loop. This allows the threads to switch and continue their execution, until all are finished as they decrement the variable’s value.

Clear the logs

The one-but-last action the locker performs wipes the System, Application, and Security logs from the machine. The wiping allows a back-up file to be specified, which is left void on purpose, ensuring the log is completely wiped.

Self destruction

At last, the locker executes a shell command, which executes “cmd.exe /c PING -n 5 127.0.0.1 > NUL && del “[path]””. The path variable is enclosed between quotes to ensure it is parsed as a single command-line argument if there is a space somewhere in the path. The path is equal to the complete path to the locker’s executable. Once the shell command has been issued, the locker shuts down. The ping command allows the locker’s process to shut down, making the delete command successful thereafter. Otherwise, the locker could still be running, and thus in use, meaning the deletion would fail. The pseudo code for the described actions is given below.

Detection coverage

Information about this group can be found in Insights, an excerpt of which is shown below. Updated indicators of compromise, as well as new changes and observations, will be added to the profile within Insights.

Conclusion

The multi-threading nature of this locker ensures a swift encryption of all logical volumes attached to the machine, until all 26 drive letters are in use. It is, however, unlikely that this locker is to be distributed via an automated campaign given how it only properly works once it’s obtained the required administrative privileges. Since most corporate environments do not provide these permissions to most users, it is more likely that the locker is to be executed once a network is within an actor’s control already. Actors can leverage phishing attacks, malicious spam (commonly known as malspam), vulnerable publicly exposed systems, or bought access to get control of the targeted systems. Also take note of the group’s aim to operate without garnering attention, which ties into the lack of direct spreading via malspam, as it would shine a light on the group’s actions.

Based on the group’s modus operandi, it looks like the group is opportunity based, rather than targeting a single industry, nor very specific corporations. The rules define a clear scope as to what is a potential target, allowing affiliates to operate as they see fit. The gang’s primary objective seems to make money, rather than a political motive.

Appendix A – RTM Locker’s Ransom Note

The complete ransom note which is dropped by the locker is given below. The “[VICTIM-ID]” within the note is equal to the victim ID of the given sample.

Appendix B – MITRE ATT&CK techniques

The MITRE ATT&CK techniques which are relevant to the locker.

This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. Trellix conducts research in accordance with its Vulnerability Reasonable Disclosure Policy. Any attempt to recreate part or all of the activities described is solely at the user’s risk, and neither Trellix nor its affiliates will bear any responsibility or liability.