Trickbot report - S2 Grupo S2 Grupo de Innovación en Procesos Organizativos INNOVATION IN PROCESSES MALWARE REPORT Evolution of Trickbot REPORT 06/2017 1. INTRODUCTION ................................................................................................................ 3 2. INFECTION PROCESS ..................................................................................................... 5 3. TECHNICAL CHARACTERISTICS................................................................................. 6 4. MODULE LOADING SYSTEM ...................................................................................... 13 5. NETWORK CONNECTIONS .......................................................................................... 21 6. ENCRYPTION MECHANISM ......................................................................................... 25 7. IPC MECHANISM (Inter-Process Communication) ................................................ 29 8. RELATED FILES.............................................................................................................. 32 9. DETECTION ...................................................................................................................... 33 10. DISINFECTION ............................................................................................................. 35 11. ATTACKER INFORMATION ...................................................................................... 36 12. REFERENCES ............................................................................................................. 38 13. AUTHORS ..................................................................................................................... 38 INDEX 1. INTRODUCTION This document contains a review of the latest versions of a Trojan family known as “Trickbot/TrickLoader”. It is a bank-type Trojan that steals credentials and bank details from infected users. Although its main objective and behavior is focused on online banking users, being a modular Trojan, it has capabilities that attackers could use for other purposes, such as document exfiltration. You can find a lot of documentation regarding the logic and origins of this malware; part of this report is based on information from some of them in order to contrast it with the logic of the latest versions and to be able to observe its evolution and new functionalities. All sources for which information has been obtained can be found in the references section. It should be noted that the report starts with and relies mainly on the analyses carried out by @hasherezade and by Xiaopeng Zhang (Fortinet). Based on these analyses, an attempt was made to compare whether in the last versions some aspect had changed and to deepen in the mechanisms not described until the moment. In summary, Trickbot has the following capabilities: It loads the code into the system It creates a replica of itself in the %APPDATA% It applies persistence techniques It collects sensitive information It injects code into other applications to control the information they handle It exfiltrates the information you get to your Command and Control server During the completion of this report the S2 Grupo Malware Laboratory worked with the samples that match the following MD5 hashes: 1000005_Trickbot_Loader.exe a50c5c844578e563b402daf19289f71f 1000005_Trickbot_bot32.exe 28661ea73413822c3b5b7de1bef0b246 1000010_Trickbot_Loader.exe 218613f0f1d2780f08e754be9e6f8c64 1000010_Trickbot_bot32.exe 135e4fa98e2ba7086133690dbd631785 1000014_Trickbot_Loader.exe e054eaae756d31a4f6e30cc74b2e51dd 1000014_Trickbot_bot32.exe 719578c91b4985d1f955f6adb688314f 1000016_Trickbot_Loader.exe 132c4338cdc46a0a286abf574d68e2e0 1000016_Trickbot_bot32.exe e8e7b0a8f274cad7bdaedd5a91b5164d As you can see in the previous image, four different versions of Trickbot. Each one of them consists of its loader and its final payload for 32-bit systems; although there is also the 64-bit version of all, it was not the subject of the analysis performed. 2. INFECTION PROCESS The main route of infection of this malware occurs through a Word document with macros that arrives attached in an email or through an exploited vulnerability by an ExploitKit. The infection follows this order of execution: A Trickbot sample is downloaded from a compromised domain in the% APPDATA% folder and executed It creates a scheduled task on the system that provides persistence It creates two files ("client_id" and "group_tag") in the same directory, one with a unique ID of the infected host and one with the ID of the current infection campaign or version of the configuration. It contacts with an external IP obtaining domain, among other things to test the connectivity and send it to your command and control servers (C2 from now). It contacts one of its C2 servers to get malware updates, modules that perform most of the malware logic and various configuration files. After all this, it begins to execute or inject in different processes its modules that are responsible for collecting information of the system and browsing credentials especially of online banking. 3. TECHNICAL CHARACTERISTICS The main executable of Trickbot is usually packaged with its own “packer”, which obfuscates the functionality of the executable and prevents generic signatures from being generated from the content itself, seeing that for each version the packer causes the code to vary completely. After unpacking one can see how the number of functions of the executable increases greatly, as it now reflects the functionality of the malicious program: Packed Unpacked After the "unpack" the first stage of this malware is obtained, known as "Loader". This executable is responsible for verifying the architecture of the system and depending on whether it is a 32 or 64 bit computer, it loads the "bot" from its resources, corresponding to that architecture. The "bot" is the executable that takes care of the last stage of infection and contains all the basic malware logic. In the first versions, the resources contained in the Loader were easily recognizable because they had descriptive names, as they identified the two versions of the Bot and a Loader to correctly load the 64-bit. In the latest versions they began to put non- descriptive names so as to make it difficult to identify them: V10 de Trickbot V14 de Trickbot V16 de Trickbot These resources, consists on executable files (PE) encrypted with the AES CBC algorithm, so after extracting them they still need to be decrypted or otherwise can be extracted from memory after running the Loader and waiting for it to perform the decryption itself and load them in RAM. After loading the corresponding bot, it starts executing the main logic of this threat: It first checks its location on the system, and if it is not found in% APPDATA% it copies itself to this location, starts executing its replica in that folder and ends the current process. As a persistence technique, it uses scheduled system tasks rather than registry keys as is often the case in other samples of malware. Previous versions of Trickbot, in all cases created a single programmed task called "bot" and made sure that every minute was launched to keep running on the system. In the latest versions, if it is executed with administrator permissions in addition to the previously mentioned task, which it has called "Drives update", it creates another one that executes it when any user logs in, called "AplicationsCheckVersion" Its next action is to check if it has all the configuration files with which it usually works: If it does not find them, it generates them from information obtained in the system and the resources of the bot, which consist of an encrypted configuration file (CONFIG) and a key to verify the signature of the configuration and modules (KEY). In this case there have been no changes in the names of these resources to date, although it is likely that in future iterations we will see how they eliminate these names as in the case of Loader resources. In the first run of Trickbot on the computer generates a file called "client_id" that contains a token or user ID, which identifies the current host. Trickbot obtains it’s configuration from a file in a disk with the name config.conf or from the resources of its own binary. This configuration will be decrypted, and after decryption it can be seen that it contains the version of the malware itself, a campaign code or version of the configuration, the addresses of several of its main C2s, and the list of modules that it must download and run automatically from any of its C2s. It then checks the connectivity by making a request to an external domain that reports the victim's IP esternal address, this domain comes from a list contained inside the malware and which have been increasing during the different version updates. Version 7 Version 14 If it receives the response it expects from this request, it starts contacting the C2s it has obtained from its configuration to start reporting information on the new victim, check for updates, and receive new modules that expand its capabilities. In normal configurations, after making certain requests with different commands that report host information to one of the C2s in its configuration, it obtains the IP of a specific server from which it can download new modules through port 447/tcp. All downloads of configurations and modules are encrypted with the same algorithm (AES CBC) and all the files are saved encrypted to the disk. After updating and downloading the configurations and modules that it has in the configuration, it decrypts and maps the first module in the memory of its own process, "systeminfo", which is responsible for collecting information such as OS version, CPU type, the amount of RAM, the users of the system and the list of installed programs and services: Then it loads the injectDll32 module together with its configuration files: Once this module is loaded, in case the user visits one of the websites listed in the configuration files (such as * cey-ebanking.com / CLKCCM / *) of this module, it captures the relevant browsing data and sends them to their C2: As discussed in the DevCentral report, version 9 of trickbot, a new module was added to the Trickbot toolset called "mailsearcher". Then in the case of being in the configuration will also be loaded into the victim system. The order in which the modules are loaded will depend on the configuration file. "mailsearcher" is responsible for searching all the files of each disk connected to the system and comparing the extensions of the files with the following list: This module reports itself to a specific C2 that it obtains from its own configuration: The URI of the request is different from the one used by the "core" of Trickbot, since in this case it has the structure "[IP]/[group_id]/[client_id]/send/" and uses its own User- Agent "KEFIR ! "Which makes it much more independent than the other modules found to date. What is seen in this section describes the actions performed by Trickbot after its first execution. From this moment Trickbot enters a loop where from time to time it checks if there is a new configuration and if there are new versions of the malware or of some of the modules. In addition, within the same loop, it performs reports with the information it collects. 4. MODULE LOADING SYSTEM During the analysis it has been observed that Trickbot uses events to control the execution flows between the core and the modules. In addition, the core performs the resolution of the Windows APIs of the modules. Let's see how this core communication system works with the modules. First it creates a svchost.exe child process suspended with the CreateProcessW function: Later with the CreateEventW function, it creates three events that will be used to manage the waits and communications between the main executable (Trickbot) and the svchost child process. Once it has the handlers of the three events, using VirtualAllocEx and WriteProcessMemory it injects in the suspended svchost process 32 bytes of data like the following: The first three groups of 4 Bytes (in red boxes) represent the identifiers of events that have created trickbot previously and that will use for their communication, in this case 4, 8 and C respectively. The following 5 groups of 4 Bytes (in purple boxes) represent the offsets in the memory itself of the svchost process, from the following functions of the kernel32.dll library: SignalObjectAndWait WaitForSingleObject CloseHandle ExitProcess ResetEvent Using the same injection method, it loads its own function into another offset of the svchost memory that will be used as the intermediary between Trickbot and the module code. This feature is one of the most characteristic details of the Trickbot module management. It is in charge of keeping itself waiting for orders from the main process. These come as offsets from functions within the memory of the svchost process itself and parameters with which to call them. This information is obtained through scripts in its own memory by Trickbot as detailed in the previous case. Most of its logic consists of a loop that starts and ends in code zones with a blue background; after the first instructions, in case of detecting a problem with the process, it enters the area marked in red that closes the handlers of the events and the process itself. In case everything goes correctly, the zone in which it enters consists of a switch, marked in green. Depending on the number of parameters needed by the function to call, enter one of the blank zones. In the case of the following screenshot, if the number of parameters (which it has loaded in edx) coincides with 9, it enters a zone with nine calls to "push edx" with which it is loading parameters in the stack extracted from consecutive offsets after eax. Finally, it makes a call to ecx, where it has loaded the first offset of eax in the fourth instruction of this zone and that corresponds to the position of a function. In the next screenshot you can see an example of calling a function like this and the status of the registers during the execution. To manage the wait between the parent and child process, Trickbot uses the events it created before the injections into the process. Using these events, when it reaches the last zone of the loop (in the previous screenshot marked with blue background) it contains two calls that correspond to a ResetEvent that notifies Trickbot that it has reached the end of the loop: And a call after SignalObjectAndWait, to which it passes the IDs of two events. This function leaves the process suspended waiting for Trickbot to do a ResetEvent of the event in this case with ID 4, which means that it has loaded the new parameters into the memory for the next iteration of the loop: Before starting the execution of this process, it injects in the Entry Point of svchost, four lines that redirect the flow of the main thread to the previous function, passing it as a parameter, the 32 bytes of data injected at the beginning: After preparing all that, it calls ResumeThread and the process goes into execution. During the first iterations of the loop, Trickbot maps one of the modules in the process memory, section by section: In the next iteration, using the data that the parent process has passed to it, it loads all the DLLs required by the newly loaded module with LoadLibrary and the functions of these that it will need with GetProcAddress. Finally it calls an initialization function of its own module, which writes the "Success" string in one of the memory zones edited by Trickbot, in case everything is correct. From this point, this last iteration is suspended with the call to SignalObjectAndWait, waiting for Trickbot to require, for example, the reporting information of said module. From the main process side, you can see how it contains a function to call the different functions that export each of its modules. These functions are those that each module exports, since the modules are DLL's and as such they export functions to be used by the core. To date these functions have not been changed in any of the versions and these are Start, Control, Freebuffer and Release. eens a en 1 | 1 Cal as (ile =] 9030B28C nov eax, [ebprvar_s8)| |oospBa82 GO3DB28F add eax, 4 66308382 loc 308382: 8@3082C2 nov [ebp+var_98], eax] ]60308382 nov edx, [ebp+var_50] 803DB2C5 nov eax, [eax] 90308385 nov edi, [edxreax*s] O3DB2C7 add ebx, 4 66308388 push esi @G3DB2CA test eax, eax 003DB389 call sub_3DBASO OO3DB2CC jnz short loc_3DB261 OO3DB38E nov edi, eax - po 803DB395 push edi H Tr 60308396 call dsiistrconpr GG3DB39C test eax, eax OO3DBI9E jnz short loc_3DB3AB : rrise = seapesee loc_3083AB: | “Control” G63DB3AB push offset aControl_@ 903DB380 push edi : IpString1 60308381 call dsilstrconpa 660308387 test eax, ©ax 803DB3B9 jnz short loc_3DB3C6 ues Gus 903DB3C6 96308306 loc 308306: ; |"FreeBuffer" G63DB3C6 push offset aFreebuf fei 903DB3CB push edi : IpString1 GO3DB3CC call dszistrcnpr @63DB302 test eax, eax 803DB304 jnz short loc _3DB3E1 —<$<—_config". When it obtains administration permissions, it copies itself to the folder: C:\Windows\System32\config\systemprofile\AppData\Roaming After executing this action, it removes the executable from the Roaming folder of the initial user, leaving the modules and configurations intact. 9. DETECTION First, manually, you can find the files mentioned in section 8 in the folder: %APPDATA%, the only case that can vary is the main executable that can be found with different names depending on their origin, since the others to date have not changed at any time. Depending on the scenario, you can also find one or two tasks called "bot" or "Drivers update", and "AplicationsCheckVersion", which will execute an application in the% APPDATA% directory every minute and when you log in respectively. During its execution, it is easier to detect it among processes running on 32-bit computers, because it keeps the executable name replicated in % appdata%. On the other hand, 64-bit computers use the Microsoft svchost.exe process to hide when run by a normal system user. In the case of being invoked by the persistence task with SYSTEM permissions, it behaves the same as in 32-bit systems. For automatic detection, there are no NIDS rules that can detect it through your traffic so far, since the fact that it is encrypted by SSL complicates it to a greater extent. Yara rules have been developed to detect it in memory, since the executable comes packaged with different types of systems for each campaign and version, preventing a common rule. The rules for detection in memory are as follows: rule MALW_trickbot_bankBot : Trojan { meta: author = "Marc Salinas @Bondey_m" description = "Detects Trickbot Banking Trojan" strings: $str_trick_01 = "moduleconfig" $str_trick_02 = "Start" $str_trick_03 = "Control" $str_trick_04 = "FreeBuffer" $str_trick_05 = "Release" condition: all of ($str_trick_*) } rule MALW_systeminfo_trickbot_module : Trojan { meta: author = "Marc Salinas @Bondey_m" description = "Detects systeminfo module from Trickbot Trojan" strings: $str_systeminf_01 = "" $str_systeminf_02 = "" $str_systeminf_03 = "" $str_systeminf_04 = "GetSystemInfo.pdb" $str_systeminf_05 = "" $str_systeminf_06 = "" condition: all of ($str_ systeminf_*) } rule MALW_dllinject_trickbot_module : Trojan { meta: author = "Marc Salinas @Bondey_m" description = " Detects dllinject module from Trickbot Trojan" strings: $str_dllinj_01 = "user_pref(" $str_dllinj_02 = "" $str_dllinj_03 = "" $str_dllinj_04 = "" condition: all of ($str_ dllinj_*) } rule MALW_mailsercher_trickbot_module : Trojan { meta: author = "Marc Salinas @Bondey_m" description = " Detects mailsearcher module from Trickbot Trojan" strings: $str_mails_01 = "mailsearcher" $str_mails_02 = "handler" $str_mails_03 = "conf" $str_mails_04 = "ctl" $str_mails_05 = "SetConf" $str_mails_06 = "file" $str_mails_07 = "needinfo" $str_mails_08 = "mailconf" condition: all of ($str_mails_*) } 10. DISINFECTION Taking into account the detection process, in case of finding traces of this threat in the system and that none of our system protection measures are able to detect or disinfect it, the ideal steps for disinfection would be to: • Eliminate the task that is executed every minute, so that it does not restart the execution of the malware. • Complete the Trickbot process with the task manager or with an application such as ProcessExplorer. • Browse to the% APPDATA% folder where it is installed, to delete the main Trickbot executable and then the three files ("user_id", "group_tag" and "config.conf") and the Modules folder. • Browse to the SYSTEM user's APPDATA folder (C:\Windows\System32\config\systemprofile\AppData\Roaming) to delete the same files from the SYSTEM user. With this, we would have completely eliminated this threat from the system, although it would be advisable to review that the task of persistence has not been restored in case that just in the period of time between eliminating it and closing the process, it would have been in the early stages of execution its and would have replaced it, although it would not be dangerous as it could not find the executable in the system. On the other hand, in cases where the infection has been through an ExploitKit, it is likely that in addition to Trickbot, our system is infected with other types of malware, since they usually do not install a single sample, so performing analyses with different tools would be recommended, reaching formatting in sensitive cases. 11. ATTACKER INFORMATION For the Trickbot infrastructure, as @hasherezade mentioned in its post in the blog of Malwarebytes, the IPs of its C2 correspond to devices such as Routers or IP Cameras (all tested with ARM processors) distributed by many different countries and in all the cases that we analyzed belonging to ISP of each of the countries that we will see below. The distribution of C2 countries (based on the configurations collected) is shown in the following chart where you can see how the United States and China stand out: Most affected systems have an access web interface such as the following: And in case of access by https to the URL formed by one of the Trickbot commands, the certificate that it shows us, is still the same as in the first versions analyzed in the post mentioned above: 12. REFERENCES https://blog.fortinet.com/2016/12/06/deep-analysis-of-the-online-banking-botnet- trickbot http://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html https://www.infosecurity-magazine.com/blogs/rig-ek-dropping-trickbot-trojan/ https://devcentral.f5.com/articles/is-xmaker-the-new-trickloader-24372 https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/ https://fraudwatchinternational.com/malware/trickbot-malware-works/ https://msdn.microsoft.com/en- us/library/windows/desktop/ms682425%28v=vs.85%29.aspx https://msdn.microsoft.com/en- us/library/windows/desktop/aa366890%28v=vs.85%29.aspx https://msdn.microsoft.com/es- es/library/windows/desktop/ms681674%28v=vs.85%29.aspx https://msdn.microsoft.com/es- es/library/windows/desktop/ms682437%28v=vs.85%29.aspx 13. AUTHORS • Marc Salinas • José Miguel Holguín Ramiro de Maeztu 7, bajo 46022 Valencia T. (+34) 963 110 300 F. (+34) 963 106 086 Orense, 85. Ed. Lexington 28020 Madrid T. (+34) 915 678 488 F. (+34) 915 714 244 www.s2grupo.es