Skip to main content

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.
Labels:

Comments

Post a Comment

Popular posts from this blog

Grinju Downloader: Anti-analysis (on steroids) | Part 2

  This malware takes anti-analysis and stealth techniques to a new level We took a look at this malware in the Part 1 of this publication. Now let’s carry on with the analysis and dig deeper into the various anti-analysis and stealth-exec features of this malware in Part2. Malpedia Inventory: https://malpedia.caad.fkie.fraunhofer.de/details/vbs.grinju Secondary Macro Code First of all, here’s the entire code that is dumped in the sheet once all the macro functions have been completed. Take a look at these lines and try to figure out what they are meant to do. Then we’ll take a look at the most important of these briefly before moving on to the next section. =CLOSE(FALSE) =FORMULA(LEN(APP.MAXIMIZE())+-459,Sheet1!R18690C129) =FORMULA(LEN(GET.WINDOW(7))+-131,Sheet1!R18691C129) =FORMULA(LEN(GET.WINDOW(20))+-893,Sheet1!R18692C129) =FORMULA(LEN(GET.WINDOW(23)=3)+433,Sheet1!R18693C129) =FORMULA(LEN(GET.WORKSPACE(31))+864,Sheet1!R18694C129) =FORMULA(LEN(GET.WORKSPACE(13)>770)+...
Post a Comment
Read more

Grinju Downloader: Anti-analysis (on steroids) | Part 1

  This malware takes anti-analysis and stealth techniques to a new level Malpedia Inventory: https://malpedia.caad.fkie.fraunhofer.de/details/vbs.grinju I’ve come across some great anti-analysis code in malware over the years. This one takes the top spot. On that note, let’s get into it, this is a long one! Since this malware employs a very complex structure, I’ve decided to divide the analysis into different sections. I’ll try to keep it as simple as possible but having said that, it really is a very complicated project. Hence, publishing in parts. TLDR: This is a very well-thought and equally well-written malware. There’s no VBA that you can analyse. The values and formulas that are used are spread across the worksheets to thousands of rows. The functions, among other things, are used to close the file, corrupt it and also delete the dropped scripts to make analysis extremely hard. In fact, you cannot analyse this malware without altering the code it self. Along the way, you’ll a...
Post a Comment
Read more

Trickbot — a concise treatise

Post-execution scope of impact and threatscape details of a sophisticated malware First Edition, April 2019 Vishal Thakur Introduction S ince its initial release, Trickbot has been an advanced, modular malware, built on complex, well-written code and backed by continuous improvement and on-going development. The modular structure of the code is the most important part of this malware. Other than giving it a clearly defined and segmented flow, it allows the authors to have the ability to add new modules with new purposes to the existing malware, which they have been doing regularly throughout the history of the malware. Trickbot is a beautiful piece of code, used for malicious purposes. Technical analysis of this malware has been published throughout its existence in the wild and there are some good, detailed publishings that are available on the internet that go into great technical details regarding the inner workings of the code and flow of Trickbot. Here’s one of my earl...
Post a Comment
Read more