Introduction
Just before closing off the year 2022, a new ransomware called CatB appeared on VirusTotal. Compared to other ransomware, this new malware family gets shipped with unique characteristics that make this recent market joiner interesting: Before the ransomware is executed, its loader component performs basic evasion checks to ensure the sample is not running in an analysis environment, such as a sandbox.
Once all checks are passed, the payload containing the ransomware is executed in the context of a trusted Windows service via a DLL Side-Loading attack. CatB then searches for user-specific files based on a list of extensions that can be encrypted. In contrast to behavior shown by other ransomware families, instead of dropping the ransom note in separate files on various different locations, CatB prepends it to each of the encrypted files. According to the ransom notes content, the files are encrypted with RSA and a key size of 2048.
Even though we haven’t observed different samples at the time of writing, within this Spotlight, we are taking a brief look at one ransomware sample to highlight the evasion techniques as well as the DLL Side-Loading attack.
Analysis of CatB Ransomware Loader
While the full delivery chain of CatB is currently unknown, the infection mechanism itself can be observed within VMRay Platform: A malicious DLL, referred to as the load within this Spotlight, is executed on a system and starts with basic evasion checks to hide its behavior from analysis environments. In total, there are three different techniques implemented.
The first one checks the number of CPU cores that are present on the system by calling the Windows API GetSystemInfo to retrieve the respective counter. The loader expects to see at least two cores available to continue its execution (Figure 1). While many sandboxes only feature single-core VMs to lower the required resources for running parallel analyses, modern desktop computers or notebooks typically have multiple CPU cores.
VMRay Platform provides the option to easily adjust the number of CPU cores directly within the system configuration (Figure 2). The modification is transparent to major parts of the VM as it only fakes the number of CPU cores for processes that are relevant to the analysis. This ensures short reaction times on changes observed in threat trends, as well as keep maintaining short analysis times, as increasing the number of faked CPU cores does not have a negative performance impact in the case of parallel running analyses.
The second performed anti-VM technique checks for the amount of main memory that is available to the system. This is utilized via calling the Windows API GlobalMemoryStatusEx, which returns a struct with various information about physical and virtual memory.
The loader extracts the value of the total available physical memory to verify that the system has at least 2048MB of memory installed (Figure 3). Desktop computers rarely have less, but many sandboxes do to save resources for the execution of parallel analyses.
Besides faking CPU cores, VMRay Platform also provides a configuration option to adjust the amount of memory that is seen by relevant processes. Similar to faking the number of CPU cores, increasing the size of available main memory does not have a negative performance impact on analyses as this is also transparent to major parts of the VM.
For the third and final check, the sample extracts the size of the hard drive as most analysis environments provide only very limited space, which is not typical for modern computers. As for all prior checks, there is again a Windows API function called DeviceIoControl available that the loader uses to receive specifications for the drive.
By using IOCTL_DISK_GET_DRIVE_GEOMETRY as a parameter for the API call, the system returns the geometry data of the physical disk, which can be used to calculate the total size. The loader continues execution only if the drive has a size of at least 50GB (Figure 5). The analysis VMs used by VMRay have disk sizes that are large enough not to get caught by this analysis environment check.
The CatB ransomware sample discussed in this Spotlight uses a DLL Side-Loading vulnerability in a trusted Windows service called MSDTC (Microsoft Distributed Transaction Coordinator), which has been known for more than 2 years. DLL Side-Loading is a well-known and easy-to-find exploitation technique that can be used by attackers to achieve code execution in the context of a trusted process as the vulnerable program tries to load one or multiple DLLs via their names from specified locations.
Once all anti-VM checks have been passed, the loader drops a file called “oci.dll” into the Windows System32 directory, which is later on mistakenly loaded by MSDTC (Figure 6).
During the next step, the loader modifies the MSDTC service to let it start automatically to achieve persistence, even though this might not be important for a ransomware.
To reach an execution with higher permissions on the system, the loader updates the user which is used to run the service to LocalSystem, which is an administrative user (Figure 7). To finally trigger the execution of CatB ransomware, the loader starts the service, which tries to load the previously dropped DLL due to its DLL Side-Loading vulnerability.
Dropping a DLL into a trusted Windows system-based location as well as Side-Loading it into a process is detected via VTIs (VMRay Threat Identifiers) and helps to detect the maliciousness of the loader used by the ransomware (Figure 8).
Analysis of CatB Ransomware
Finally, the actual payload containing CatB ransomware is executed in the context of the trusted Windows service MSDTC. An interesting observation here is that the ransomware performs exactly the same anti-VM checks, as done by the loader (Figure 9).
Once CatB passes all the checks for the second time, the ransomware tries to find interesting files to encrypt to make them unavailable to the user. VMRay reveals the behavior of searching for files across multiple drives in its function log (Figure 10).
Our analysis shows that the ransomware searches for files that are related to users and maintains two lists for this purpose. One list with the extensions of file types that will be encrypted (Figure 11, left), and another, containing extensions that are excluded and, therefore, will not be modified (Figure 11, right).
Based on the exclusion list, we can assume that the malware developer does not want to damage the system or does not see any advantage in encrypting system files, installers, or disk images. Ransomware operators typically do not want to destroy, they want to hold files hostage, and the operating system still needs to work for the victim to see the ransom note.
However, even though the ransomware maintains a list of file extensions used to search for files that will be encrypted, it will also encrypt files with extensions that are not part of that list.
While searching for files, CatB checks each file’s size; if it is below 52MB and part of the extensions listed in Figure 11 (left) the complete file is encrypted. Otherwise, if the size of the file exceeds the limit of 52MB or does not have a proper extension and is not part of the list in Figure 11 (right), only the first 20480 bytes are encrypted (Figure 12).
We can assume that the ransomware developer limits the file size due to the amount of performance that is needed for encrypting large files. If the encrypted process takes too long, systems can be switched off before all of their files have been encrypted.
Compared to other ransomware families, CatB prepends the ransom note to each encrypted file without modifying its extension, instead of dropping a separate file and renaming the encrypted one. Victims might not notice what happened to their files as common applications associated with the file type can fail to open them if the header, bytes used to recognize them, are gone. Looking at the content of an encrypted file reveals the ransom note (Figure 13).
VMRay’s VTIs are capable of detecting the modification of multiple user files within the analysis environment, even though the malicious behavior was performed in the context of a trusted system service (Figure 14).
In addition, the VMRay Platform comes with a continuously updated set of YARA rules.
Conclusion
Malware families like CatB underline the importance of using an evasion-resistant sandbox. This ensures that samples with anti-VM checks are analyzed properly and reveal their malicious behavior. VMRay provides extensive and easy-to-configure options to bypass a variety of different anti-VM checks.
VMRay’s analysis report, as well as the function logging capability, assists malware analysts and researchers in quickly diving deep into the ransomware’s behavior and having a detailed look into its capabilities.
References
https://minerva-labs.com/blog/new-catb-ransomware-employs-2-year-old-dll-hijacking-technique-to-evade-detection
https://www.fortinet.com/blog/threat-research/ransomware-roundup-catb-ransomware
IOCs
Hashes:
Sample (Loader):
3661ff2a050ad47fdc451aed18b88444646bb3eb6387b07f4e47d0306aac6642
Hashes
Dropped Payload (Ransomware)
35a273df61f4506cdb286ecc40415efaa5797379b16d44c240e3ca44714f945b
Ransom Note:
Bitcoin Wallet Address
bc1qakuel0s4nyge9rxjylsqdxnn9nvyhc2z6k27gz
Ransom Note:
Email Contact
catB9991@protonmail.com
Patrick Staubmann
Threat Researcher
