Analyzing Tinba: Configuration Data

Post & Analysis by: Mikko Suominen

Tinba made its entrance into the malware scene a couple of years ago and at the moment, it stands as one of the most popular banking trojans out there. Amongst its noticeable features are the inclusion of preloaded configuration and the implementation of advanced encryption methods to increase its efficiency during operation and to reduce its chance of being dissected.

In this blog post, we’ll focus on the configuration data, specifically on how to extract the configuration data from process memory. The reason why we (and some of you out there) are interested in the configuration data is because this information could help us understand how it operates and who the targets are.

Cracking the XOR encryption

Tinba is known for its form-grabbing and web injection capabilities, which it uses to steal banking credentials from users who unknowingly visited compromised sites. It makes its way into a system mostly via spam emails and exploit kits.

Once downloaded, the form-grabbing and web injection configurations are stored on the disk, protected by XOR with a 4-byte key followed by RC4 and finally ApLib compression. The XOR key is the name of the folder where Tinba files are located, converted from strings to an integer. If no configuration files were downloaded, Tinba will resort to using the prebuilt configuration data from within its binary. This data uses the same encryption as the files minus the XOR encryption.

The XOR encryption is implemented to tie the configuration files to a particular machine. By using a combination of machine and botnet specific data as the XOR key, someone with no access to the infected machine would face a huge challenge in decrypting the files.

Decrypting the configuration files

However, decrypting the files might be unnecessary as Tinba’s method of hiding its configuration data is remarkably poor by modern standards. Both the form-grabbing data and web injection data are fully decrypted and decompressed to be stored permanently in the web browser memory. This is quite careless since other banking trojans tend to jealously guard their configuration data and will only decrypt the data as needed and then immediately wipe the decrypted data from memory once it is no longer needed.

Oversight in memory allocation?

To make matters even easier, Tinba’s author has coded the memory allocation for the configuration data very lazily. Instead of allocating only the necessary amount of memory for the specific data, the author decided to allocate a hard-coded amount of memory large enough to guarantee that any configuration data would fit. Consequently, the large 0x1400000 byte memory block stands out like a sore thumb in the web browser memory space. The form-grabbing configuration data is held at the beginning of the area while the web injection data can be located at the offset 0xa00000 within the area. Both blobs of data begin with the size of the configuration data.

As an example, the following is one entry for the web injection data received by this sample – 9c81cc2206c3fe742522bee0009a7864529652dd.

Tinda web injection data

This sample indicates that the target is a banking institution in Poland.

Similarity to Zeus’ format

If Tinba’s configuration data looks eerily similar to you, it is because it follows the same format used by Zeus and many other malware families. The format has apparently turned into a bit of an industry standard for crimeware because it enables the same malicious web injections to be used on different botnets.

It would be interesting to find out how different malware authors ended up using the same format for their malware’s configuration data. We can assume that the web injection data is not developed by the botnet owner but bought from a third party. If that’s the case, agreeing on a certain configuration format would require cooperation between multiple web injection developers with multiple malware developers. Perhaps it just happens organically because a few years ago Zeus had such a large market share that it make sense for other authors to use the same format to make web-injection procurement easier for customers.

Mikko Suominen is a Senior Analyst on our Remediation team.

Further reading: The Evolution Of Webinjects (VB2014 paper) by Jean-Ian Boutin.

Articles with similar Tags