Beginning in mid-September 2017, we started seeing a new abuse scheme on .ch and .li domains. The websites in question were running on outdated software and inevitably, hackers exploited some well-known vulnerability in order to inject malicious code. At this point we would usually expect an exploit kit in the website’s content with the purpose of infecting the victim’s machine with malware. In these cases however, the Javascript inject often looked somewhat like the following:
This code is designed to run in the background of the victim’s browser and immediately starts an endless loop of intensive computations at full pace, effectively turning the browser into a hash-crunching mule for the sake of distributed mining of cryptocoins, with profits going directly to the hacker.
While Trojans like Dyre and Dridex are dominating malware-related news, we take the time to have a closer look at Tinba (Tiny Banker, Zusy, Illi), yet another Trojan which targets Windows users. In the first part of this post, we give a short historical review, followed by hints about how to detect (and remove) this threat on an infected system. In the second part, we have a look at a portion of the Trojan’s code which enhances its communication resilience, and how we can leverage these properties for defensive purposes.
Tinba is a fine piece of work, initially purely written in assembly. CSIS discovered it back in May 2012, and it contained WebInject capability and rootkit functionality in a binary of just 20 KB. The source code of Tinba leaked in July 2014, helping bad guys to create their own, extended versions.
The source code of Tinba leaked in July 2014. Shown are some preparations to hook ZwQueryDirectoryFile.
Tinba on steroids was discovered in September 2014. Two main features are worth noting: First, each binary comes with a public key to check incoming control messages for authenticity and integrity. Second, there is a domain generation algorithm (DGA), which we will discuss later. In October 2014, Tinba entered Switzerland, mainly to phish for credit card information.
Tinba tried to phish credit card information.
Like other commodity Trojans, Tinba checks whether it is running in a virtual machine/sandboxed environment by checking the hard-disk size or looking for user interaction. According to abuse.ch, there was an intense distribution of Tinba in Switzerland early this year. Such spam campaigns can happen again at any time, so it is of use to know how to detect Tinba on an infected system and remove it.
Even though Tinba has the ability to hide directories and files (rootkit functionality), cybercriminals were wondering why they should bother using it. Why not simply hide directories and files with the “hidden” flag, which works for most users? Thus, it is relatively simple for a computer-savvy user to remove this version of Tinba from an infected (see instructions below).
A randomly named directory, which contains the Trojan itself, can be hidden by setting its attributes to “hidden”.
If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.
Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.
Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.
SWITCH Security-Blog 