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
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 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
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.
SOURCE: F5 Labs https://www.f5.com/labs/articles/threat-intelligence/trickbot-gets-trickier-by-adding-an-encryption-layer?utm_source=twitter&utm_medium=social&utm_campaign=f5news&utm_content=130918
