IBM has discovered a new financial malware that is targeting banks with a full bag of tricks for AV detection. Back in 2009 Trusteer, now a part of IBM, discovered Silon, a financial malware that was defrauding online banking customers protected by two-factor authentication systems left and right. In 2010 and 2011, the malware underwent two major updates and continued to do well. Lately, its numbers have been in decline, causing us to wonder whether Silon’s perpetrators were taking a long vacation in prison.

Alas, it is not so. In July 2012 we discovered a new financial malware that, upon closer investigation, contained some behaviors identical to those exhibited by Silon. After some internal debate, we decided to name it “Tilon.”

Tilon: The Newest Threat

So, what does Tilon do? Tilon is a financial malware that employs the Man in the Browser (MitB) approach. It injects itself into the browser and then fully controls the traffic from the browser to the Web server, and vice versa. It has an impressive list of supported browsers, such as Microsoft Internet Explorer, Mozilla Firefox and Google Chrome. It then captures all form submissions (“form grabbing”) from the browser to the Web server, logs them and sends them to its command and control (C&C) server, thereby gaining access to all login credentials, transactions, etc. More interestingly, perhaps, it controls the traffic (Web pages) from the Web server to the browser, and through a sophisticated “search and replace” mechanism, it targets specific URLs and replaces both large and small parts of the pages with its own text.

All of this is pretty standard MitB malware practice today, and Tilon merely provides more or less what Silon did back in 2009 and what Zeus, SpyEye, Shylock and others are capable of today. What is most impressive about Tilon is the breadth of evasion techniques it employs to avoid detection and scrutiny and to survive attacks by security products. Some of the evasion techniques we are aware of include:

  • Tilon will not install properly on a virtual machine. This is a standard practice by some malware these days, as virtual machines are typically used by researchers, not genuine users. Tilon goes one step further, however, and instead of terminating the installation or running idly (both are suspicious behaviors to a small degree), it installs a fake system tool scamware. So, the Tilon dropper is likely to be dismissed as yet another fake system tool, keeping its malicious nature concealed.
  • Tilon installs as a service with a genuine-looking name and with a random executable name. Again, this prevents it from standing out to random scrutiny. Once run, the service injects malicious code into various native Windows processes, then terminates itself, so no malware process is found in memory thereafter.
  • Inside one of the Windows native processes, Tilon starts a watchdog thread that monitors its service entry in the registry and its executable file on disk. If these are tampered with, Tilon restores them within 3 seconds. This mechanism resists removal by many security products.
  • Tilon has a very peculiar way of hooking browser functions, which is the standard implementation of the two MitB concepts — form grabbing and HTML injection. Most malware families replace the first five bytes of the functions they hook with “JMP stub,” where “stub” is the malware code that implements the hook logic. Tilon takes a completely different approach. Once it injects into the browser, it first installs an exception handler for the process (Fig. 1). Then, it overwrites only the first byte of the hooked function with the byte 0xFA, which is the x86 opcode for the Clear Interrupt Flags (CLI) instruction (Fig. 2). This instruction is privileged, so when the CPU attempts to run it in user-space, an exception will be thrown. The exception handler installed by Tilon catches this exception, and it proceeds to run the hook logic and yields execution to the original hooked function thereafter. This unorthodox hooking technique is likely used to evade security products that look for “traditional” hooking techniques on browser functions.

Fig. 1: Installing the exception handler

  • Tilon mutates, we discovered, and it has already mutated once around the end of July or early August. The mutation was around how the random file names are generated, randomizing more parts of the file name.

Detecting Tilon

The net result is very low AV detection of the Tilon dropper (four out of 41 AV engines. These results were obtained on Aug. 8 for sample MD5 92613662ac735c91e7e25b16237c3ac5).

Moreover, the ones that did detect the dropper as malicious categorized it as a “fake system tool” instead of as financial malware (Fig. 3). It should be noted that the Microsoft Threat Encyclopedia contains an entry about a malware called “Win32/Enchanim.gen!B,” which may actually be the initial variant of Tilon. The details in the Microsoft site are too light to know for certain. We aren’t familiar with any specific name for the second variant of Tilon. As the VirusTotal results indicate, it’s not detected as financial malware at all.

There is, however, some good news. IBM’s products are doing well against Tilon. IBM Security Trusteer Pinpoint Malware Detection detects Tilon, while IBM Security Trusteer Rapport prevents its installation, detects its presence in the browser and removes it from already infected machines.

More from Malware

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

RansomExx Upgrades to Rust

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language. Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the…