JULY 22, 2019

TrickBooster – A Deeper Dive into the Malware that Successfully Harvested Over 250M Addresses

By: Alon Weinberg and Tom Nipravsky Last week Deep Instinct announced TrickBooster to the world and revealed it has gained its operators a mouth-dr

By: Alon Weinberg and Tom Nipravsky

Last week Deep Instinct announced TrickBooster to the world and revealed it has gained its operators a mouth-dropping database of over 250M email addresses. In our previous blog post we shared information on the extent of Trickbot’s success based on the variety of email addresses collected by Trickbooster from a wide array of government agencies, universities and leading corporations worldwide.

Since the previous blog was published, we’ve been very busy sharing our analysis and findings with partners, authorities and law-enforcement agencies. Yet, we’ve also dedicated our efforts in continuing to analyze and dig deeper into TrickBooster’s activity at the host level, its capabilities and evasion techniques. This blog post will focus on those aspects of TrickBooster.

As mentioned in our previous blog, TrickBooster is used as a second stage module dropped into a machine infected with TrickBot. As TrickBot has already been described and researched extensively, we will focus solely on TrickBooster.

Trickbooster’s First Stage

TrickBooster conceals its content very well. It stores its payload encrypted, decrypts it in runtime to be finally loaded and executes using Process Hollowing.

Trickbooster’s first stage consists of three components:

  • PE resource - encrypted and encoded in base64
  • Shellcode A - XORed by key and encoded in base64
  • Shellcode B - XORed by key and encoded in base64

These components are extracted and run in the following order:

  1. The PE resource is decoded in base64.
  2. Shellcode A and B are decoded in base64.
  3. Shellcode A and B are extracted using a key to XOR them.
  4. Shellcode B is executed, the shellcode decrypts the RSA2 encrypted resource – and voila – a PE appears.
  5. Shellcode A is executed and uses Process Hollowing to self-inject and execute the PE.

Now that we’ve reviewed the flow at a high-level, let’s get more technical and detailed.

The first thing TrickBooster does is look for a resource named FCVDSSXZA. After the resource is found it is copied to a buffer and then decoded in base64. For now, the resource is not fully opened and will be decrypted later. At the next step the malware concatenates strings using std:string and then decodes them in base64, this gives us a XORed shellcode – shellcode A. This step is repeated with different strings creating a second XORed shellcode – shellcode B.

Both of the shellcodes are extracted using a key to XOR them.

When both shellcodes are extracted TrickBooster creates three mapped files backed by the system paging file with RWX protection. Both shellcodes are copied to two of the mapped files and the resource is copied to the third.

TrickBooster is now ready to start the decryption of the resource. Shellcode B is executed and is in charge of decrypting the PE resource. It receives four arguments resourceSize, mappedResourceAddr, keySize, reversedKey.

The shellcode loads ADVAPI32.dll and then uses GetProcAddress for calling cryptography functions which will be used for the decryption. Now the shellcode creates an RSA2 key that will be used to later open the reversedKey. The reversedKey argument is reversed and then decrypted using the RSA2 key, this key is used for RC4 encryption/decryption.

Last, the shellcode opens the resource using the the RC4 key, to do so, it uses the function CryptEncrypt instead of CryptDecrypt since RC4 is synchronous.

When Shellcode B is done, Shellcode A is executed. The shellcode receives two arguments resourceSize, mappedResourceAddr. The purpose of this shellcode is to perform Process Hollowing to execute the resource.

The shellcode first finds kernel32 and ntdll by looking in the PEB, then a method also used by Meterpreter is utilized to find the needed functions (using ROR and a hash).

The path and command line of the current process are searched for and then a new suspended process is created using the path and command line found. The suspended process is used for the Process Hollowing of the resource.

The resource carries the main functionalities described in our previous blog post. An interesting flow that occurs when TrickBooster runs on 64B machines is the dropping of yet another module – TrickBooster second stage (which is a third stage taking TrickBot into account as well).


TrickBooster 2nd Stage

From our research of the internal module we’ve conducted so far, we’ve come to the conclusion that its sole purpose is to connect specifically to OUTLOOK in order to harvest email addresses. It does so by using Outlook MAPI (Outlook Messaging API). The second stage will iterate through every folder in the victim's email (inbox, drafts, sent etc.) and collect the email addresses of both senders and recipients.


It then adds up all information into a zip file (using zlib) by dividing the zip into three files:

email_address - the file containing the domain that Outlook is connected to, and a list of email addresses

outlook_platform - whether Outlook is 32/64 bit

outlook_version - as the name implies, Outlook version

Right after writing the zip – this module terminates itself and control goes back to the parent process.


Our research into TrickBooster continues, as well as our monitoring of its activity in the wild. We will continue to update on our findings as they become available. So, stay tuned!


IOC Update

Shared Certificate


  • TrickBooster signed sample:



Additional Certs (so far only seen used to sign TrickBot, not TrickBooster)




TrickBooster hashes (SHA256)




TrickBooster C&C