Tinba and Tilon are two of the most sophisticated financial malware toolkits available today. These malware authors have created variants to monitor Web sessions between a customer and their bank in real time and change data on-the-fly. For example, after the customer logs in, the malware will hijack the authenticated session to add a new payee and transfer money in the background. This fraud tactic requires that the malware sit inside the customer’s browser, analyze the traffic and react to it based on a deep understanding of how the bank’s application works.

However, banks are deploying protection layers to monitor the online sessions between customers and their Web applications. These security systems are capable of detecting anomalies that indicate malware-initiated activity. Banks that deploy these types of systems are able to effectively detect and block the activity of Tinba, Tilon, Shylock and many other financial malware strains that use this same Man-in-the-Browser tactic.

Malware Authors Backpedal

In the past couple of months, we have witnessed an interesting development in the financial malware space. The IBM Security research team at has detected simultaneous changes in both Tinba and Tilon designed by malware authors to avoid being detected by these systems.

It appears that these malware authors have decided to take a step back. Instead of the traditional method of tampering with the session in real time, the malware now takes a simpler approach. When the customer accesses the bank’s website, the malware presents a completely fake Web page that looks like the bank’s log-in page. Once the customer enters his or her log-in credentials into the fake page, the malware presents an error message claiming that the online banking service is currently unavailable. In the meantime, the malware sends the stolen log-in credentials to the fraudster, who then uses a completely different machine to log in as the customer and execute fraudulent transactions.

If the login or transaction requires two-factor authentication (one-time password tokens, card and reader, etc.), the malware captures this information as part of the fake log-in page. Using this tactic, the malware never lets the customer reach the bank’s log-in page, which prevents back-end security systems from being able to detect malware anomalies in the session and identify the fraud.

What we described above is a simple credentials theft attack that is very similar to the old-fashioned phishing attack. Instead of sending a malicious email that directs the victim to a fake website, the fraudsters are using exploits to install malware on the computer, which inserts a fake online banking Web page in their browser. It isn’t as sophisticated as injecting transactions into Web banking sessions in real time, but it accomplishes its goal of evading detection.

Fraud attempts associated with these new versions of Tinba and Tilon are still limited. For banks that lack security controls to prevent simple credential theft attacks, this could be bad news. Fraudsters will look for new targets they can attack with this downgraded capability.

Fighting These Attacks

Banks have always faced two-attack vectors in the online channel. The first is credentials theft. There are various ways to execute this type of attack, including malware, pharming and phishing. The second attack vector is session hijacking, which is achieved through malware. These two vectors require two different solutions. Session hijacking can be defeated using solutions such as IBM Security Trusteer Pinpoint Malware Detection, which looks for malware-driven anomalies during the session. Credentials theft can be defeated using solutions such as IBM Security Trusteer Pinpoint Criminal Detection, which analyzes log-in attempts, detects behavioral anomalies and correlates it with account compromise events, such as phishing incidents and malware infections.

By controlling the full attack life cycle, it is possible to conclusively determine that the person behind the keyboard is a fraudster and not the real customer. Banks should address both attack vectors at once using an integrated solution that leverages real-time intelligence from both attack vectors. Otherwise, the fraudsters will quickly transition their attacks to exploit the unprotected vector.

The fight against the fraudsters can be won. Banks that address both attack vectors holistically have reduced their fraud losses significantly. You can’t put a lock on your door and leave your window open.

A Deeper Look at Tinba

Below is a technical analysis of the new Tinba variant analyzed by our research group. Tinba is a financial malware discovered by security researchers eight months ago. One of Tinba’s most interesting aspects is its size. At 20 KB, this rather small malware is able to pack all the features you would expect from a financial malware into a tiny package. IBM’s security researchers have recently discovered a new and improved version of Tinba, dubbed “Tinba v2.” Tinba v2 introduces several new features and enhancements:

1. New Web injections method: “full0page replacements,” including local caching
2. New binary configuration structure
3. Plugins support in configuration
4. Support for Chrome injections

IBM researchers have discovered that Trojan developers are investing heavily in stealth capabilities. Staying hidden from the victims and their security products is one thing, but Trojans are also attempting to evade analysis and investigation by security experts. It comes as no surprise that the Tinba v2 developers made sure their malware would remain stealthy during the installation process to hide from security researchers. IBM has already identified that Tinba v2 is targeting major financial institutions as well as consumer Web services.

The following report covers the installation, communication and evasion techniques used by Tinba v2:

Installation

Tinba v2 follows the same installation sequence as its predecessor; it drops on predefined paths under user’s %AppData%, having both folders and executable names hard-coded per instance of the malware. For example:

To stay persistent, Tinba v2 installs on predefined Registry Run keys, such as SketchGo, NikkonE and CanonMul.

Like its predecessor, when executed, it spawns winver.exe and injects from there to explorer.exe, so there is no real process associated with Tinba.

In addition, there is a new binary configuration structure stored encrypted with RC4. The decryption key/size is hard-coded in the executable itself and changes between samples. While still under research, the configuration structure already revealed reserved space for TinbaV2 plugins. One DLL that has already been discovered has SOCKS5 proxy functionality.

Full Page Injections

Unlike the classic Zeus Web injects format, Tinba v2 configuration has sectioned entries that each have a different meaning, as follows:

Entry #0 is pretty self-explanatory — so far, we’ve seen it target mostly Web-based email credentials. The primary new capability Tinba v2 brings to the table is full-page replacements. This is how it generally works:

1. Tinba v2 detects navigation to a bank URL, matching one of the URL patterns for a full-page replacement (entry number one in configuration)
2. Before any communication to the bank’s site, Tinba v2 contacts its C&C server with a Referrer HTTP header, telling the C&C what page to fetch/hijack
3. The C&C sends to the victim the entire requested page, so there is no actual communication with the bank’s site.

The configuration also holds entries for local injections (entries two and three), probably for tactical purposes (for example, hiding security-awareness content in the log-in page). These use a pretty standard, Zeus-like, “Web injects” format.

Taking Tinba’s injection-caching to the next step, entries four and five are resources (mostly GIF and JPG images) from targeted online banking sites. The motivation behind this feature is to avoid excessive traffic to the C&C when replacing full pages, so images and banners are not fetched from C&C server (or the genuine bank website), but rather from the local Tinba v2 configuration on the infected machine.

C&C Communication

Tinba v2 uses the HTTP protocol to communicate to its C&C server. Unlike most malware, though, it utilizes nonstandard HTTP headers. Three new HTTP headers are being used by Tinba v2. First, the X-ID header represents unique identifier for the infected machine, partly generated from the machine’s volume serial number. Second, the X-BN header, we believe, is the Botnet ID or network identifier. The most interesting HTTP header is the response header X-Skip, which looks like a Boolean switch for Tinba v2 to indicate whether to inject the current URL with a full-page replacement.

So far, most C&Cs observed originated from Poland and Germany.

Patching and Hooks

Like its predecessor, this variant injects into browsers using CreateRemoteThread. In addition to previously targeted browsers (Internet Explorer and Firefox using same hooks on WININET and PR_Read/PR_Write), it now targets Chrome, hooking un-exported functions from within chrome.dll.

Anti-Reversing Techniques

Tinba v2 uses several tricks to prevent analysis. First, the code is never injected as a module (PE). This may render automated analysis programs ineffective. Second, it uses a unique “dynamic addressing” method to hide called functions. The method operates in the following manner:

Register ebx is assigned with a fixed offset. In the above snippet, you can see that in address 0x3508B8, register ebx gets the value from the top of the stack, which is 0x3508B8 — abusing the calling convention mechanism. Then, it is subtracted with 0x4022E3, making it 0xFFF4E5D5. This value alone is meaningless. However, it is used as a referencing offset within other functions, as exampled in the following RC4 function:

Needless to say, the offsets may vary in different points of execution and between samples.

Another trick we have seen is the use of polymorphism, to some degree, to make samples look different, e.g. calling to a register instead of direct address.

Below is a list of the Tinba v2 samples that were analyzed:

IBM Security researchers will continue to analyze Tinba v2 samples, so stay tuned for additional information on Tinba v2.