CPL malware analysis, part 1

    CPL malware is a special type of malware that spreads in the form of dynamic DLL libraries that act as extensions to Windows Control Panel elements. This type of malware is especially popular among cybercriminals in Brazil and is used to distribute the Win32 / TrojanDownloader.Banload downloader and the Win32 / Spy.Banker.T banker .



    Each CPL file is a dynamic link library. The DLL itself, by its model, stores executable code and data that can be used by other executable PE files through the DLL export mechanism. However, it is not possible to directly execute the library 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 by calling the executable file control.exe, which is the Windows control panel. For this, the DLL must satisfy special requirements, one of which is the presence of an export function called CPlApplet . Below is her prototype in Delphi.


    Fig. The prototype of the CPlApplet function in Delphi.

    It can be seen that the function takes four arguments as input: hwndCPl , which is the handle to the main application window; uMsg is the identifier of the message that the DLL sends the executable file to the control panel; lParam1 and lParam2 are arguments that are specific to a particular message. Messages sent by the control panel executable file are the main mechanism for working with the CPL library.


    Fig. The basic structure of the CPlApplet function .

    The dynamic libraries of simple control panel applets 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). Typically, authors place malicious code in that section of the CPlApplet function that is responsible for processing the CPL_DBLCLK message .

    To spread this type of malware, cybercriminals use phishing emails. The user may be offered to read a fake document by opening which he is infected with a malicious program. The following email topics are used by cybercriminals to lull users' vigilance:

    • a document with an invoice or receipt for payment of something;
    • a document with information about the state of the 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 relate to the user.


    The following figure shows a typical attack pattern on users using CPL malware in Brazil. The user’s compromise chain begins with the distribution of malicious files by malicious users via 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. Life cycle of attacks using CPL malware.

    Above we mentioned the typical structure of the core function of CPlApplet, the screenshot below shows a similar function of the malware in the disassembler. It is important to mention that most of the samples of such malware we analyzed are written in Delphi, with the exception of only a small number of samples with our own packers, which are written in Microsoft Visual C.


    Fig. CPlApplet function of one of the malware samples.

    This function has a similar structure to the general form that was mentioned above. It can be seen that there are 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 CPlAppletcalled in various situations and is the main function that implements the logic of the CPL library in memory. The execution diagram of these functions and their connection with the Windows system libraries are shown in the figure below.


    Fig. Call flow of CPlApplet functions .

    The figure shows that the first CPL function of the library to be called is DllMain . This is the entry point to the library, which performs the initialization of its data and structures. DllMain function called by LoadLibrary APIin the shell32.dll library after the library is loaded into memory. It would be logical to assume that the entire logic of the malware’s operation can be immediately placed in this function, since it runs before the call to CPlApplet . We will consider this question below.

    After the initialization of the DLL, i.e., the execution of its DllMain function , a sequential call to the CPlApplet function with various messages is performed . The order of the function call with the corresponding messages is indicated by the numbers from 1 to 7. The CPL_DBLCLK message is the main one, since the main malicious code is located there. In the case of this sample, payload is located there, to which control is transferred when processing this type of message.

    The payload code of the CPL malware samples that we observed has a certain structure and can be divided into the following parts:
    • initialization;
    • building URLs for downloading malicious content;
    • execution of downloaded files.



    Fig. A snippet of malicious payload code.

    As you can see on the graph of calls to the payload functions, 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 a loop, then the function execution thread 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 and other actions, for example, did not call the Sleep function , got the path to other system directories. However, the above diagram is quite common for many samples. The following is a snippet of code that constructs URLs and downloads files.


    Fig. A snippet of malware code that is responsible for downloading files from a remote C&C server.

    The screenshot above shows that for each encrypted string function is called decryption decipher_str . Then, based on these lines, the final URL is formed from which the executable file will be downloaded. It can be seen that the downloaded file is disguised as an image file with the extension .png. It will be saved to the% APPDATA% \ Desk.exe location. The download_URL function directly downloads a file using the regular Windows API calls.

    Note that not all CPL malware samples that we detected use encrypted strings. We often came across patterns in which strings are presented in clear text. In these samples no decryption function decipher_str , which we mentioned above.


    Fig. Example of a malicious CPL malware file with plaintext strings.

    The last piece of payload code is responsible for executing the files downloaded from the 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. A malicious program is not installed on the system, it only specializes in downloading and installing other malicious programs on the system, i.e., it acts as a downloader or downloader. Thus, the loader itself is difficult to detect in the system, since it does not leave traces there, for example, registry keys or other indicators.


    Fig. A snippet of code that is responsible for executing the downloaded file.

    Many of the files of such malware that we analyzed are variants of the Win32 / TrojanDownloader.Banload malware family and specialize in installing banking trojans in the system.

    Most CPL malware samples use string decryption mechanisms based on SUB and XOR operations. The decryption key is hardwired in the code of the function itself, which is engaged in decryption. Malicious program uses the so-called “Extended Backus – Naur Form (EBNF) for storing encrypted strings and keys.



    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. A key consists of at least one alphanumeric character also in uppercase. We also observed such keys as “@” and “!” In the keys that we did not include in the regular expression above for simplicity.

    The following figure shows an example of a 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 considered 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 seen that in the decryption operation the first pair of characters of the encrypted string is skipped, it will be used at 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 subtracted one before the subtraction operation occurs. The figure below shows how the decryption operation occurs for the first seven characters of the encrypted string.


    Fig. Decryption of the first seven characters of the encrypted CPL malware string.

    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, saves them and starts the decryption process. In the loop, the function takes the next two characters of the string and a couple of characters of the key, performing the XOR operation. Next, the subtraction operation (SUB) is performed on the obtained value (first stage), while the value of the first pair of characters that were stored in memory at the very beginning of the function is subtracted from it. The resulting value is copied to the memory buffer that stores the decrypted text. At the last step, the pair of characters that were used in the XOR operation is copied, that is, they become a subtracted value for the SUB operation at the next iteration. In the case where the symbols for decryption still remain, and all the symbols of the key have already been used up,


    Fig. String decryption function.

    Also popular now: