Infoblox Threat Intel

infoblox:blogs/category

2021-03-19T13:49:20

12 minutes

Malicious Activity Report: Trickbot Loader

Malicious Activity Report: Trickbot Loader. Recent activity from a Trickbot campaign targeting the insurance and legal sector1 shows that the botnet is still a threat, despite U.S. Cyber Command’s attempt to disrupt it in October 2020.2 Given the potential impact of this threat, we are releasing this detailed report on Trickbot’s functionality to provide our customers and security researchers with the knowledge to prepare for and defend from potential Trickbot-related threats.

/fragments/blog/author/infoblox-threat-intel

/fragments/blog/share/social-links

On this page

/fragments/contact-sales

Author: Andreas Klopsch

TLP:WHITE

Executive Summary

Recent activity from a Trickbot campaign targeting the insurance and legal sector¹ shows that the botnet is still a threat, despite U.S. Cyber Command’s attempt to disrupt it in October 2020.² Given the potential impact of this threat, we are releasing this detailed report on Trickbot’s functionality to provide our customers and security researchers with the knowledge to prepare for and defend from potential Trickbot-related threats.

In this report, we describe Trickbot’s packer and process execution chain, provide insight on identifiers generated by the malware, as well as detail its signature verification and persistence techniques. We include an explanation of the configuration and how it is decrypted during execution, along with an overview of the network flow and the capabilities of the command and control (C&C) protocol.

Trickbot uses string encryption, and so to support other researchers, our full report includes a script to decrypt strings embedded in the sample we analyzed.

Overview

Trickbot, first observed in 2016,³ has transformed from a standard banking trojan into a highly modular loader used by financially-motivated cybercriminals, as well as by threat actors linked to nation state activities.⁴ Trickbot is sold as malware-as-a-service (MaaS) and has been linked to multiple security events⁵ in the past. The following timeline shows a list of events related to Trickbot:

Figure 1: Timeline of published security events related to Trickbot

We have seen Trickbot-related indicators, as well as malspam campaigns distributing Trickbot in our own data sources. Since its first appearance in 2016, the malware authors behind Trickbot have developed different kinds of modules⁶ for capabilities such as:

Stealing banking information,
System/network reconnaissance,
Credential and user information harvesting,
Network propagation, and
Achieving persistence in a victim’s environment.

Trickbot is polymorphic, and as a result, the behavior and characteristics may differ between variants.

Analysis

Initial Execution, Packer and Payload Injection

Sandbox analysis⁷ shows that an Excel macro downloads the Trickbot payload, which masquerades as a PNG file from a malware distribution domain. Next, it executes the Trickbot payload via rundll32.exe. This executable already exists by default on Windows systems and is not dropped by the Excel document or the packer. The rundll32.exe process spawns a child process of itself that masquerades as a legitimate Windows tool but that injects the Trickbot payload into the 64-bit version of the Windows Error Reporting tool wermgr.exe via process hollowing.

Figure 2: Trickbot process execution chain

The Trickbot loader has an evasive packer that uses a variety of anti-analysis techniques to prevent researchers from debugging and diving into the packer itself. Since the focus of this paper is analyzing the behavior of the loader, we do not include an analysis of the packer itself; however, we did identify the following anti-analysis measures:

SMulti-stage unpacking process,
Junk instructions,
Control flow obfuscation,
Section hashing to detect software breakpoints, and
Encryption/decryption of code chunks prior to and after function-calling.

Obfuscation

Trickbot uses string encryption to hamper reverse engineering. The encrypted strings are embedded in an array, and each time one is decrypted, an offset is pushed as a parameter onto the stack to determine which string/array element to decrypt. Figure 3 below provides an example of encrypted strings in a disassembler; we have placed the decrypted string next to each as a comment. The snippet in Figure 4 provides Python code for researchers to decrypt strings on their own.

Figure 3: Array of encrypted strings

Figure 4: Python code snippet for string decryption

ID Generation

Prior to communicating with its C&C, Trickbot generates different kinds of identifiers, some of which are used to give the attackers information about the victim’s system when they are exfiltrated via the C&C protocol. We also believe that some of them are used to distinguish between different infections and/or campaigns. We confirmed several identifiers:

Client ID

Trickbot uses the client ID to identify the victim. First, the malware retrieves the computer name via the Win32 API GetComputernameW.8 It then appends “W_” and the operating system (OS) version information retrieved via GetVersionExW. Finally, it appends a randomly generated string with a length of 32 bytes. Our analysis system generated the following client ID:
Adapter ID

The malware generates a SHA256 hash of the local computer’s network adapters, which is retrieved via GetAdaptersInfo. Finally, it hexlifies the generated hash. On our analysis system, the malware generated the following SHA256 value:
Hard-Coded ID

Trickbot embeds a four-digit number into the binary as an encrypted string, which is used for C&C communication. The number is not identical for each binary. When Trickbot sends out the C&C request to register the victim in the botnet, it appends this ID to the HTTPS request. The purpose of the identifier is unclear, but it is possible that the C&C server uses it to distinguish among different versions of the malware. Researchers sometimes refer to this as a Build ID.⁹ On our analysis system, the malware embedded the following hard-coded ID in the binary:
WinVersion ID

Trickbot determines the victim’s Windows version by calling GetVersionExW and GetNativeSystemInfo. The first retrieves a structure named OSVERSIONINFOA, which holds enough relevant information to determine the Windows System. GetNativeSystemInfo retrieves the system’s architecture. For our analysis system, Trickbot detected the following environment:

Configuration

Trickbot embeds an encrypted configuration file in XML format, which is obfuscated by two encryption layers. In the first layer, the config buffer is decrypted with a 16 byte XOR key. In the second layer, the XOR’ed config buffer is decrypted via AES Cipher Block Chaining Mode¹⁰ with a custom initialization vector.

The AES key is generated by taking the top 32 bytes of the XOR’ed config buffer and copying it into a separate buffer. Next, the malware generates a SHA256 hash of the 32 bytes and appends it to the end of that same buffer. The malware continues to generate SHA256 hashes of the whole buffer and appends the new SHA256 128 times. The final generated hash is the AES Key. In Figure 5 below, we provide a graphical overview of the configuration decryption routine. In the bottom box of the diagram, “IV” is an abbreviation for the custom initialization vector used for decryption.

Trickbot generates the initialization vector in the same way, except that rather than taking the top 32 bytes, it skips the first 16 bytes.

Figure 5: Graphic explaining config decryption layers

When we extracted the configuration from the Trickbot loader, one of the things we found was a list of IP addresses with tags. The table below provides the meaning of the tags from the config:

Tag

Description

Notes

ver

Binary version

gtag

Campaign marker

Changes from binary to binary

srv

C&C server IP address

srva

Fake C&C server IP address

This is later transformed into a valid C&C server

autorun

Value, to determine which module to run on default

In this case, run pwgrabber module

IP addresses embedded with the srva tag are addresses that do not contact a valid C&C server but are deliberately added to confuse security researchers. During config parsing, Trickbot uses an algorithm to transform these into valid IP addresses.

Signature Verification

Trickbot uses PCS30 signature verification to check whether embedded or received resources are valid. For decryption, Trickbot uses the same XOR process as it used for the first step of AES key generation. The algorithm used to validate signatures is ECDSA_P384.¹¹

We have confirmed that the analysis sample verifies the configuration files and the modules sent by the C&C server but there could be additional fragments that it verified as well.

Figure 6: Hexdump of extracted ECC public key blob; used for signature verification

Persistence

The Trickbot loader will try to achieve persistence via task scheduling on the victim’s system. The malware first creates a directory in the AppData\Roaming folder. It will then drop an executable into this folder and set a scheduled task to run with the highest privileges possible on System Startup.

Other reports state that the scheduled time differs between variants, just as there is variance in the tool that the malware masquerades as.

Figure 7: Screenshot of Task Scheduler in Windows with task created by Trickbot

C&C Communication

The Trickbot loader communicates with its C&C server over HTTPS. The different C&C instructions are separated by a specific command ID, which is always embedded in the HTTPS request/response that the server and client exchange with each other.

Client-based and server-based commands can be differentiated because client-based commands are C&C requests sent from the victim machine to the server. Researchers from Fortinet^12,13 analyzed the Trickbot botnet, which assisted with our analysis of C&C communication.

Client-Based

Apart from command 63, which uses HTTPS POST to exfiltrate data, all C&C requests from clients are GET requests. They are sent in the following form:

The gtag is an XML value in the config, and the client ID was previously generated by the binary from the operating system information and the username, as well as a randomly generated string. We were able to extract the following commands:

Command ID

Command

Notes

Keep alive

Stay idle, keep connection

Download module

Request module from C&C server

Log module/command execution

Also used for OS setting exfiltration

Log module execution result

Sends logging messages

Update base config

Update configuration

Update bot

Update bot to newer version

Report captured traffic of InjectDll module

InjectDll module is also used to steal banking information

Probably exfiltration

Includes indications that this command is used for exfiltration

Capability to add boundaries14 to HTTP header (boundaries are often used when downloading or uploading files over HTTP/HTTPS)

Server-Based

Responses received from the C&C server are sent in the following format:

We were able to identify the following instructions:

Command ID

Command

Notes

Keep alive

Stay idle and keep communication with client

Download and execute module

Download a module and execute it

Related to RDP

This command uses WINAPI calls related to Remote Desktop Protocol

Execute command

Execute a single command delivered in the C&C response

Download and inject module

Download a specific module and inject it into process

Update bot

Update bot with never version

Attack Chain Narrative

Trickbot is a very modular trojan and will therefore try to download specific modules depending on its configuration and the instructions issued by the actor.

First, it tries to contact its C&C server and issue a C&C request with command ID 5, to download a module. We believe this command is intended to download the pwgrabber15 module, which is included in the AutoRun config tag, and is used to steal different kinds of passwords from an infected system. However, during our analysis, we were not able to fetch the payload because the C&C server was already offline. The user-agent is hardcoded into the binary and decrypted via the string decryption algorithm we provided earlier in Figure 4 of Section 3.2.

Figure 8: Initial HTTPS GET request to download an additional module

Next, the Trickbot loader fetches the victim’s external IP address using one of multiple legitimate domains that offer this service. The following figure is an example of an HTTPS request to identify the IP address.

Figure 9: Identifying external ip via externalip[.]com

Trickbot also checks whether the client is behind NAT and informs the C&C server:

Figure 10: Informing C&C server whether client is behind NAT

Afterward, it attempts to register the bot via command 0 and tries to exfiltrate the following information:

Windows version of victim’s system,
SHA256 value of adapter info, and
External IP address

Figure 11: Exfiltrating OS network settings and registering the botnet

The complete registration command follows this pattern:

After registration, Trickbot sends out logging messages to its respective C&C server via command ID 14. The following two GET requests show that the binary tries to exfiltrate information about the execution environment. This includes the user executing the file and the path of files related to Trickbot.

Figure 12: Sending out logging messages to inform on module execution

Since we are hijacking Trickbot’s behavior, the file it tries to execute does not exist on the analysis system. As a result, it sends two other C&C requests informing the server that the execution failed:

Figure 13: Sending out logging messages to inform on module execution

It first sends out a C&C request with command ID 10 and the digit 62 appended immediately afterward. This informs the C&C server that the next request will contain logging messages regarding the process for downloading and injecting a module.

Conclusion, Recommendations and Mitigation

This report provides security departments with a detailed analysis of Trickbot to proactively prepare against this type of threat. The insights into Trickbot’s algorithms and configuration are intended to aid researchers in their analysis, and providing the C&C protocol capabilities and persistence mechanism is intended to assist in detecting already existing Trickbot infections.

In October 2020, a joint operation of law enforcement and tech companies attempted to take down the Trickbot botnet. The actor(s) behind Trickbot returned two months later in a campaign with newly developed modules, demonstrating they are able to recover quickly following a compromise of their infrastructure.

We expect that Trickbot will continue to grow and evolve. In order to prevent, detect and mitigate threats regarding Trickbot, we recommend the following:

Use properly updated endpoint protection systems. Trickbot is well known and security teams should stay up-to-date with the author’s changes.
Install a network security solution. BloxOne Threat Defense can prevent malware from contacting its C&C for exfiltration.
Implement malspam protection. Distribution via malspam attachments is a common attack vector for Trickbot. Always treat email attachments with caution. If unsure, contact your company’s security team.
The National Cyber Security Centre of the UK have collected a number of tips on how to deal with Trickbot: https://www.ncsc.gov.uk/news/trickbot-advisory

Endnotes

Article Tags

infoblox:blogs/tags/domain-impersonation-threats
infoblox:blogs/category/ai