Revive: from spyware to Android banking trojan

• On June 15, 2022 a new Android Banking Trojan, dubbed as Revive, was discovered in the wild by Cleafy TIR team.
• According to the evidence found on its code and its command and control infrastructure (C2), Revive appears to be at its early stages.
• Revive appears to be delivered against Spanish citizens through phishing campaigns targeting customers of a specific top-tier Spanish bank.
• Revive will enable Threat Actors (TA) to perform Account Takeover attacks, (ATO).
• Currently, Revive has three main capabilities:
  – Capturing everything written on the device through a keylogger module.
  – Performing “on-device” phishing attacks through the usage of clone pages, which aim to steal  banking  login credentials.
  – Intercepting all SMS received on the infected device, typically from banks and financial institutions in the PSD2 area (e.g. authorization codes 2FA/OTP)
• To increase the attacks’ success-rate, TAs created a video explainer, to support victims during the installation once the malicious application has been downloaded.

In June 2022, a new Android banking trojan was discovered by the Cleafy TIR team. Since the lack of information and the absence of a proper nomenclature of this malware family, we decided to dub it as Revive to better track this family inside our internal Threat Intelligence taxonomy.

The name Revive has been chosen since one of the functionality of the malware (called by the TAs precisely “revive”) is restarting in case the malware stops working.

Revive belongs to a category of malware used for persistent campaigns, as it was developed and tailored for a specific target. This type of malware is quite different from other famous Android banking trojans, such as TeaBot or SharkBot, that are able, at the same time, to attack multiple banks/crypto apps installed on the infected device through their modular architecture.

However, the attack’s methodologies of Revive are similar to other banking trojans as it still  abuses the Accessibility Services to perform keylogging activities and to intercept SMS messages of the victim. The combination of these features are enough to perform Account Takeover attacks (ATO), since TAs are able to obtain login credentials and the 2FA/OTP sent via SMS by banks.

So far, both samples of Revive have a very low detection rate by Antivirus solutions (AVs). As shown by Figure 2, the second sample has zero detection rate, since the malware is clearly still under development.

As in the majority of cases, Revive uses different Social Engineering techniques to appear as a legitimate app in order to mislead the victims. In fact, the malware is delivered through a phishing page and it hides behind a new 2FA app of the targeted bank.

Once the victim downloads the malware, Revive tries to obtain the Accessibility Service feature through a pop-up. This permission is used for  functionality, therefore monitoring and stealing information from the victim device.

When the victim opens the malicious app for the first time, Revive asks to accept two permissions related to the SMS and phone calls. After that, a clone page (of the targeted bank) appears to the user (as shown in Figure 5) and if the login credentials are inserted, they are sent to the C2 of the TAs. After that, the malware shows a generic home page, with different links that redirect to the legitimate bank website.

Analyzing the code, our hypothesis is that the developer of Revive  took inspiration from an open source spyware called “Teardroid”, available on GitHub[3], since there are some code and name similarities both in the application and in the C2 infrastructure used. However, Teardroid is a spyware with different capabilities, while Revive has been developed with a different purpose. TAs removed some features of Teardroid and added new ones in this new variant, enabling ATO attacks. This is why Revive can be considered a banking trojan instead of a spyware.

Moving to its C2 infrastructure, other similar features can be observed as well, since both of them appear to be based on FastAPI, a Web framework for developing RESTful APIs in Python, similar to Django/Flask.

In fact, it appears that TAs also create a variant of the Teardroid control panel [4], adapting it for their needs during a fraud operation (e.g. collecting valid credentials, intercepting SMS messages, etc..).

The following figure shows some of the similarities found during our investigation:

Revive has been developed with the goal of performing ATO attacks against a specific target. In order to achieve this task, the malware has three capabilities:

• Steal the login credentials. The following task can be achieved both with the clone page shown to the user and with the keylogger feature, through the abuse of the Accessibility Services.
• Intercept all messages received from the infected devices, with the aim of obtaining the 2FA of the bank sent to the user via SMS.
• Grab everything  that the user writes on the device (e.g credentials, messages, phone numbers etc, as shown in Figure 10). Those information are saved on a local database and sent to the C2 server.

[3] https://github.com/ScRiPt1337/Teardroid-phprat

[4] https://github.com/ScRiPt1337/Teardroidv4_api

Concurrently to the well-known Android Banking Trojan, like SharkBot, TeaBot or Oscorp/UBEL, that are complex malware with multiple features able to carry out advanced attacks like ATO/ATS, there are also small and tailored campaigns, probably conducted by local TAs. The latter types of scenarios sometimes could be more difficult to intercept, since the malware are usually written from scratch (often not detected by antivirus solutions), with few features tailored for only one target and the campaigns are carried out for only a few days.

At the time of writing, it is difficult to make an hypothesis about the future of Revive, since the malware is still in its early stages (although it is already able to perform ATO attacks); TAs could improve it following multiple paths (e.g.adding new features and transform Revive into a RAT or customizing the malware for other targets).

Appendix 1: IOCs