Last week, we talked about a new banking Trojan, called TrickBot, that is plaguing banks all around the world, including the US, UK and Australia. In this article, we will take in inside look at how the Trojan works.
TrickBot has made its way into the banking sector over recent months by using a malvertising campaign, involving Rig Exploit Kit to disseminate its payload.
Behavioural analysis
Once deployed, TrickBot copies itself into %APPDATA% and deletes the original sample. No changes are made to the initial name of the executable file (in the below example the sample was named “trick.exe”).
Figure 1: Sourced from Malwarebytes Labs
The first thing the bot does, is drop two additional files: client_id and group_tag, which are generated locally and used to identify the individual bot and the campaign to which it belongs. There is no encryption – both files contains text in Unicode.
client_id contains: the name of the attacked machine, the version of the operating system, and an arbitrarily generated string.
In the same folder, a config.conf file is also present. This file is downloaded via Command & Control (C&C) and stored in encrypted form.
Note: Command & Control (C&C or C2) is used by attackers to maintain communications with compromised systems within a target network.
A folder, called Modules, is created in %APPDATA%. More files, called injectDll32 (the banker module, injecting DLLs into target browsers to enable theft of credentials) and systeminfo32 (used for gathering general system info), are downloaded into the same location via C&C. They are also encrypted and a list of the attacked browser is hardcoded in the injectDll32.dll.
Figure 2: Sourced from Malwarebytes Labs
Sometimes these files have an equivalent folder that stores the configurations (as seen in the diagram above). Details of the attacked target (i.e. the bank’s URL) are stored in this folder.
The bot is able to remain effective by adding itself as a task in Windows Task Scheduler. No effort is made to try and hide the task under a legitimate name – as you can see in the example, it’s simply called “Bot”.
Figure 3: Sourced from Malwarebytes Labs
If an attempt is made to kill the process, it is automatically restarted by the Task Scheduler Engine.
Network communication
The Trick Bot connects to several servers. It initially connects to a valid server, so that it gets the visible IP. Strangely, it uses its own User Agent (“BotLoader” or “TrickLoader”) and makes no attempt to disguise itself as a legitimate browser. Most of the Bot’s communication with C&C is SSL encrypted, however, some is left unencrypted.
In the URL of a POST request, group_id and client_id are used – which are the same names given to the files seen early. The command id follows after that. This was a characteristic of Dyreza.
An additional payload is downloaded (for example 47d9e7c464927052ca0d22af7ad61f5d) without encrypting the traffic. C&Cs are set up on hacked wireless routers, i.e. MikroTik, which is another feature of TrickBot that is the same as its predecessor, Dyreza.
There is absolutely no attempt made to imitate legitimate-looking names for HTTPs certificates either – they contain completely random data. For example:
https://193.9.28.24/tmt2/TESTMACHINE_W617601.653EB63213B91453D28A68C0FCA3AC4/5/sinj/
Inside TrickBot
TrickBot is made up of many layers.
Figure 4: Sourced from Malwarebytes Labs
Crypter
The first layer is generally the protective layer, containing the encrypted payload that tries to hide from AV software.
Loader
The second layer is the main bot loader, which selects whether to deploy 32-bit or 64-bit payload. New PE files are encrypted and stored in resources. Again, no attempt is made to hide the purpose of the resources. The names are easy to decode.
Figure 5: Sourced from Malwarebytes Labs
To start with, the application acquires information about victim’s operating system, so that the appropriate path can be chosen. Depending on the environment, a suitable payload is selected from resources, decrypted by a basic algorithm and validated. This method is slightly different to how Dyreza worked. Next, a dedicated function is used to map the unpacked bot to the memory and deploy it.
The 32-bit bot uses self-injection to map the new module inside its own memory, before redirecting execution, whereas for the 64-bit payload, the additional executable (64bit PE loader) is first unpacked and run, and then it loads the core, malicious bot. In contrast to Dyreza – where the main modules were DLLs – TrickBot uses EXEs.
In Summary
Trick Bot has a lot in common with its predecessor, Dyreza, although it does not have as many features (possibly designed that way to make distribution quicker). From comparing the code of both bots, it is clear that the offspring does not just contain a few tweaks – it has been completely rewritten and it is highly likely to gain as much fame as the former champion.