According to Limor Kessem, executive security advisor at IBM Security, “unlike its predecessor, Dyre, TrickBot has “dabbled” in malvertising, leveraging the RIG exploit kit, malicious email attachments and poisoned Office macros coming through the “Godzilla loader”. That behaviour suggests that the group behind TrickBot is after specific business accounts. They have been sending malware-laden spam to companies, not just indiscriminate waves of email.” This is another new feature which Dyre did not contain.
Experts agree that although there are quite a few similarities, TrickBot has been rewritten with a different coding style and minor changes have been made to upgrade the code rather than reinvent the wheel. Similarities include, loaders and custom encryptors, similar hashing features, and an upgraded command and control encryption tool.
TrickBot contains more C++ code, compared to Dyre, which mostly used C. The new Trojan also uses the Microsoft CryptoAPI instead of built-in functions for AES and SHA-256 hashing algorithm (a kind of unique signature for a text or data file – also used by Bitcoin). Dyre ran commands directly, whereas TrickBot links with the Task Scheduler through the COM standard for more impact.
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.
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”).
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.
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.
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:
TrickBot is made up of many layers.
Figure 4: Sourced from Malwarebytes Labs
The first layer is generally the protective layer, containing the encrypted payload that tries to hide from AV software.
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.
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.
You find the info useful?