In the previous article, we looked at the analysis of the Gozi/Ursnif downloader. For this article, I picked up the TrickBot malware which is the most complicated malware I’ve analyzed to date. In fact, I had to divide the analysis into a three-part article.
Note 1: Ensure you have the malware sample placed in a safe environment (preferably, a malware analysis lab setup) before starting analysis.
Note 2: Memory addresses mentioned in this article are just for reference. They may be different on your machine.
Hashes for the sample:
- MD5:
5cb530286450af3d5a11715105a745d9
- SHA256:
82af9ce9081280ffcb603df3d5685201dd781762227908a9674076a0b8041467
Analysis
Static Analysis
Compilation Timestamp
The binary had a compilation timestamp of Tue Nov 20 12:13:49 2018
as seen in PEstudio
.
Interesting Imports
The binary imports:
GetProcAddress
,GetModuleHandleA
- Binary may be loading more functions dynamically.
CryptEncrypt
,CryptImportKey
,CryptDestroyKey
- Binary may be involved in cryptographic operations.
SendMessageA
,MessageBoxA
- Binary may display some message box, possibly as a diversion
TLS Callbacks
The binary contains two TLS callback functions which indicates anti-debugging capabilities. TLS callback functions are called before the default entry point of a binary. If a debugger is not set to break at system breakpoint, malicious code may be executed even before the debugger first breaks at the default entry point of the binary.

Dynamic Analysis
Windows Defender Disabled through Registry


Spawns Multiple Processes
trickbot.exe
spawns tsickbot.exe
and cmd.exe
which executes PowerShell. tsickbot.exe
spawns svchost.exe
and may have performed process replacement to masquerade around as a benign process.


Installs a Startup Service
The binary installs C:\Users\A\AppData\Roaming\vrssit\tsickbot.exe as a service.

Disables Windows Defender Real-Time Monitoring through PowerShell


Significant Network Activity
The binary is capable of communicating with multiple remote servers – 46.149.182.112:449
, 140.190.54.187:449
, etc. A remote IP is contacted only if the previous IP that the binary tried to contact is unavailable. From the snaps below, it can be seen that the transmitted information is encrypted.




Configuration File
The binary drops a configuration file named, settings.ini
in C:\Users\A\AppData\Roaming\vrssit\
, containing encrypted data. The key to decrypt this data may lie within the binary.

Code Analysis + Debugging
Pre-Analysis
Before running trickbot.exe
in a debugger, ensure that the debugger is set to break on a system breakpoint instead of the entry point. This is because TLS callback functions are executed before code at the default entry point. I’m using OllyDbg2
.

In IDA
, Ctrl+E
shows the set of entry points.

Set breakpoints on the above three addresses in OllyDbg2
. I used memory map to easily find these addresses.

TLS Callbacks Analysis
On execution, the breakpoint on TLS callback function at address 0x4216A4
is hit first. It did not have any significant function calls. The breakpoint on TLS callback function at address 0x421670
was hit next, but this function did not do anything interesting either. In summary, the TLS callback functions did not have any malicious code. Execution next hits the breakpoint at address 0x401284
which is _WinMainCRTStartup
. The _main
function is at address, 0x40D1B2
.
Copying Encrypted Data into Memory
The binary uses 40
distinct functions to handle copying of hard-coded encrypted data into memory (0x462020
– 0x46333F
).


Preparation for Data Decryption – Part 1
An encryption related function is called, with _rawData
(0x422000
) being the most significant.

CryptAcquireContextA
is loaded from Advapi32.dll
and is used to create a new RSA
key container at address, 0x28FB74
.


Useless Code
The binary then sends a character, d
to itself and checks if it is being processed by the current window. If not, the character is sent again until it verifies that the message is being processed by the current window. Else, it sends the next character of the message. If the message was unable to be sent (determined through GetLastError
), the binary creates a new window.

This sequence of SendMessage
, GetLastError
, InSendMessage
and CreateWindowExA
repeats continuously until the address 0x40CC7E
.
Preparation for Data Decryption – Part 2
The binary gets CryptImportKey
from Advapi32.dll
to import a hard-coded RSA
public key at address, 0x460200
.


A 76-bit
encrypted RC4
key is created (0x460340
– 0x46038C
).

The RC4
key is decrypted using the public RSA
key and imported at address, 0x40D10B

Data Decryption
254464
bytes stored at 0x422000
are decrypted using the decrypted RC4
key.

After decryption:

We can see that the contents of the buffer contains a PE executable!
In-Memory Execution
The binary allocates RWX
memory (at 0x480000
) of size 262144
bytes.

It copies the decrypted EXE
into the allocated memory.


And executes it in-memory using a call
instruction.

TL;DR
The malware sample is a PE32
executable which is capable of disabling Windows Defender, modifying the Windows Registry, communicating with remote servers, dropping other files, achieving persistence on the system and executing an embedded EXE in-memory.
Thanks for reading!
In this article (1/3), I described my analysis for the TrickBot malware. So far, the malware has decrypted an EXE in memory and executed it. In the next part, I’ll describe my analysis for the malware’s process injection activity.
Thank you for reading! If you have any questions, leave them in the comments section below and I’ll get back to you as soon as I can!
Feature image credits: https://hackersonlineclub.com/malware-analysis/