Fraud

Little Trickbot Growing Up: New Campaign

Recently there have been several reports of a financial malware named TrickBot; this malware's code looks similar to Dyre.
November 07, 2016
4 min. read

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

Figure 1: TrickBot target evolution

Dynamic Injects

TrickBot has server-side webinjects, meaning, when the user connects to the targeted bank’s site, a replication of the target’s response source is sent to the C&C, where Javascript injections are inserted.

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 2: TrickBot’s old configuration

 

Figure 3: TrickBot's new configuration

Figure 3: TrickBot's new configuration

Static Injections

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

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

Figure 5: A redirected request to a malicious domain

Ping Request

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

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

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

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

Figure 9: Handling pipe commands

 

Additional commands include:

“i” – get client_id, e.g.: ADMIN-PC_W617601.A9B4C7FF18D0126F481CA1758B0A0FEF

“a” – get self ip, e.g.: 8.8.8.8

“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


Conclusion

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.

Authors & Contributors
Julia Karpin (Author)
Principal Security Engineer
Shaul Vilkomir-Preisman (Author)
Malware Researcher
Anna Dorfman (Author)
Footnotes

What's trending?

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read