Analysis of CPL malware, part 1
CPL malware is a special type of malware that is distributed as dynamic DLL libraries that act as extensions of Windows Control Panel elements. This type of malware is especially popular with attackers in Brazil and is used to distribute the Win32 / TrojanDownloader.Banload daunloader and the Win32 / Spy.Banker.T banker .
Each CPL file is a dynamically linked library. The DLL itself, in its model, stores the executable code and data that can be used by other executable PE files through the DLL export mechanism. However, the library cannot be executed directly by the user, since it can only be used through the executable file and the process created for it.
Dynamic CPL libraries can be executed through a call to the executable file control.exe, which is the Windows Control Panel. To do this, the DLL must meet special requirements, one of which is the presence of an export function named CPlApplet . Below is its prototype on Delphi.
')
Fig. The prototype of the CPlApplet function on Delphi.
It can be seen that the function accepts four arguments as input: hwndCPl , which is the handle of the main application window; uMsg is a message identifier that sends the DLL an executable file of the control panel; lParam1 and lParam2 are arguments that are specific to a particular message. Messages sent by the executable file of the control panel are the main mechanism for working with the CPL library.
Fig. The basic structure of the function CPlApplet .
Dynamic libraries of simple applets of the control panel are located in the% WINDIR% \ System32 directory. Attackers use a different location to store their malicious CPL files, which will also be executed using the Windows Control Panel (control.exe). Usually authors place malicious code in that section of the CPlApplet function, which is responsible for processing the CPL_DBLCLK message.
To distribute this type of malware, attackers use phishing emails. The user may be offered to read a fake document, opening which he is infected with malware. The following e-mail topics are used by attackers to euthanize user vigilance:
The figure below shows a typical attack pattern for users using CPL malware in Brazil. The chain of compromise of a user begins with the attackers spreading malicious files through e-mail messages. Such a message may include an attachment, or contain in the text a hyperlink to a file located on a remote server. As a rule, the malicious DLL itself is packaged in a ZIP archive (email attachment).
Fig. Attack life cycle using CPL malware.
Above, we mentioned the typical structure of the main function of CPlApplet , the screenshot below shows the similar function of the malware in the disassembler. It is important to mention that the majority of samples of such malware analyzed by us are written in Delphi, with the exception of only a small number of samples with their own packers, which are written in Microsoft Visual C.
Fig. The CPlApplet function of one of the malware samples.
This function has a similar structure with the general form indicated above. It can be seen that it contains a large number of conditions that indicate the processing of various types of messages. The screenshot shows the various code fragments responsible for processing the four messages.
We mentioned that CPlApplet is called in various situations and is the main function that implements the logic of the CPL library in memory. The scheme of execution of these functions and their connection with the Windows system libraries is shown below.
Fig. Call flow of CPlApplet functions.
The figure shows that the first function of the CPL library to be called is DllMain . This is the entry point to the library, which performs the initial initialization of its data and structures. The DllMain function is called by the LoadLibrary API in the shell32.dll library after the library is loaded into memory. It would be logical to assume that all the logic of the malicious program can be immediately placed in this function, since it runs before the CPlApplet is called . This question we will consider below.
After the DLL is initialized, i.e., executing its DllMain function, the CPlApplet function is sequentially called with various messages. The order of the function call with the corresponding messages is indicated by numbers from 1 to 7. The CPL_DBLCLK message is the main one, since the main code of the malicious program is located there. In the case of this sample, there is a payload (payload), to which control is transferred when processing this type of message.
The payload code of the CPL malware samples we observed has a specific structure and can be broken down into the following parts:
Fig. A fragment of malicious code payload.
As can be seen in the call graph of the functions of the payload, its execution is quite linear, the figure shows a fragment of the initialization function. At the very beginning of this function, the stack is initialized with zero values in the loop, then the function execution flow falls asleep for 30 seconds, after which it saves the path to the% APPDATA% directory in the memory buffer. Note that the patterns we observed in the initialization function performed other actions, for example, did not call the Sleep function, received a path to other system directories. However, the above scheme is quite common for many samples. Below is a snippet of code in which URLs are constructed and files are loaded.
Fig. Malware code snippet that is responsible for downloading files from a remote C & C server.
The screenshot above shows that for each encrypted string, the decipher_str decryption function is called. Then, based on these lines, the final URL is generated, from which the executable file will be downloaded. It can be seen that the download file is masked as an image file with the extension .png. It will be saved to the location% APPDATA% \ Desk.exe. The download_URL function directly downloads a file using standard Windows call APIs.
Note that not all CPL malware samples detected by us use encrypted strings. We often come across samples in which the lines are in clear text. In such samples, the decipher_str decryption function, which we mentioned above, is missing.
Fig. An example of a malicious CPL malware file with plaintext strings.
The last piece of payload code is responsible for executing files downloaded from a remote server using the standard ShellExecute API function. Our analysis showed that the actions performed by CPL malware are simple and effective enough to compromise the user's system. The malicious program is not installed into the system, but only specializes in downloading and installing other malicious programs into the system, that is, it acts as a downloader or downloader. Thus, the bootloader itself in the system is difficult to detect because it leaves no traces there, for example, registry keys or other indicators.
Fig. The code snippet that is responsible for the execution of the downloaded file.
Many of the malware files that we analyzed are variants of the Win32 / TrojanDownloader.Banload malware family and specialize in installing banking trojans into the system.
Most samples of CPL malware use string decryption mechanisms based on SUB and XOR operations. The decryption key is hardwired in the code of the function itself, which is responsible for decoding. The malicious program uses the so-called. “Extended Backus – Naur Form (EBNF) for storing encrypted strings and a key.
In the form of a regular expression, it looks like this:
It can be seen that the encrypted strings (cipher_string) consist of at least two pairs of hexadecimal characters (in upper case), and the number of characters will always be even. The key consists of at least one alphanumeric character, also in upper case. We also observed in the keys such characters as "@" and "!", Which we did not include in the regular expression above for simplicity.
The following figure shows an example of the decryption algorithm. At the first stage, the characters of the encrypted string will be encrypted twice, since each pair is considered as a hexadecimal byte value. The same can be said about the key, the sequence of ASCII characters is treated as a hexadecimal byte stream.
Fig. The first stage of the decryption algorithm.
Fig. The second stage of the decryption algorithm.
At the first stage of the algorithm, it is clear that in the decryption operation the first pair of characters of the encrypted string is skipped; it will be used in the second stage as a subtracted value from the result obtained at the first stage of the algorithm. Already at this stage, the result of the subtraction is considered as an ASCII character. In our example, the ASCII code represents the letter “h”. Note that in the case when the result of the subtraction operation gives a negative number, the value 0xFF is added to the most subtractive before the subtraction operation occurs. The figure below shows how the decryption operation takes place for the first seven characters of the encrypted string.
Fig. Decrypt the first seven characters of the encrypted string of the CPL malware.
The screenshot below shows the main part of the decryption function in IDA Pro. The function reads the first two characters of the encrypted string from memory, stores them and starts the decryption process. In the loop, the function takes the next two characters of the string and a pair of key characters, performing an XOR operation. Then, the subtraction (SUB) operation is performed on the obtained value (the first stage), and the value of the first pair of characters that were stored in the memory at the very beginning of the function is subtracted from it. The resulting value is copied to a memory buffer storing the decrypted text. At the last step, the pair of symbols used in the XOR operation is copied, that is, they become a subtraction value for the SUB operation at the next iteration. In the case when the decryption characters still remain, and all the key characters have already been used up, the key characters are taken from the very beginning.
Fig. Line decryption function.
Each CPL file is a dynamically linked library. The DLL itself, in its model, stores the executable code and data that can be used by other executable PE files through the DLL export mechanism. However, the library cannot be executed directly by the user, since it can only be used through the executable file and the process created for it.
Dynamic CPL libraries can be executed through a call to the executable file control.exe, which is the Windows Control Panel. To do this, the DLL must meet special requirements, one of which is the presence of an export function named CPlApplet . Below is its prototype on Delphi.
')
Fig. The prototype of the CPlApplet function on Delphi.
It can be seen that the function accepts four arguments as input: hwndCPl , which is the handle of the main application window; uMsg is a message identifier that sends the DLL an executable file of the control panel; lParam1 and lParam2 are arguments that are specific to a particular message. Messages sent by the executable file of the control panel are the main mechanism for working with the CPL library.
Fig. The basic structure of the function CPlApplet .
Dynamic libraries of simple applets of the control panel are located in the% WINDIR% \ System32 directory. Attackers use a different location to store their malicious CPL files, which will also be executed using the Windows Control Panel (control.exe). Usually authors place malicious code in that section of the CPlApplet function, which is responsible for processing the CPL_DBLCLK message.
To distribute this type of malware, attackers use phishing emails. The user may be offered to read a fake document, opening which he is infected with malware. The following e-mail topics are used by attackers to euthanize user vigilance:
- a document with an invoice or receipt for payment of something;
- a document with information about the status of a bank account or other banking information;
- a document with information on electronic methods of paying bills that are popular in Brazil;
- A document with various images and photographs that are relevant to the user.
The figure below shows a typical attack pattern for users using CPL malware in Brazil. The chain of compromise of a user begins with the attackers spreading malicious files through e-mail messages. Such a message may include an attachment, or contain in the text a hyperlink to a file located on a remote server. As a rule, the malicious DLL itself is packaged in a ZIP archive (email attachment).
Fig. Attack life cycle using CPL malware.
Above, we mentioned the typical structure of the main function of CPlApplet , the screenshot below shows the similar function of the malware in the disassembler. It is important to mention that the majority of samples of such malware analyzed by us are written in Delphi, with the exception of only a small number of samples with their own packers, which are written in Microsoft Visual C.
Fig. The CPlApplet function of one of the malware samples.
This function has a similar structure with the general form indicated above. It can be seen that it contains a large number of conditions that indicate the processing of various types of messages. The screenshot shows the various code fragments responsible for processing the four messages.
We mentioned that CPlApplet is called in various situations and is the main function that implements the logic of the CPL library in memory. The scheme of execution of these functions and their connection with the Windows system libraries is shown below.
Fig. Call flow of CPlApplet functions.
The figure shows that the first function of the CPL library to be called is DllMain . This is the entry point to the library, which performs the initial initialization of its data and structures. The DllMain function is called by the LoadLibrary API in the shell32.dll library after the library is loaded into memory. It would be logical to assume that all the logic of the malicious program can be immediately placed in this function, since it runs before the CPlApplet is called . This question we will consider below.
After the DLL is initialized, i.e., executing its DllMain function, the CPlApplet function is sequentially called with various messages. The order of the function call with the corresponding messages is indicated by numbers from 1 to 7. The CPL_DBLCLK message is the main one, since the main code of the malicious program is located there. In the case of this sample, there is a payload (payload), to which control is transferred when processing this type of message.
The payload code of the CPL malware samples we observed has a specific structure and can be broken down into the following parts:
- initialization;
- building URLs to download malicious content;
- execution of downloaded files.
Fig. A fragment of malicious code payload.
As can be seen in the call graph of the functions of the payload, its execution is quite linear, the figure shows a fragment of the initialization function. At the very beginning of this function, the stack is initialized with zero values in the loop, then the function execution flow falls asleep for 30 seconds, after which it saves the path to the% APPDATA% directory in the memory buffer. Note that the patterns we observed in the initialization function performed other actions, for example, did not call the Sleep function, received a path to other system directories. However, the above scheme is quite common for many samples. Below is a snippet of code in which URLs are constructed and files are loaded.
Fig. Malware code snippet that is responsible for downloading files from a remote C & C server.
The screenshot above shows that for each encrypted string, the decipher_str decryption function is called. Then, based on these lines, the final URL is generated, from which the executable file will be downloaded. It can be seen that the download file is masked as an image file with the extension .png. It will be saved to the location% APPDATA% \ Desk.exe. The download_URL function directly downloads a file using standard Windows call APIs.
Note that not all CPL malware samples detected by us use encrypted strings. We often come across samples in which the lines are in clear text. In such samples, the decipher_str decryption function, which we mentioned above, is missing.
Fig. An example of a malicious CPL malware file with plaintext strings.
The last piece of payload code is responsible for executing files downloaded from a remote server using the standard ShellExecute API function. Our analysis showed that the actions performed by CPL malware are simple and effective enough to compromise the user's system. The malicious program is not installed into the system, but only specializes in downloading and installing other malicious programs into the system, that is, it acts as a downloader or downloader. Thus, the bootloader itself in the system is difficult to detect because it leaves no traces there, for example, registry keys or other indicators.
Fig. The code snippet that is responsible for the execution of the downloaded file.
Many of the malware files that we analyzed are variants of the Win32 / TrojanDownloader.Banload malware family and specialize in installing banking trojans into the system.
Most samples of CPL malware use string decryption mechanisms based on SUB and XOR operations. The decryption key is hardwired in the code of the function itself, which is responsible for decoding. The malicious program uses the so-called. “Extended Backus – Naur Form (EBNF) for storing encrypted strings and a key.
In the form of a regular expression, it looks like this:
It can be seen that the encrypted strings (cipher_string) consist of at least two pairs of hexadecimal characters (in upper case), and the number of characters will always be even. The key consists of at least one alphanumeric character, also in upper case. We also observed in the keys such characters as "@" and "!", Which we did not include in the regular expression above for simplicity.
The following figure shows an example of the decryption algorithm. At the first stage, the characters of the encrypted string will be encrypted twice, since each pair is considered as a hexadecimal byte value. The same can be said about the key, the sequence of ASCII characters is treated as a hexadecimal byte stream.
Fig. The first stage of the decryption algorithm.
Fig. The second stage of the decryption algorithm.
At the first stage of the algorithm, it is clear that in the decryption operation the first pair of characters of the encrypted string is skipped; it will be used in the second stage as a subtracted value from the result obtained at the first stage of the algorithm. Already at this stage, the result of the subtraction is considered as an ASCII character. In our example, the ASCII code represents the letter “h”. Note that in the case when the result of the subtraction operation gives a negative number, the value 0xFF is added to the most subtractive before the subtraction operation occurs. The figure below shows how the decryption operation takes place for the first seven characters of the encrypted string.
Fig. Decrypt the first seven characters of the encrypted string of the CPL malware.
The screenshot below shows the main part of the decryption function in IDA Pro. The function reads the first two characters of the encrypted string from memory, stores them and starts the decryption process. In the loop, the function takes the next two characters of the string and a pair of key characters, performing an XOR operation. Then, the subtraction (SUB) operation is performed on the obtained value (the first stage), and the value of the first pair of characters that were stored in the memory at the very beginning of the function is subtracted from it. The resulting value is copied to a memory buffer storing the decrypted text. At the last step, the pair of symbols used in the XOR operation is copied, that is, they become a subtraction value for the SUB operation at the next iteration. In the case when the decryption characters still remain, and all the key characters have already been used up, the key characters are taken from the very beginning.
Fig. Line decryption function.
Source: https://habr.com/ru/post/257679/
All Articles