Recently there have been several reports of a financial malware named TrickBot1. The malware’s code looked similar to Dyre’s code but was lacking in functionality in comparison to the old Dyre samples. It also had a fairly basic module configuration, including:
- a system information collecting module
- a browser injection module
The malware had no VNC, SOCKS, and form grabber modules. The samples that were observed in the field had a persistency mechanism, browser function hooks (also known as man-in-the-browser) and a short list of Australian targets that were fetched from the command and control (C&C) server.
This week our research team came across a new campaign of TrickBot malware. The previous webinjects configuration was partial and looked like a part of a testing version of the TrickBot malware. After analyzing this campaign, we noticed a change in the webinjects configuration.
Many new targets, including Germany and the UK, were added to the previous targets of Canada, Australia, and New Zealand.
Figure 1: TrickBot target evolution
After the targeted source has been injected with malicious code, it is returned to the user as if it actually came from the bank.
In the following illustrations, one can see the fields that were added. These are intended to filter out certain file types as they can be fetched from the real bank site.
Figure 2: TrickBot’s old configuration
Figure 3: TrickBot's new configuration
Static injections, also known as “redirects,” are now fully functional in TrickBot. When the user tries to connect to a targeted site, the malware redirects the request to a malicious C&C server and returns a fake page that looks exactly like the bank’s original page.
Figure 4: TrickBot's new configuration
Inside the browser function hook, the request page is forwarded to the fake domain containing Bot ID inside the “ClientInfo” header.
Figure 5: A redirected request to a malicious domain
A ping request, which is sent from every page in the site, is launched by a “start_ping” function on a “document.ready” event in an endless loop every two seconds (like Dyre).
These requests are also redirected to the malware’s server inside the browser network hook.
Figure 6: A ping is sent by the malicious code in the page
Hello Dyre, My Old Friend
Similar to Dyre, TrickBot uses pipes for its inter-process communication.
Once a browser is launched, a malicious module (“core-dll.dll”) is injected into its memory by the main TrickBot module in svchost.exe.
Figure 7: TrickBot’s module in Firefox’s address space
The browser module waits for incoming pipe connections. The main module connects to the browser module using a named pipe “\Device\NamedPipe\ <PID >lacesomepipe” where PID is the process ID number of the browser.
Figure 8: The pipe in the infected svchost.exe process
The commands are one byte long. Each command is a letter that signifies the data to transfer.
Figure 9: Handling pipe commands
Additional commands include:
“i” – get client_id, e.g.: ADMIN-PC_W617601.A9B4C7FF18D0126F481CA1758B0A0FEF
“a” – get self ip, e.g.: 126.96.36.199
“g” – get group_id, e.g.: lindoc3
“q” – quit and disconnect the pipe
The browser module asks the main module for every one of these data pieces and if one of the data pieces is not received, the malcious thread will terminate and the browser will not be patched by the malware.
A security improvement from Dyre’s pipe is implemented by closing the pipe right after all the commands are sent. Meaning that if a researcher is inspecting the malware, connecting to the pipe in order to get the configuration is not as trivial as it was in Dyre.
Sampled MD5: 104923556ace17b4f1e52a50be7a8ea0
It seems that the creators of this malware are rolling it out to the field gradually, testing its spreading capabilities and adding targets as they go along. It is highly likely that we will witness its functionality expand and its target list will continue to grow.