TrickBot Execution Flow

Step by step

In this post, we go through a step by step look at the execution flow of the latest TrickBot variant. I’ll skip some of the more basic stuff and get to the parts that are interesting. To get you started, I have summed it up in this diagram, it shows the entire flow but as I said earlier, we’ll skip over the some of the steps.

Trickbot execution stages

I’ll start off with some of the interesting bits. In the code below, you can see that the malware uses some very clever ways to get around the local anti-malware software. The anti-malware in this case happens to be Windows Defender. It tries to simply stop the service to start with. Then it moves on to deleting the service altogether.

Stop the Defender service

Delete the Defender service

Then the malware moves on to an interesting approach. It uses Powershell to disable the ‘Real-time Monitoring’ feature of the application — which would allow the malware to execute without being detected at all.

Using Powershell to disable the Realtime Monitoring feature

After the anti-malware solution has been dealt with, the malware copies itself to a different location and launches from there.

Malicious process launched from AppData

Next step is to launch the fake svchost.exe (no ‘-k’ in the command used, basic DFIR steps should guide you through this) and move on to getting the config from the c2.

Fake svchost.exe is launched

After this step, new directories are created for the modules to be loaded into and configs are saved to these locations for later use.

Example: C2 config is created

File being written to disk

Another example

We can see here that the C2 config is written to the stack:

Stack view

And here’s a view of the mem dump:

C2 info loaded to memory

The image below shows all the instances of svchost that are spawned by the malicious process (each one has a specific function).

Settings.ini is an encrypted file that has information on the system. The key used to encrypt the modules/configs is saved in this file.

In the image below, you can see the encrypted data being loaded into the memory before it is written to disk:

And here is the final process tree:

The malware also does a quick IP check on the victim machine:

This one if interesting. I first wrote about this back in 2017. The malware launches an instance of firefox (along with other available browsers) which in turn spawns an instance of the ctfmon.exe — a process that helps recognise input from sources other than the keyboard.

Now, let’s have a quick look at how the actual injection works at this point in time. The configs have all the information on which websites should be injected into (the list has grown quite a lot, with generic URIs that seem to target the login pages, regardless of the sites).

Example of a config file

Once the user browses to a site that matches the config, the injection is transacted. It is good to see that chrome is picking these injections up (in some cases) and blocking the sites (other browsers are not doing that at the time of this writing).

Let’s go ahead and take a deeper look. The same session on a non-infected machine looks like this:

End of code on a non-infected machine

On an infected machine, we are able to see the injected code:

End of code on an infected machine

At the time of this writing, the injected code loads a JS variable that is used to steal information that is exchanged over this session (like passwords and account IDs).

The samples used for this analysis were taken from virustotal.com and are available through various OSINT resources. If you need the hash for one of them, let me know through comments and I’ll make that available.