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/