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:
The binary had a compilation timestamp of
Tue Nov 20 12:13:49 2018 as seen in
The binary imports:
- Binary may be loading more functions dynamically.
- Binary may be involved in cryptographic operations.
- Binary may display some message box, possibly as a diversion
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.
Windows Defender Disabled through Registry
Spawns Multiple Processes
cmd.exe which executes PowerShell.
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 –
22.214.171.124: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.
The binary drops a configuration file named,
C:\Users\A\AppData\Roaming\vrssit\, containing encrypted data. The key to decrypt this data may lie within the binary.
Code Analysis + Debugging
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
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
_main function is at address,
Copying Encrypted Data into Memory
The binary uses
40 distinct functions to handle copying of hard-coded encrypted data into memory (
Preparation for Data Decryption – Part 1
An encryption related function is called, with
0x422000) being the most significant.
CryptAcquireContextA is loaded from
Advapi32.dll and is used to create a new
RSA key container at address,
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
CreateWindowExA repeats continuously until the address
Preparation for Data Decryption – Part 2
The binary gets
Advapi32.dll to import a hard-coded
RSA public key at address,
RC4 key is created (
RC4 key is decrypted using the public
RSA key and imported at address,
254464 bytes stored at
0x422000 are decrypted using the decrypted
We can see that the contents of the buffer contains a PE executable!
The binary allocates
RWX memory (at
0x480000) of size
It copies the decrypted
EXE into the allocated memory.
And executes it in-memory using a
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/