Application Tier

Trickbot Gets Trickier by Adding an Encryption Layer

blog

4 min. read

By Daniel Frank, Julia Karpin

Trickbot is one of the most prevalent financial threats in recent years. F5 Labs has published numerous articles about TrickBot as we’ve tracked its progression from purely a banking trojan to one that targets credit card companies and wealth management services. Trickbot is known for its resilient infrastructure: command and control (C&C) servers set up on hacked routers, many unique C&C IP addresses, and regular updates, which make the malware’s infrastructure hard to take down.

Conveniently for us, Trickbot’s orderly developers keep track of the changes by enumerating each updated botnet version. The list of available servers and the campaign ID are hard-coded into each sample’s resource section and are later saved to an encrypted file on the victim’s machine.

Sometime around version 1000238 (and still working in version 1000255), Trickbot added an extra encryption layer to its main configuration file, breaking our automated decryption process. Before this change, we could decrypt the main configuration (originally named “config.conf” and later renamed to “info.dat”) using scripts available online such as hasherezade’s tool,1 which still works on Trickbot’s other modules. Another option we could use before the change was to apply kevthehermit’s tool2 directly on the config hidden in the unpacked sample’s resource section. This still works, but only after we unpack the sample and dump its resources using a tool like Resource Hacker,3 for example. However, this requires another automation process or manual analysis to handle the unpacking.

So, after identifying our two options—writing an unpacking automation or investigating the new encryption layer—we decided the fastest path was to find out what has changed in the encryption algorithm of the file’s contents.

Our goal was to stop the malware right after it reads the file’s content into its memory space and then follow the encrypted content buffer to see which functions are used to manipulate it. During its installation, the malware extracts the server list from its resources using a different algorithm. That is why we deleted the scheduled task it used for persistency, restarted the machine, and then started it in a debugger. We set a breakpoint on the relevant call to “ReadFile” when the malware decrypts the config for its own use.

Once the breakpoint was hit, we started to search the function that was decrypting the file’s contents. Eventually, this was what we found:

Figure 1: Loop decrypting the main configuration’s first stage

Figure 1: Loop decrypting the main configuration’s first stage

What we see in the dump view is the encrypted buffer that is about to be decrypted. In the code view, we can see the loop that performs a four-byte XOR on each DWORD of the encrypted buffer while decrementing the key’s value by one in each iteration.

The key and the configuration’s length are hardcoded into the configuration file itself. The first DWORD is the key, and the second DWORD is the configuration’s length, so the content of the configuration itself starts at offset 0x8:

Figure 2: Configuration structure highlighted

Figure 2: Configuration structure highlighted

Figure 3: The four-byte XOR loop in IDA

Figure 3: The four-byte XOR loop in IDA

To automate the process of this additional stage of decryption, we wrote a short Python script (included in the Appendix section). After the script runs, we can redirect the output to the tools mentioned above and decrypt it as we have done before.

While debugging the sample, we noticed that Trickbot does not unveil all its imported WinAPI functions. Instead, Trickbot generates API calls by using a function table containing addresses to the relevant WinAPI functions, which it resolves dynamically at launch time.

Figure 4: Dynamically resolving Windows API functions

Figure 4: Dynamically resolving Windows API functions

In conclusion, sometimes changes, even minor ones such as this one, are enough to break a working automation process, and they require some time to investigate. That’s how the malware’s authors gain precious time to defraud unsuspecting victims before security vendors can blacklist their servers.

As a reminder, Trickbot consistently uses email spam and phishing campaigns as its initial attack pattern, so it’s imperative that organizations train their users how to recognize potentially faked emails, and not to open suspicious file attachments or click on questionable embedded links. A web application firewall can also help your organization detect and mitigate banking trojans.

Daniel Frank is a security researcher for F5 Networks. His core roles include developing security-driven code, researching emerging threats, and dynamically analyzing and reverse-engineering malware. Prior to joining F5 in 2018, Daniel was a security researcher at RSA. He has presented at various security conferences; the most recent was RSA Conference 2018 APJ.

Julia Karpin is a senior malware researcher on the F5 security research team. She has been dealing with financial malware and its shenanigans for most of the current decade. Her main interest is Windows and Android malware, reverse engineering and automating every research aspect that can be automated. She has been a speaker at various security conferences, including REcon (@reconmtl), Virus Bulletin (@virusbtn), and OWASP Israel (@OWASPIL).

Need-to-Know

Expertly picked stories on threat intelligence

Hundreds of apps will be attacked by the time you read this.

So, we get to work. We obsess over effective attack methods. We monitor the growth of IoT and its evolving threats. We dive deep into the latest crypto-mining campaigns. We analyze banking Trojan targets. We dissect exploits. We hunt for the latest malware. And then our team of experts share it all with you. For more than 20 years, F5 has been leading the app delivery space. With our experience, we are passionate about educating the security community-providing the intel you need to stay informed so your apps can stay safe.

Every

9 hrs

a critical vulnerability—with the potential for remote code execution—is released.