A Blog Series on The Banking Malware That Faded Away in 2017
According to IBM X-Force data, several major cybercrime groups that operate banking Trojans have slowly relinquished center stage in 2017, and for no apparent external reason. These groups include: Shifu, Tinba, Neverquest, Qadars, and GozNym – all of which have gradually faded away, or are nearing hiatus in 2017. Where were these malware codes before, and where are they today? This blog series reviews their history and tracks the current status of each Trojan. In this blog post, we focus on Tinba.
No One's Missing the Tinba Bunch
The Tinba Trojan (aka TinyBanker, Zusy) was first discovered in the wild in mid-2012 – dubbed ‘tiny' due to a slim 20KB file size, which included its configuration and web injection kit.
This malware started out as classic banking Trojan, designed to grab user credentials and network traffic. The first Tinba release sported a form grabber to steal usernames and passwords, and a web injection mechanism for man-in-the-browser (MitB) attacks.
Although Tinba began as an exclusive tool used by its developers' gang, the project began evolving in other directions from the moment its source code was surprisingly leaked in mid-2014. The code leak gave immediate rise to two more Tinba variations, which were each taken up by different cybergangs, spawning Tinba v2, and Tinba v3. Each of those varieties was a fully independent Trojan project, clearly developed and updated by different individuals.
In 2015, another addition to the Tinba bunch included a fourth variation (Tinba v4), proving that yet again, a new gang took the source code and revamped it to create their own banking Trojan. In late June 2015, this v4 gang lured in victims via a malvertising campaign that led them to an exclusive exploit kit dubbed “HanJuan”, through which Tinba v4 was dropped to vulnerable endpoints.
But it's called “the Tinba bunch” for a reason… A Tinba v5 also existed in the not so distant past! According to X-Force research, in 2016, yet another version of Tinba code was used as a remote administration tool. Leveraging proxy-changing capabilities, it was used in pharming and phishing attacks, and mostly targeted bank customers in Eastern Europe.
Most Prevalent: v3
Of all the Tinba variations observed by X-Force in the wild, Tinba v3 was the most active project in the sense that it was more prolific, and appeared to be used simultaneously by more than one group, leading us to believe it was possibly commercially available in underground forums.
In terms of its capabilities, right from its emergence in mid-2014, Tinba v3's developer invested extra work into features that were designed to enhance the Trojan's detection evasion capabilities, the bypass of automated security controls, and its ability to “phone home” even when the original Command & Control servers were down. Botmasters typically strive to protect their botnets from potential hijacking and takedowns, and Tinba v3's developer took extra care to ensure that its fallback mechanisms would secure the illicit “business continuity”.
For its fraudulent transactions, Tinba v3 relied on four principal Trojan features:
- A persistent user-mode rootkit
- Ability to steal any set of credentials with a generic form grabber
- Man-in-the browser (MitB) capabilities
- Deployment of dynamic web injection mechanisms
To launch social engineering windows and to manipulate web sessions, Tinba v3 used a few browser injection approaches. For example, the Trojan incorporated an “Automated Transfer System” (ATS) panel into its operational flow to orchestrate the fraudulent transactions its operators attempted.
ATS works with the Trojan's MitB capabilities to launch transaction automation scripts on the fly, dictate pre-programmed parameters and thresholds for the fraudulent transfer, and specify mule account numbers that the malware would use to complete illicit transactions.
Since it is an automation tool based on a given flow of events, ATS was much more popular before multi-factor authentication schemes came into the security equation. To bypass that hurdle, Tinba worked more elements into its ATS, adding dynamic web injections that popped-fake messages on the victim's screen, designed to ask for the second factor one-time password in real time, and then plug into the bank's page to complete the fraudulent transaction nonetheless.
Another interesting web-injection approach Tinba v3 used in its configurations is known as “FI-Grabbers” in fraudster lingo. It stands for “Full Information Grabber” – an elaborate web injection that asks the victim to divulge a large set of details about their account, and their personally identifying information (PII). These grabbers were accessed on a remote server and automatically matched a web injection with the bank site the victim was browsing.
In and of themselves, FI-Grabbers are actually a paid cybercrime service that delivers web injections that will require “the right type of data” from the victim to supposedly lead to a successful transfer. The advantage the Tinba cybergang had with these grabbers is to keep their injection details out of the configuration files, delivering them only on the fly, and thus hidden from most security researchers.
Below, a snippet from Tinba v3's configuration file shows the injections calling to the FIGrabber.
Figure 1: Tinba configuration calls a remote FIGrabber injection – Source IBM X-Force
Overall, Tinba v3's typical fraud scenario was similar to other banking Trojans' tactics: collect victims' credentials, grab personally identifying information (PII), use social engineering to steal two-factor authentication codes, and finalize the illicit transfer. The fraudulent transactions were initiated in-session, from the victim's own device, using a remote access module.
Zones of Activity
X-Force data from the past two years shows that in 2015 Tinba variants were active in Germany, Italy, the Netherlands, Poland, and Romania. It was observed in Singapore and Indonesia, likely operated by a local group late that year. The malware was also active in Russia and Japan around the same period.
In 2016, Tinba v3 variants were mostly focused on UK banks; however, according to X-Force data, Tinba stopped infecting new machines only four months into 2016, and has remained inactive in that sense since.
Slow Death?
During its prime, Tinba v3 was rather active in the cybercrime arena, and according to X-Force data, in Q1-2016, it still ranked in the top-5 of the most prevalent banking Trojans on a global scale. But for some reason, Tinba did not persist. In spite of being a relatively well-known code, and used by different groups, it seems all variations met their demise at around the same time.
The malware's activity gradually decreased, until it all but disappeared in 2017.
X-Force data from the past 12 months shows that Tinba campaigns were extremely small throughout the entire period, and took a continuous downward trend in attempted infections, which signifies that the gang had stopped launching infection campaigns altogether, or did not manage to infect new endpoints with the existing payload.
Figure 2: Tinba trend of infection attempts on clean endpoints – Source IBM X-Force
Beyond the decline in attempted infections, existing infected machines gradually stopped seeing illicit access activity to their owners' bank accounts. That activity plunged sharply in July 2017, seeing a 96% decline in activity from its highest peak for the year, recorded in June 2017.
Figure 3: Tinba trend of attempted illicit access on infected endpoints – Source IBM X-Force
Natural Death or Takedown?
With no particular reason, what would make Tinba variations fade out at around the same time? Considering the timeline, it is possible that there was a reason, and Tinba's sunset was linked to the major law-enforcement take down of the Avalanche network in 2016.
“Avalanche” was a long-standing cybercrime infrastructure that was rented out to cybercriminals who used it to launch and manage mass malware attacks and money mule recruitment operations spanning the entire globe. Avalanche was taken down in November 2016, but the investigation and the gradual shut down likely started much earlier. Tinba operators were only one of many other malware groups that relied on Avalanche for their campaigns and ongoing malware operations.
It is also possible that the malware simply no longer measured up. Many times, malware developers abandon certain projects and move on to others, leaving the previous code to deteriorate until it can no longer evade even static security detection mechanisms. At that point, all the malware's operators can do is use the existing botnet of infected endpoints they already control, knowing well it is only a matter of time until those too block the malware and escape their control.
Will Tinba be back? In the case of this malware, unlike other codes, I have doubts that we will see Tinba again in its familiar form. At this point in time, there are more leaked codes out there, and more sophisticated projects than Tinba. While anything is possible, Tinba is likely gone until further notice. Of course, one can never predict the course malware may take, and it is always recommended to keep up safe browsing hygiene and system security.
X-Force research always keeps an eye out for changes in the cybercrime landscape. To keep up to date on malware and cybercrime groups, stay tuned to our research blogs on Security Intelligence.com or join IBM's X-Force Exchange where you can set alerts for the subjects that matter to you.
Next Up: GozNym
In our next blog in this series, we will explore the stormy entry and exit of the GozNym Trojan from the malware arena.
