Report an incident
Report an incident

Analysis of a Polish BankBot

    Analysis of a Polish BankBot

    Recently we have observed campaigns of a banking malware for Android system, which targets Polish users. The malware is a variant of the popular BankBot family, but differs from the main BankBot samples. Its victims were infected by installing a malicious application from Google Play Store. We are aware of at least 3 applications that were smuggled to Google Play Store and bypassed its antivirus protection:

    • Crypto Monitor
    • StorySaver
    • Cryptocurrencies Market Prices

    The last one is an older version which was uploaded to VirusTotal on 13.10.2017.

    According to the ESET’s analysis “Crypto Monitor” and “StorySaver” reached between 1000 and 5000 downloads. In each case, the malware pretended to be a benign, useful application.

    The primary function of the trojan is the theft of credentials to online banking systems. It contains a hardcoded list of Polish banking applications that the malware impersonates, for example PKO Bank Polski, mBank, ING Bank Śląski and Bank Pekao SA (the full set of targeted applications is presented further in this post). Samples that we have analyzed do not target banking applications in languages other than Polish.

    Additionally, BankBot is also capable of reading SMSes and showing fake notifications.

    Basic information

    So far we have not observed any code obfuscation in this variant of BankBot. The trojan uses Firebase, which is a platform that allows developers to create applications using a cloud service. It allows to use multiple services, including databases, without the need to host a backend server. Interesingly, Bankbot uses the platform only for generating tokens and receiving messages from Firebase Cloud Messaging, however stolen login credentials are sent to an external C&C server via HTTP. Firebase is not suitable for storing credentials because, with a link to the database, it would be possible for third parties to read and write any data.

    The URL that identifies the database hosted by Firebase can be found in file res/values/strings.xml. For example, for the application “Crypto Monitor” it contains the following entry:

    Bankbot requests the folllowing permissions:

    • android.permission.INTERNET
    • android.permission.ACCESS_NETWORK_STATE
    • android.permission.ACCESS_WIFI_STATE
    • android.permission.WRITE_EXTERNAL_STORAGE
    • android.permission.READ_PHONE_STATE
    • android.permission.READ_EXTERNAL_STORAGE
    • android.permission.SEND_SMS
    • android.permission.RECEIVE_SMS
    • android.permission.READ_SMS
    • android.permission.WRITE_SMS
    • android.permission.RECEIVE_MMS
    • android.permission.WAKE_LOCK
    • android.permission.VIBRATE

    List of targeted banks:

    The method of stealing money

    First, the malware generates a Firebase ID token, which is used to identify users. Then, it obtains a list of installed applications and compares it with the list of names of attacked banking applications. The corresponding decompiled code is presented below:

    If any of these applications is installed, a WebView object is created. Such objects are used to embed web pages in an application. In this case, the trojan embeds a phishing page corresponding to that bank.

    For example:

    If a user submits login details, they are not stored on the server-side immediately, as happens in the case of an ordinary phishing webpage. Instead, the phishing website shows a JavaScript prompt window that contains data that was just provided (if the user has written my_password in a password field, the window will contain pl.pkobp.iko user: my_password). These windows are invisible if a victim tries to log-in through the malicious application, because they are “hooked” through overwriting of the onJsPrompt function inside a class that extends WebChromeClient. The trojan reads credentials from invisible windows and sends them to a C&C server via HTTP.

    It is shown in the following code:

    To withdraw money from the bank, the botmaster still needs to obtain an authorization code that is sent via SMS. This is done by capturing all received SMSes and sending them to the C&C server, similarly as other data. The code that is responsible for this malicious activity is a part of a class that extends BroadcastReceiver, presented below:

    The malware can also display fake login windows after receiving a message from Firebase Cloud Messaging, which contains the name of the application that will be impersonated. The relevant code is inside a class that extends FirebaseMessagingService. In this scenario, a false notification from the banking service is displayed. If a victim opens the notification, a window with a fake banking login page will open.

    The trojan also implements the “lock” command, which sets itself as a default application for receiving SMS messages:

    Communication with C&C

    Before sending stolen data to the server, registration of the infected phone takes place. It is done by sending an HTTP request which contains the following information:

    • IMEI number
    • name of the network operator
    • phone number
    • Android version
    • current country
    • list of installed applications
    • phone model
    • 1.0 constant (probably a version of the malware)
    • token that was generated by Fireabse
    • server_id: a constant that has different value in every sample.

    After a bot is registered, all further requests contain the IMEI number as the bot identificator.

    The following script can be used to communicate with a C&C server:

    How to avoid infection?

    We advise to avoid installing applications from untrusted sources. However, recent experiences show that Google Play Store can contain harmful applications as well. To protect from malicious software, one can take advantage of built-in security mechanisms of Android itself: before installing an application, it shows the list of requested permissions. For example, if an application is supposed to monitor currency exchange rates, but asks for the permission to read SMSes, it is likely that it steals them. On the other hand, excess of required permissions does not necessarily mean that an application is malicious. Sometimes developers request more permissions than the application actually needs, which might be a simple mistake or due to insufficient understanding of the Android security model on their part, although it is a rare case.

    Yara rule




    86aaed9017e3af5d1d9c8460f2d8164f14e14db01b1a278b4b93859d3cf982f5 204f2e5e18691156036cbcfc69fa759272a2180fba77a74415ccb2c7469a670b 75759cc9af54e71ac79fbdc091e30b4a6e5d5862d2b1c0decfb83c9a3d99b01b

    Other analyses