SharkBot: a new generation of Android Trojans is targeting banks in Europe

• At the end of October 2021, a new Android banking trojan was discovered and analyzed by the Cleafy TIR team. Since we didn't find references to any known families, we decided to dub this new family SharkBot.
• The main goal of SharkBot is to initiate money transfers from the compromised devices via Automatic Transfer Systems (ATS) technique bypassing multi-factor authentication mechanisms (e.g., SCA). These mechanisms are used to enforce users' identity verification and authentication, they are usually combined with behavioural detection techniques to identify suspicious money transfers.
• We identified a botnet which is currently targeting the UK, Italy, and the US, including banking applications and cryptocurrency exchanges. Given its modularity architecture we don't exclude the existence of botnets with other configurations and targets.
• Once SharkBot is successfully installed in the victim's device, attackers can obtain sensitive banking information through the abuse of Accessibility Services, such as credentials, personal information, current balance, etc., but also to perform gestures on the infected device.
• At the time of writing, SharkBot appears to have a very low detection rate by antivirus solutions since multiple anti-analysis techniques have been implemented: string obfuscation routine, emulator detection and a domain generation algorithm (DGA) for its network communication in addition to the fact that the malware has been written from scratch.
• SharkBot implements Overlay attacks to steal login credentials and credit card information and it also has capabilities to intercept legitimate banking communications sent through SMS.
• At the time of writing, multiple indicators suggest that SharkBot could be at its early stages of development.

At the end of October 2021, a new Android banking trojan appeared on Cleafy's telemetries. Since the lack of information and the absence of a proper nomenclature of this malware family, we decided to dub it SharkBot to better track this family inside our internal Threat Intelligence taxonomy.

SharkBot belongs to a “new” generation of mobile malware, as it is able to perform ATS attacks inside the infected device. This technique has been already seen recently from other banking trojans, such as Gustuff. ATS (Automatic Transfer System) is an advanced attack technique (fairly new on Android) which enables attackers to auto-fill fields in legitimate mobile banking apps and initiate money transfers from the compromised devices. Contrary to TeaBot and Oscorp/UBEL where a live operator is required to insert and authorize a money transfer, with ATS technique Threat Actors can scale up their operations with minimum user intervention. We assume that SharkBot is trying to bypass behavioural detection countermeasures (e.g.,biometrics) put in place by multiple banks and financial services with the abuse of Android Accessibility Services, also bypassing the need of a “new device enrollment”.

Moreover, SharkBot appears to have all the main features of nowadays Android banking trojan achieved by abusing Accessibility Services[1]such as:

• Ability to perform classic Overlay Attacks against multiple applications to steal login credentials and credit card information
• Ability to intercept/hide SMS messages
• Enabling key-logging functionalities
• Ability to obtain full remote control of an Android device (via Accessibility Services)

At the time of writing, we didn’t notice any samples on Google's official marketplace. The malicious app is installed on the users' devices using both the side-loading technique and social engineering schemes.

Thanks to an in-depth analysis of several samples related to SharkBot, we collected 22 different targets including international banks from UK and Italy and 5 different cryptocurrency services, as shown in the following Figure 2:

[1] https://developer.android.com/reference/android/accessibilityservice/AccessibilityService

SharkBot, is a new generation Android banking trojan, discovered by Cleafy Threat Intelligence team at the end of October 2021. The name “SharkBot” comes from multiple strings found in its binaries, which contain the word “sharked”.

SharkBot hides itself with common names and icons posing as a legitimate application to the victims, as shown in Figure 3.

However, during its installation, SharkBot immediately tries to enable Accessibility Services that keep being requested persistently with fake pop-ups until the victim accepts.

Once the malicious app has been installed, no icon is displayed on the device and SharkBot is able to get all the permissions needed (declared inside the AndroidManifest file) thanks to the accessibility services enabled. This is done by clicking instantly on the popup shown to the user.

With the permissions shown in Figure 5, SharkBot is able to read/send text messages, perform overlay attacks and, with the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, it is able to bypass Android's doze component and stay connected to the C2 servers to continue its malicious behavior.

At the time of writing, Sharkbot seems to be still under development as the very first samples tracked down at the end of October use:

• a demo version of the Allatori Java Obfuscation [2] (as shown in Figure 6).
• the word “example” in the package name.
• the words “test1” and “testuk” inside the C2 used during the first exchange of information with malware.
• some functionalities are not yet available.

So far, SharkBot has a very low detection rate by antivirus solutions (only 3/62), as shown by Figure 7. This means that the malware has been written from scratch, in addition to the fact that it uses an external module, downloaded from the C2, containing the ATS core functionalities and anti-detections technique used to slow down the static and dynamic analysis.

Analysing the underground hacking forums, we didn’t find any references to this malware. This makes us think that SharkBot is still a private botnet.

[2] http://www.allatori.com/ (*Allatori is a legitimate software)

SharkBot uses different anti-analysis and detection techniques, in particular:

• Strings obfuscation, to slow down the static analysis and “hide” all the commands and important information used by the malware, as shown in Figure 9.

• Anti-Emulator. When the malicious application is installed on the device, it checks if the device is an emulator or a real phone. This technique is usually used to bypass sandboxes or common emulators used by researchers during the dynamic analysis.
• External ATS module. Once installed, the malware downloads an additional module from the C2. The external module is a “.jar” file that contains all the functionality used to perform the ATS attacks. We analyze this module in the paragraph “SharkBot - ATS (Automatic Transfer System) module”.
• Hide the icon app. Once installed, SharkBot hides the icon of the app from the device screen.
• Anti-delete. Like other malware, SharkBot uses the Accessibility Services to avoid that the user uninstalls the malicious application from the settings options.
• Encrypted communication. All the communication between the malware and C2 are encrypted and encoded with Base64. In addition to this, SharkBot uses a Domain Generator Algorithm (DGA).

Although SharkBot has an ATS module, it also has some common features present in other banking trojan, in particular:

• The capability to read and hide SMS received from the infected user (sending them to the threat actor C2 server). This feature is mostly used by threat actors to get the 2FA sent by the bank via text messages.
• The “now famous” overlay attack used to steal login credentials and credit card data. This feature is used by SharkBot to obtain the login credentials of the targeted banks/crypto app, to perform the ATS attack to the next step.

Android’s Accessibility Service has been historically abused by multiple banking trojans (e.g., TeaBot, Oscorp/UBEL) for conducting multiple malicious actions in the infected device. SharkBot, similar to Gustuff, is able to abuse Accessibility Service enabling ATS attacks inside the infected device.

ATS (Automatic Transfer System) attacks enable TA to auto-fill fields in legitimate mobile banking apps and initiate money transfers from the compromised devices to a money mule network controlled by TA or other affiliates. This makes it possible to scale up their operations with minimum user intervention.

For a bank perspective, mobile ATS attacks are very hard to identify and handle since typically:

• They don't require a “new device enrollment” phase which drastically reduces their footprint.
• They are able to bypass any 2FA mechanism used by banking applications (e.g. SMS-based, push-based, etc.).
• As all the actions are performed by the trusted user, ATS attacks are able to bypass Behavioral detection mechanisms, including Behavioral biometrics.
• Illegitimate wire transfers are inserted and authorized on the victim device itself, which typically is considered “trusted” by banks.

Once a victim has granted accessibility permissions, all the contents shown in the device screen can be intercepted and manipulated by SharkBot. Those capabilities are gained through Android AccessibilityEvents which are events that are sent by Android OS when something notable happens in the user interface. In fact, the main purpose of an accessibility event is to communicate changes in the UI to an AccessibilityService.

SharkBot appears to have interest only on a specific subset of accessibility events, which are the following:

We can group all the accessibility events intercepted by SharkBot as follows:

SharkBot has already implemented various functions which are been used for parsing all the data extracted from the UI, save them into a JSON format and exfiltrate them to the designed C2 server:

TA can also passively logs all the exfiltrated information from each infected device and enriching them with detailed information useful for a further ATS attack, such as account balance(s), enabled 2FA/SCA/MFA mechanisms, cash-out availability (e.g. SEPA, Instant payments), etc.

Once the ATS attack is remotely requested by TA, SharkBot will start interacting with the infected device and auto-fill fields in legitimate mobile banking apps and initiate money transfers. During this phase TA can also interact with the targeted application simulating gestures and clicks, if required.

With the discover of SharkBot we have shown new evidence about how mobile malwares are quickly finding new ways to perform fraud, trying to bypass behavioural detection countermeasures put in place by multiple banks and financial services during the last years.

Like the evolution of workstation malwares occurred in the past years, also in the mobile field we are seeing a rapid evolution towards more sophisticated patterns like ATS attacks.

‍

Appendix 1: SharkBot commands

The following table summarize the list of all the commands found in SharkBot during the technical analysis:

‍

Appendix 2: IOCs