Intro

According to the Chinese zodiac 2020 is the year of the RAT, and in accordance with the myth the rat tricked his adversary in order to be ahead of him and “win the race”. The RAT mindset is also a growing trend that ThreatFabric analysts have observed in mobile banking Trojans over the last years. This blog provides an overview of the changes that took place in the last months on the mobile banking threat landscape and describes why we can expect an increase in the use of Remote Access Trojans for fraudulent purposes.

Play on words aside, in the world of malware the term RAT stands for Remote Access Trojan. This functionality can be added to malware in order to provide the criminal operator the same degree of (remote) control of the infected device as its owner/user has.

Remote access can be achieved in different ways, for example by using more-or-less native services such as SSH (Secure Shell) or RDP (Remote Desktop Protocol), or even by using third-party software such as TeamViewer, VNC or RAdmin. We want to stress that those tools by themselves are not inherently malicious and are in most cases used for legitimate purposes, such as providing users with support or perform remote administration (hence calling this type of utilities Remote Administration Tools which can cause confusion). Some malicious actors prefer to develop their own code/tools with the hope to remain under the radar while benefiting of similar functionality.

Historically, mobile banking malware was designed and used primarily to access and steal information that facilitates financial fraud. Examples of such information include second factors of authentication (SMS, mTAN) and other secrets that could be used to perform fraud through the targeted banking services. As fraud detection mechanisms used by financial institutions evolved it became harder for criminals to use aforementioned methods without being detected.

Threat actors have conceived diverse ways to circumvent detection mechanisms by impersonating the victim’s device. A famous one is the use of a back-connect proxy on the infected device combined with device fingerprints, allowing the actor’s device to look like the “real” one. Solutions like device binding and fingerprinting allowed financials to detect such techniques, therefore criminals had to innovate again. In this situation RATs are criminals’ Holy Grail, as they offer the ability to perform fraudulent transactions directly from the infected (victim) device. By doing so, criminals are making it substantially harder to detect fraudulent transactions without a client-based detection solution.

In Android banking malware, the RAT capability has not been commonly used due to limitations of the Android operating system (it requires use of the Accessibility Service). Nevertheless, back in 2016 the “Retefe” threat actors were already observed making use of RAT functionality by abusing the TeamViewer application, giving them full control over the infected device. As Retefe is run by a group of experienced Windows malware actors and because RAT capabilities are quite common in Windows banking malware, the actors probably decided to reuse that approach with Android devices as well.

Threat actors motivated by financial gain have noticed the shift of consumers from desktop towards mobile based online banking. This trend has also resulted in the evolution of mobile malware in order to bypass detection measures. From simple SMS-stealer to fully-fledged RAT with Automated Transaction Systems, criminals continuously innovate to try to remain successful. Hereafter is an overview of recent changes made by some key players in the Android banking malware threat landscape.

Cerberus

The Cerberus banking Trojan that appeared on the threat landscape end of June 2019 has taken over from the infamous Anubis Trojan as major rented banking malware. While offering a feature-set that enables successful exfiltration of personally identifiable information (PII) from infected devices, Cerberus was still lacking features that could help lowering the detection barrier during the abuse of stolen information and fraud. Mid-January 2020, after new-year celebrations, Cerberus authors came back with a new variant that aimed to resolve that problem, a RAT feature to perform fraud from the infected device.

This new Cerberus variant has undergone refactoring of the code base and updates of the C2 communication protocol, but most notably it got enhanced with the RAT capability, possibility to steal device screen-lock credentials (PIN code or swipe pattern) and 2FA tokens from the Google Authenticator application.

The RAT service is able to traverse the file system of the device and download its contents. On top of that it can also launch TeamViewer and setup connections to it, providing threat actors full remote access of the device.

Once TeamViewer is working, it provides actors with many possibilities, including changing device settings, installing or removing apps, but most notably using any app on the device (such as banking apps, messengers and social network apps). It can also provide valuable insight into victim’s behavior and habits; in case it would be used for espionage purposes.

The following snippet shows the code responsible for TeamViewer login and initialization:

String runningPackage = this.lowerPkgName;
if(getNodeFromEvent.contains("com.teamviewer.host.market")) {
    AccessibilityNodeInfo username = AcccesibilityUtils.getNodeFromEvent(event, "com.teamviewer.host.market:id/host\_assign\_device_username");
    AccessibilityNodeInfo password = AcccesibilityUtils.getNodeFromEvent(event, "com.teamviewer.host.market:id/host\_assign\_device_password");
    AccessibilityNodeInfo submit = AcccesibilityUtils.getNodeFromEvent(event, "com.teamviewer.host.market:id/host\_assign\_device\_submit\_button");
    if(username != null) {
        this.teamviewerUsername = this.utils.readShPrStr(this, this.strings.connect_teamviewer);
        if(!this.teamviewerUsername.isEmpty()) {
            this.teamviewerPassord = this.utils.readShPrStr(this, this.strings.password);
            this.credsSubmitted = false;
            this.passwordFilled = false;
            this.userFilled = false;
            this.permissionStatus = 0;
            this.utils.writeShPrStr(this, this.strings.connect_teamviewer, "");
            this.utils.writeShPrStr(this, this.strings.password, "");
        }
    }

    if(this.permissionStatus == 0) {
        AccessibilityNodeInfo v7\_7 = AcccesibilityUtils.getNodeFromEvent(event, "com.teamviewer.host.market:id/action\_bar_root");
        if(v7_7 != null && AcccesibilityUtils.getNodeFromEvent(event, "com.teamviewer.host.market:id/buttonPanel") != null) {
            this.permissionStatus = 1;
            AccessibilityNodeInfo tmButton = AcccesibilityUtils.getNodeFromEvent(event, "android:id/button1");
            if(tmButton != null) {
                this.acc_utils.clickButton(tmButton);
            }

            AccessibilityNodeInfo klmCheckBox = AcccesibilityUtils.getNodeFromEvent(event, "com.samsung.klmsagent:id/checkBox1");
            AccessibilityNodeInfo klmConfirm = AcccesibilityUtils.getNodeFromEvent(event, "com.samsung.klmsagent:id/btn_confirm");
            if(klmCheckBox != null && this.permissionStatus == 1) {
                this.acc_utils.clickButton(klmCheckBox);
                this.acc_utils.clickButton(klmConfirm);
                this.permissionStatus = 2;
                Utils utils = this.utils;
                utils.launchPkg(this, "com.teamviewer.host.market");
            }
        }
    }

    if(!this.teamviewerUsername.isEmpty() && !this.teamviewerPassord.isEmpty()) {
        if(username != null && !this.userFilled) {
            this.acc_utils.setInput(username, this.teamviewerUsername);
            this.userFilled = true;
        }

        if(password != null && !this.passwordFilled) {
            this.acc_utils.setInput(password, this.teamviewerPassord);
            this.passwordFilled = true;
        }

        if((this.userFilled) && (this.passwordFilled) && !this.credsSubmitted) {
            this.permissionStatus = 0;
            this.acc_utils.clickButton(submit);
            this.credsSubmitted = true;
            String v0_9 = this.utils.readShPrStr(this, this.strings.hidden);
            if(v0_9.equals("true")) {
                this.goBack();
            }
        }
    }
}

The feature enabling theft of device’s screen lock credentials (PIN and lock pattern) is powered by a simple overlay that will require the victim to unlock the device. From the implementation of the RAT we can conclude that this screen-lock credential theft was built in order for the actors to be able to remotely unlock the device in order to perform fraud when the victim is not using the device. This once more shows the creativity of criminals to build the right tools to be successful.

Abusing the Accessibility privileges, the Trojan can now also steal 2FA codes from Google Authenticator application. When the app is running, the Trojan can get the content of the interface and can send it to the C2 server. Once again, we can deduce that this functionality will be used to bypass authentication services that rely on OTP codes.

This is an example of what the Google Authenticator application looks like:

Until now, the end of February 2020, no advertisement for these features has yet been made in underground forums. Therefore, we believe that this variant of Cerberus is still in the test phase but might be released soon. Having an exhaustive target list including institutions from all over the world, combined with its new RAT capability, Cerberus is a critical risk for financials offering online banking services. Whether in its target list or not, it is easy for its operators to enhance the list to target additional apps (refer to the appendix for the current target list).

Gustuff

The Gustuff banking Trojan, first spotted in 2016, went through quite a long journey of enhancements since its appearance on the threat landscape. Although originally built based on the infamous Marcher malware, it went through a major refactoring, introducing considerable changes in its architecture and feature set.

To the best of our knowledge, Gustuff was the first Android banking Trojan that heavily relied on Android’s Accessibility Service to power its RAT functionality. The RAT was originally implemented to lower detection of fraud but was later enhanced to facilitate automated and large-scale fraud from the infected devices. Unlike Cerberus, Gustuff’s RAT doesn’t use third-party utilities but uses a home-made JSON-based text protocol instead, to both visualize and interact with content of the infected device’s interface.

In April 2019 the actors behind the Gustuff Trojan started developing a new version of the bot alongside the original one in “production”, resulting in the original Trojan being slowly phased out to make place for the new one. Although this process was slow, the new variant started replacing the old one extensively from August 2019 on. After several weeks the swap between versions was finished. Whilst keeping most of the codebase, the new variant of Gustuff introduced changes in the architecture and command handling and added some new features such as keylogging, browser overlays and even an ATS (Automated Transaction System) on top of the RAT.

Although technically being an overlay attack, browser overlays closely resemble the infamous “webfakes” (popular technique used by Windows banking malware), as instead of checking the package name of running apps, the Trojan abuses Accessibility privileges to check contents of the browser’s address bar to determine if the victim is accessing a website from the target list. The browser ends up being overlayed, tricking the victim into interacting with a fake web page.

One of the first browser overlays built by the Gustuff actors was the public Australian government login page:

Unlike Cerberus, Gustuff is operated privately and has its main focus on Australian and Canadian banks. Targeting financial institutions, crypto-wallets but also government websites and job seeking platforms in order to collect more personal information from the victims (see the appendix for targets).

Gustuff was the first Android banking Trojan observed to include an ATS, making it more advanced and efficient compared to other similar bankers. The Automated Transaction System will operate quasi-automatically by stealing victim’s credentials, logging in to its account to verify validity of credentials and availability of funds, and later logging in again to setup and perform fraudulent transactions, all from the victim’s device. Due to its technological stand and focus, the Gustuff trojan is a major threat to all targeted parties in its target list.

Hydra

Having its roots as a “dropper services” as described in our BianLian blog, Hydra went a long way from using outdated overlay attack techniques, to a fully capable banking malware. Although still having such capability, starting from February 2019, Hydra is no longer used as dropper but as a functional and stand-alone banking Trojan.

It features screencast capabilities (like the Anubis Trojan), enabling actors to visualize what is happening on the device in real-time, but also a back-connect proxy option, enabling actors to impersonate the infected device and use it to perform fraud. Some other features include remote app installation, remote screen locking and the possibility to use Google firebase as command handler.

The following screenshots show some of the overlays used against banks operating in Turkey:

Hydra is operated privately and until recently was targeting exclusively banks operating in Turkey and some crypto wallet applications. Beginning 2020, the actors expanded the list of targets to include applications from major banks all around the world (see the appendix for targets). Taking into consideration the ongoing evolution of the Trojan, the expansion of the target list could either mean that the actors decided to grow their fraud opportunity or that they are planning to enter the malware rental market.

Expanding the target list to more countries and more institutions will also pose new challenges for this Trojan; it means trying to remain undetected by a large spectrum of malware and fraud detection solutions.

The next important step for Hydra to be successful internationally will be to add a RAT functionality to its payload. Due to the well-thought-of modular architecture of the bot, actors will certainly be able deal with such enhancements pretty easily; one more reason to keep an eye on it!

Ginp

Ginp appeared on the threat landscape in the second half of 2019 as a simple SMS stealer, completely written from scratch. It is not unusual to see actors attempt to create new malware now and then, but in this particular case the malware started to evolve rapidly, going through frequent development cycles.

In the months following its first appearance, it has adopted techniques used by mature banking malware, sometimes even reusing code snippets from existing malware such as Anubis. By fall 2019, Ginp was already a fully-fledged banking Trojan, capable of performing credit card and credential theft using overlay attacks.

The frequency at which this Trojan is evolving is quite surprising: authors have issued more than 10 different variants of the bot in 4 months. Here we highlight the important mutations that Ginp took in that time span:

Another aspect that makes Ginp stand out is the Modus Operandi of its overlay attacks. As visible in the following screenshots of overlays, a remarkable differentiator of Ginp is that all its overlay screens for banking apps consist of at least two steps. The first page of the overlay is used to steal the login credentials, the second one to steal the credit card details. The social-engineering trick is encouraging the victim to “validate” its identity and therefore provide all the previously mentioned information.

The following screenshots show a set of overlays used by Ginp:

So far authors of the Trojan seemed to keep the Trojan private. The actual narrow and very focused target list (see appendix) indicate a certain knowledge and interest in Spanish banks, which could indicate authors’ familiarity with the country.

Although capable of stealing basic personal information from victims, Ginp is yet still lacking functionality when it comes to remaining undetected while performing fraud. Although there is an actual gap, looking at how fast and frequent new versions of the Ginp Trojan are released, there is a high chance that the challenge will be taken care of soon. We can expect Ginp to evolve further in order to circumvent fraud detection measures and therefore also offer functions such as screencast, back connect proxy and possibly even RAT.

Update 10/03/2020

At the end of February the actors behind Ginp added screen capture capabilities to their Trojan. Like previously added functionality, the code is borrowed from the leaked Anubis Trojan source code. It enables the bot to stream screenshots and send them to the C2 so that actors can see what is happening on the screen of the infected device.

Anubis

Although no longer officially supported since the conviction of its author, Anubis is still a common choice of criminals when it comes to Android banking malware. Since both client and server source code are publicly accessible for free, this does not come as a surprise. Some of the new users even made changes to it, fixing the bugs and gradually improving some aspects of the Trojan to sell or rent it in underground forums.

Even though some changes have been observed in certain Anubis campaigns, no major changes have been introduced by those secondary sellers. Most changes are either fixes of known issues or improvements of existing features (such as automatic disabling of Google Play Protect). In January 2020 a new sales post appeared in some underground forum offering a modified version of Anubis 2.5 actually promising a RAT feature:

Translation:

Additionally, at the moment we develop VNC (commonly used as a synonym for RAT in the malware community). It will be implemented in the coming month. Persons, who supported the service by purchasing the bot, will be granted a chance to work as our partners, build will cost around 15k. Maybe a little less.

With VNC implemented, bot will install an app from the Google Play store on the victim’s device and after that you will get an access code. The victim will be able to see when you are accessing the device, it is not possible to hide that process in Android. However, we will add the feature that will allow disabling the screenlock. If the screen of the device is locked, bot will receive the command to unblock the device. After that you can connect to the phone and perform necessary transactions. It should be OK for nighttime; you shouldn’t have any problems.

I accept your requests to add any feature to the bot. We will discuss prices individually. Injects will happen once in 3-4 months.

Judging by this humble and not very technical description, it seems that the actors behind this post chose an implementation similar to how Cerberus is offering its RAT feature: using a third-party application to control the infected device. Although this statement should be taken with caution (there is no honor among the thieves), there is a high chance we will see new variants of the Anubis Trojan offering a fully-fledged RAT, keeping the malware relevant in the current threat landscape.

Conclusion

The arrest in April 2019 of “maza-in”, author of the Anubis Trojan, caused a shortage of rented and supported Android banking Trojan in the mobile threat landscape. It resulted in many actors staying low and scared, unable to use a convenient banking Trojan. Anubis followed the fate of Exobot and GMBot, becoming a free publicly available banking malware that was shadowed by commercial products.

The aforementioned calm, however, didn’t last for long. Shortly after discontinuity of the Anubis malware rental service, a new successful commercial service appeared which is operational to this date - Cerberus. In addition, some actors chose to start development of their own banking Trojans, resulting in new malware such as Ginp.

Existing banking Trojans have continued evolving in order to remain relevant and successful. Creative and inventive, certain threat actors have been able to enhance their malicious tools to remain under the radar while growing fraud revenue. Gustuff and Hydra are good examples of such with their own view on implementation of Automated Transaction Systems and Remote Access.

This year we can expect the threat landscape to evolve further, with new banking malware families appearing and older ones being enhanced with new capabilities. It seems that in order to keep up with contemporary fraud detection solutions and successfully perform fraud, malware authors will continue implementing features that facilitate on-device fraud. More than ever, a clear overview and understanding of the threat landscape is crucial, and tools to detect the presence of such malware on devices have become invaluable to avoid fraud.

Mobile Threat Intelligence

Our threat intelligence solution – MTI, provides the context and in-depth knowledge of the past and present malware-powered threats in order to understand the future of the threat landscape. Such intelligence, includes both the strategic overview on trends and the operational indicators to discern early signals of upcoming threats and build a future-proof security strategy.

Client Side Detection

Our online fraud detection solution – CSD, presents financial institutions with the real-time overview on the risk status of their online channels and related devices. This overview provides all the relevant information and context to act upon threats before they turn into fraud. The connectivity with existing risk or fraud engines allows for automated and orchestrated, round the clock fraud mitigation.

Appendix

Cerberus

Samples

Target list

Gustuff

Samples

Target list

List of browser overlay targets

Hydra

Samples

Target list

Ginp

Samples

Target list