Early this year, there was a major distribution of Clop ransomware, mainly targeting Korean government agencies. Clop ransomware distributed using a hack tool called ‘Ammyy,’ is unlike common ransomware and attacks after a period of latency. Since the end of May 2019, Clop ransomware has emerged again with the sudden increase in the distribution of Ammyy hack tool.
While analyzing Ammyy, ASEC found a malware utilizing the SDB (Shim Database) file, created during the installation and uninstallation of Ammyy. Let’s take a closer look at the operation, flow, and features of the SDB-based malware, based on the analysis made by ASEC (AhnLab Security Emergency-response Center).
1. Distribution flow of Clop ransomware via Ammyy downloader
Let’s begin with the distribution flow of Clop ransomware using the Ammyy hacking tool. Ammyy hacking tool uses social engineering and distributes ransomware via email. As shown in [Fig 2-1], the ransomware downloads the Ammyy downloaders, and installs the malicious backdoor as a result.
As shown in [Fig 2-1] flowchart, processes that lead up to Ammyy installation are explicit. However, how the installation of ransomware is carried out is still under study. The installation and uninstallation of Ammyy backdoor has a short cycle period. Among the files that are found to have been created during this period, ASEC found and analyzed the SDB-based malware, which is quite rare in Korea.
2. The operation, flow, and features of the SDB-based malware
Let’s take a look at the operation flow of the SDB-based malware. Ammyy backdoor uses an SDB(Shim Database) file to generate malware to install other backdoors on the system in a way that the users can hardly notice. The created malware include injectors, commonly named as ‘loader32.exe,’ and malware, such as ‘SDB_msf_32_crypted.dll,’ which installs the malicious SDB file.
The SDB file is a Windows mechanism to support backward compatibility, which accepts various types of ‘compatibility fixes.’ When an application calls a DLL file, it uses the codes in the SDB file to maintain compatibility.
[Fig 2-2] shows the installation process of a backdoor utilizing the SDB file.
[Table 2-1] shows an overview of malware flow utilizing the SDB file.
This way, the SDB-based malware writes the encoded backdoor malware in the registry, as shown in [Fig2-3]. The encoded backdoor is registered to the registry path ‘HKLM\SOFTWARE\ Microsoft\[randum string].’
Then, it generates a malicious SDB file and registers it using the ‘sdbinst.exe’ utility software. The registered SDB file is located at ‘C:\Windows\AppPatch\Custom.’
Observation on the generated SDB file structure reveals that the SDB file is targeting a ‘services.exe’ process, as shown in [Fig 2-4]. The ‘services.exe’ process is capable of overwriting a specific offset with its shellcode, which is not an official feature supported by ‘Shim,’ but is used nonetheless by the attacker to patch a specific address within the memory.
The ScRegisterTCPEndpoint() function is one of the internal features of ‘services.exe.’ If this function is called while ‘services.exe’ is running, the shellcode is executed instead. The shellcode decodes the encoded PE file that has already been registered and launches it on the memory.
[Fig 2-5] shows the offset address to be patched by ‘services.exe’ in the memory, and [Fig 2-6] shows the ‘ScRegisterTCPEndpoint()’ function used during this process.
The malware defines the offset address while generating the SDB file because the offset address of the ‘ScRegisterTCPEndpoint()’ function may vary depending on the version of the operating system. In the routine, ‘services.exe’ is read onto the memory from the Windows system path, as shown in [Fig 2-7].
Then, the code seeks a hard-coded string, ‘DisableRPCOverTCP,’ which is specific to the ‘ScRegisterTCPEndpoint()’ function. As shown in [Fig 2-8], this string is located at the end of the ‘ScRegisterTCPEndpoint()’ function. Then, from this location, the code searches upwards to initiate the start routine of the function.
Shim is applied when a process is generated. Because the code is targeting ‘services.exe,’ a normal system process, ‘services.exe’ will become the agent of the malicious behavior for the SDB file after the system reboot.
The malicious backdoor learns the necessary information of the infected system and sends it to a C&C server, then runs commands after a connection to the server is established. These commands include features such as searching, generating, and deleting files. Besides this, the backdoor can carry out basic functions, such as running CMD commands through a pipe and sending the result to the C&C server.
The backdoor also searches for related files. First, it checks the ‘ip.txt’ file in the ‘system32’ folder (where ‘services.exe’ is located) or the system root path (C:\). In the file, additional C&C server addresses are assumed to be added. If such addresses do not exist in the file, the backdoor will attempt to access the basic C&C server address that is hard-coded.
Prior to sending the basic information to the server, the backdoor searches for ‘BotInfo.txt’ in the ‘system 32’ folder. This file is assumed to contain information about the infected system. If such file does not exist, it accesses http://ip-api.com/json and obtains various information, such as the IP address, city, country, and Internet Service Provider, then acquires additional system information, such as the operating system version, PID, and user name before sending it to the C&C server.
[Fig 2-9] shows the routine to acquire information about the infected system
Therefore, other than removing the Ammyy and injector codes, disinfection must be performed for the installed SDB file if a malicious SDB file has already been installed by Ammyy backdoor. Otherwise, the backdoor will continue to run within the ‘services.exe’ process. Users can hardly recognize the infection because a normal system process, ‘services. exe,’ has become an agent for the backdoor’s malicious behavior.
Such attacks utilizing the malicious SDB file are similar to the previous attacks made by FIN7 attack group, also known as the Carbanak attack group. (Reference URL: https://www.fireeye.com/blog/threat-research/2017/05/fin7-shim-databases-persistence.html)
3. Malicious factors based on the SDB file structure
To fight against such attacks utilizing the SDB file, ASEC invented a diagnostics process to detect malicious SDB files. As it was stated earlier, the SDB file is a database file designed to support the backward compatibility of software applications. It operates when the function operation changes, calling API functions and converting the codes given to it. The malware that we found this time manipulates the operation of ‘services.exe’ to launch the SDB file with a shellcode when ‘ScRegisterTCPEndpoint()’ is called.
Then the question is, how is the SDB file composed, and how did the shellcode operate when the ‘services.exe’ process is loaded? The previous example of [Fig 2-4] explains how a significant amount of data is located in the SDB file.
First, the SDB file is composed of a header (0xC sized) and a repeated pair of tags and data following it. The data that follows may vary depending on the tag, and the ‘tag and data’ pair is listed in that exact order. Therefore, to understand the complete structure, the data must be read from the first offset although the preceding tag may predict the following data. As shown in [Table 2-2], the 4 upper bytes determine the tag type.
After the header (0xC sized), a 4-byte tag and matching data are listed. For example, in the case of the ‘0x7007’ tag in [Table 2-2], the data for list of items can be predicted to follow the first part, ‘0x7.’ The ‘0x7007’ tag is used to list information about ‘TAG-EXE.’
[Fig 2-10] shows the structure of the SDB file used for the malware based on this information.
The highlighted section in red is the 0xC sized header, where the version information takes the upper 0x8 bytes, and the succeeding data, ‘0x73646266,’ is for a string, ‘sdbf,’ which stands for SDB file. The subsequent tag, ‘0x7802,’ stands for TAG_INDEXS, which indicates that the index list data of the file will follow.
The next section, ‘0x26,’ indicates that the ‘0x26’ sized data will be contained. This way, we can figure out that TAG_DATABASE and TAG_STRINGTABLE information will follow afterward, and that the SDB file is composed of four main sections: HEADER, INDEXS, DATABASE, and STRINGTABLE.
TAG_DATABASE section provides information including shellcode and SDB file execution target process. [Fig 2-11] shows the data listed within the TAG_DATABASE section.
There is a tag, ‘0x7005,’ in the database, which stands for TAG_PATCH. This means that patch data will follow this tag. In the HEX table, ‘0x2EE’ following the ‘0x7005’ tag indicates the size of the patch data that will follow. Information on shellcode is also included in this data. In the offset after ‘0x2EE,’ there is another tag, ‘0x7008,’ which stands for TAG_MACHING_FILE. This tag indicates that the following data includes information about the target process. Tag ‘0x6001’ represents the TAG_NAME, which is the names of these tags, thereby it can be assumed that the following ‘0x5E’ will be data related to the target process information.
Tags are generally followed by the ‘data-size’ or ‘actual data.’ However, the values in the string table must be referenced to identify tags starting with ‘0x6,’ as shown by the SDB file tag types in [Table 2-2].
As was explained earlier in [Fig 2-11], we figured out that ‘0x5E’ indicated information about the target process name, and [Fig 2-12] indicates that the target process name, ‘service exe,’ will be located at a spot that is ‘0x5E’ away from the start of the string table. Now, we understand that a patch on the ‘services.exe’ process is made using this structure, and that the patched data will be the shellcode within the TAG-PATCH section.
This way, SDB file data is identified and operated based on the tags. After figuring out the structure of such SDB files, ASEC made a generic detection available for the malicious SDB files to prevent infection before an SDB file operates in the ‘sdbinst.exe’ process.
The AhnLab’s V3 product aliases related to the Ammyy hack tool and the malicious SDB files are as follows.
<V3 Product Aliases>
– FlawedAmmyy RAT: Backdoor/Win32.Flawedammyy
– SDB file installation code: Trojan/Win32.Injector
– Malicious SDB file: BinImage/Sdb.Gen, BinImage/Malsdb.S1, BimImage/Malsdb.S2
– Backdoor code: Backdoor/Win32.Agent
ASEC always keeps its eyes on the distribution processes for various malware, including Clop ransomware. ASEC endlessly analyzes newly found or rare malware to develop preventive measures and have it reflected on AhnLab products.
Categories:Malware Information