When you search for Anti-Virus (AV) solutions to protect your mobile devices, you don’t expect these solutions to do the opposite i.e. make devices vulnerable to malware.
This what the Check Point Research (CPR) team encountered while analyzing suspicious applications found in Google Play. These applications pretended to be genuine AV solutions while in reality they downloaded and installed an Android Stealer called Sharkbot.
Sharkbot steals credentials and banking information. The malware implements a geofencing feature and evasion techniques that makes it stand out in the field. It also makes use of Domain Generation Algorithm (DGA), an aspect rarely used in the world of Android malware. Sharkbot lures victims to enter their credentials in windows that mimic benign credential input forms. When the user enters credentials in these windows, the compromised data is sent to a malicious server.
Sharkbot has a handful of tricks up its sleeve. It doesn’t target every potential victim it encounters, but only select ones, using the geofencing feature to identify and ignore users from China, India, Romania, Russia, Ukraine or Belarus.
Figure 1 -Geofencing feature as implemented in Sharkbot.
Evasion techniques are also a part of Sharkbot’s arsenal. If the malware detects it is running in a sandbox, it stops the execution and quits.
Figure 2 – Evasion technique encountered in Sharkbot.
In the Google Play store, we spotted a total of six different applications that were spreading Sharkbot.
Figure 3 – Icons and names of the applications we found.
These six applications came from three developer accounts, Zbynek Adamcik, Adelmio Pagnotto and Bingo Like Inc. When we checked the history of these accounts, we saw that two of them were active in the fall of 2021. Some of the applications linked to these accounts were removed from Google Play, but still exist in unofficial markets. This could mean that the actor behind the applications is trying to stay under the radar while still involved in malicious activity.
The applications removed from Google Play were downloaded and installed approximately 15 thousand times. Following information we got from www.appbrain.com.
Figure 4 – Statistics of the developers’ accounts. Unpublished applications are outlined.
After spotting the applications that spread Sharkbot, we immediately contacted Google and reported our findings. After a fast yet thorough examination, all the applications that were found spreading Sharkbot were permanently removed from the Google Play store.
However, the Sharkbot malware is still active. In this article, we provide a deep technical analysis of Sharkbot and reveal the steps that helped us to spot the malware-spreading applications on Google Play.
February 25, 2022 – We discovered 4 applications of SharkBot Dropper on Google Play.
March 03, 2022 – We reported Google about found applications.
March 03, 2022 – NCC Group published their research on Sharkbot Dropper.
March 09, 2022 – Reported applications removed from Google Play.
March 15, 2022 – One more SharkBot dropper discovered on Google Play, 0+ installs. Same day we reported this application to Google.
March 22, 2022 – One more SharkBot dropper discovered on Google Play, 0+ installs. Same day we reported this application to Google.
March 27, 2022 – newly found SharkBot dropper’s removed from Google Play.
We already mentioned that Sharkbot implements evasion techniques and a geofencing feature, but these are not its only noteworthy tricks. Another distinctive aspect present in Sharkbot is the use of DGA, which is rarely seen in Android malware. With DGA, one sample with a hardcoded seed generates 7 domains per week. Including all the seeds and algorithms we have observed, there is a total of 56 domains per week, i.e., 8 different combinations of seed/algorithm.
Speaking of its main functionality, Sharkbot implements the traditional toolkit for Android bankers and stealers. As a vivid example, we saw the abuse of the Accessibility Service which provides the application with access to all the data which is seen by the user and also allows the application to interact with an interface as though as it were a person.
During our observations, 27 versions of the bot were discovered. The main differences between the versions are different DGA seeds as well as different botnetID and ownerID fields. For more information on the different versions and a change log, see the Appendix.
The Sharkbot malware implements a total of 22 commands that allow various kinds of malicious actions to be executed by a Command-and-Control server (CnC) on the infected device.
This table shows the commands used and their descriptions:
Requests permission for sending SMS.
Downloads and stores a jar file with java code.
Updates a given option in local DB.
Updates the different options.
Uninstalls a given application.
Sends the contacts list to the server.
For the user to change the default SMS manager.
Disables the battery optimization, so Sharkbot can run in background
Creates the “Injection” window from a given URL.
For the user to enable Sharkbot as Accessibility Service.
Updates the “TIME_KNOCK_ADMIN” option.
Displays a PUSH-notification for the user.
Prevents the user from activating the application.
Imitate the user’s swipe over the device’s screen.
Sets up an autoreply message on Push-notifications.
Silently uninstalls a given application.
Sends SMS messages to the provided phone numbers with a provided text.
Turns on Notification Listener permission for the Sharkbot application.
Starts given applications and logs all Accessibility Events.
Sends an SMS with given text to a given number.
Downloads a file from provided URL and stores it locally with an APK extension.
A command is transferred to the jar-file, dropped with the updateLib command.
If unknown command arrives from server, then this command is sent to jar-file, dropped with updateLib command.
Below we provide a more detailed description of the commands supported by the malware.
Checks if permission for sending SMSs is granted. If not, then the user is asked to grant permission to send and read SMSs.
With this command, the CnC sends code for overlay injects for the user’s applications. The code is saved to a local jar-file. We named this module jarMod. The CnC can send commands to jarMod, including updateConfig, changeSmsAdmin and any uncategorized command.
Figure 5 – Code block of executable dropper.
Sharkbot stores local configuration in an SQLite DB (database) in the file database.db or sharked.db located at the path /data/data/<package_name>/databases/. Values in the DB are stored in encrypted form.
Figure 6 – Example of a local database.
With the help of the updateSQL command values in the database can be updated.
With this command, the CnC address and the name of the application for injection can be updated:
Figure 7 – Storing new configuration.
Uninstalls the application with the provided package name:
Figure 8 – Uninstalling an application.
Collects and sends contacts to the server.
Sends the name of old and currently default SMS applications to the CnC, and sends a command to the previously downloaded jar code (see updateLib command).
Figure 9 – Handler of the changeSmsAdmin command.
Used to disable battery optimization for Sharkbot’s package.
Figure 10 – Disabling battery optimization for the Sharkbot application.
Performs overlay inject with a form from a provided URL.
Figure 11 – Performing inject.
Used to enable the Accessibility Service for Sharkbot:
Figure 12 – To enable the Accessibility Service for Sharkbot.
Set the field “TIME_KNOCK_ADMIN” in the local DB to the provided value.
Figure 13 – Updating knock time.
Shows the user a push message with provided text.
Figure 14 – Code to show a push-message to the user.
With this command, the CnC sets up package names for which the Accessibility Service prevents the user from accessing these applications:
Figure 15 – Prevent the user from accessing an application.
By default, 2 package names are used: com.android.settings and com.samsung.accessibility
Figure 16 – Default applications to prevent access.
With this command Sharkbot can imitate the user’s swipe over the device’s screen:
Figure 17 – Emulating swipe sequences.
This appears as if it was designed to unlock an application or the whole device.
This is not an actual command, but a field in the updateConfig command. With the autoReply field, the server sends a message to imitate an answer on push events. The command consists of an array with two fields in each element of the array:
Figure 18 – Example of the autoReply field.
It is possible to set different messages for each application. On Figure 18, you can see messages for two different applications: WhatsApp messenger and Facebook messenger.
In Figure 18, we caught the test period for the development of the autoreply feature. We can say that because both messages target www.google.com.
You can also use one message for all notifications. Here is a variant from the production usage:
Figure 19 – One message for all notifications.
This is not a command, but a field of the updateConfig command. With the removeApp command, the server sends a huge list of applications which should be uninstalled from the user’s device. At present, this list contains 680 applications.
Figure 20 – Uninstalling applications.
There are very few types of malware that can work without communicating with a CnC server; stealers and bankers are the ones which can’t. If a malware operator has several servers, then it’s easy to block access to them either by a corporate firewall, or with the AV software installed on the device. After the CnCs are blocked, an operator can change the domain name of the CnC server but how are already installed clients supposed to learn about the server change? This is where Domain Generation Algorithm enters the scene.
DGA is an algorithm by which a malicious client and malicious actor can change the CnC server in concert, without any communication. DGA is a piece of code which runs on a client and generates dynamic names for the CnC server, so if today one CnC server is blocked then within a day, a week or a month, a new name for the CnC will be generated and used. This algorithm complicates the process of blocking malware operators’ servers.
Usually DGA consists of two parts: the actual algorithm, and the constants used by the algorithm. These constants are called DGA seeds.
As we mentioned earlier, implementing DGA is rarely observed in Android malware, but Sharkbot is an exception.
Before the connection to the DGA domains is made, Sharkbot attempts to connect to the static URL hardcoded inside:
Figure 21 – Static CnC URL.
Only if the static server does not respond, Sharkbot uses an embedded DGA procedure to get relevant domains for the current date and then attempts to connect to them one by one:
Figure 22 – DGA code.
The final string for DGA consists of several fields:
Current year (using since 02.09.2022)
Current week number
We noticed that the seed-word is changed across samples. We caught the following variants:
“” (no word)
Figure 23 – Using seeds in domain name generation.
The exchange with the CnC server happens over HTTP with POST request on path /. Each request and answer is encrypted with RC4. The key for RC4 is transferred encrypted with the RSA public key. The request consists of 2 fields:
rkey: Used to transfer the RC4 encryption key. The key is encrypted with the RSA public key.
rdata: Used for data, encrypted with RC4.
Figure 24 – RAW request to the server.
The answer consists of the encrypted data only.
Figure 25 – RAW answer from the server.
In a clean view protocol you can find the JSON data. The bot acts as a client, and the CnC acts as a server. A typical request from the bot looks like this:
Figure 26 – Clear request to the server.
When a server has no commands to send, it answers with “ok”:
Figure 27 – Server answer without command.
When a server has commands for the bot, the answer looks like this:
Figure 28 – Server answer with command.
These are the fields in the answer:
dataCommand: Type of packet.
command: Type of command.
CommandID: We observed this field is increased by one for every command, and is sent by the server.
data: Command data, whose contents depend on the type of command.
Periodically, with a fixed period of time, the bot sends a knock-packet to the server. By default, this packet is sent every 30 seconds. The server can change the time period with the command updateTimeKnock. Here is how a knock-packet looks :
Figure 29 – Keep-alive packet.
The value for a knock field is chosen at random:
Figure 30 – Choosing the knock value.
At the time of publication, we counted 8 IP addresses which were Sharkbot’s CnC servers at different times. During our research of the infrastructure, we spotted a field commandID in some answers from the server. This field is used to identify each command sent from the server to the client.
After more detailed analysis, we can assume that this field is increased by one for each command sent from the server. During our experiments, we noticed that this value does not depend on the particular CnC server but instead is a common value for all of them.
Here are the logs of the requests and response exchange with different servers on January 25, 2022, one after the other:
Server mnbvakjjouxir0zkzmd[.]xyz with IP 31[.]214.157.112 :
Figure 31 – Request to the server, at 15:45:12.487.
Figure 32 – Answer from the server, at 15:45:13.80.
Server mjaynxbvakjjouxir0z[.]xyz with IP 109[.]230.199.99:
Figure 33 – Request to the server, at 15:48:06.448.
Figure 34 – Answer from the server, at 15:48:07.45.
As you can see, the value of commandID changed by exactly one. From this we can assume even more:
There is one real server, and the others work as relays.
We can use the values of the field commandID to evaluate the activity of the server sending commands to clients.
Using the value of the commandID field, we can estimate the activity of Sharkbot’s servers. We calculated an average increase of the commandID value per hour for the period from January 26 to March 23 and got the following result:
Figure 35 – Sharkbot server activity.
We can see that activity increased, with the peak at the beginning of March. This correlates with the active use of Sharkbot’s dropper on Google Play.
The following chart shows the number of unique IP addresses encountered in the period from February 14 to February 20:
Blue bars denote the count of unique IP addresses per day.
Red bars denote the count of unique IP addresses, excluding the ones already seen in the previous days.
Figure 36 – Unique IP addressed statistics observed in the middle of February.
During our observation for this particular week in February, we saw approximately one thousand unique IP addresses in total.
The following chart shows the location-based statistics. The main targets are Italy and the United Kingdom.
Figure 37 – Regional statistics.
Now that we described different aspects of Sharkbot, to complete the picture, we discuss the methods by which Sharkbot spreads. As mentioned at the beginning, the malware is downloaded and installed by the dropper applications in Google Play which masquerade as AV solutions. These are the applications:
They have some additional tricks.
The droppers detect emulators and quit if one is found. No communications with CnC are started in this case:
Figure 38 – Emulation evasion and region restrict code.
There is also a geofencing technique implemented inside the droppers, as can be seen in the image above. The malicious part of the applications is not triggered if the locale is set to China, India, Romania, Russia, Ukraine or Belarus.
The part of the application controlled by the CnC server understands 3 commands:
b: Download and install the APK file from the provided URL.
c: Store the autoReply field in a local session.
d: Restart the execution of the local session.
All of these applications request the same set of permissions:
Figure 39 – Permissions.
The applications register the service to get access to Accessibility Events:
Figure 40 – Accessibility Service description.
Below we describe the key parts of the malicious code in the applications.
With this command from the CnC, an application can abuse the Accessibility Service for its own needs. The Accessibility Service is able to execute different “tasks”, which are extracted from the Intent:
Figure 41 – Setting up the Accessibility Service “task.”
This “task” is later used in the event’s dispatcher. For example:
Figure 42 – Accessibility Service “task” dispatching.
The “task” describes which actions should be performed for particular events. For example, the default “task” looks like this:
Figure 43 – Accessibility Service “task” by default.
This “task” instructs the Accessibility dispatcher to perform a CLICK on a node, which contains a text Alfa Antivirus, Cleaner.
The Accessibility dispatcher supports the following actions:
CLICK: Performs click-action, on a chosen control.
SCROLL_BACKWARD: Performs back-action, on a chosen control.
intent: Performs permission request for: android.settings.MANAGE_UNKNOWN_APP_SOURCES or android.settings.action.MANAGE_OVERLAY_PERMISSION
During the execution of a given “task”, every event is sent to the CnC:
Figure 44 – Sending an Accessibility event to the CnC server.
The malware can drop and install the APK file on the user’s device:
Figure 45 – Code to install the application.
Figure 46 – Code to drop the application.
The stored field autoReply works the same way as autoReply for Sharkbot, as described earlier. Malware answers with a message provided by the CnC to application, which generates a push notification.
As we can judge by the functionality of the droppers, their possibilities clearly pose a threat by themselves, beyond just dropping the malware. The droppers are able to inspect and act on all the UI events of the device as well as replace notifications sent by other applications. In addition, they can install an APK downloaded from the CnC, which provides a convenient starting point to spread the malware as soon as the user installs such an application on the device.
In the ever-changing contemporary (cyber-)world, nothing should be taken for granted. If a new AV solution appears in Google Play today, there’s no way to guarantee it won’t turn out to be a malware spreading threat tomorrow. This is the exact case we observed with the Sharkbot malware.
In this spreading scheme, the malware itself is not uploaded to Google Play but rather the intermediate link is, which masquerades as a legitimate software. As we can see by more than 15,000 installations for all the applications in total, people can be lured by a beautiful icon and a promise to “protect their devices.”
The Check Point Research Team is constantly monitoring this and other threats in the mobile landscape, and we immediately notified Google of the malicious behavior we encountered. Despite a fast response from Google, which removed applications linked to threat actor accounts, more attempts were made in Google Play with more droppers from different accounts. They were all subsequently removed as well, but the damage from 15,000 thousand installations was already done.
Google Play Protect’s solid reputation should not decrease user awareness that threat actors are constantly evolving their malware and looking for new schemes to execute this malware on victims’ devices. Our advice to Android users:
Install applications only from trusted and verified publishers.
If you see an application from a new publisher, search for analogs from a trusted one.
Report to Google any seemingly suspicious applications you encounter.
Check Point’s Harmony Mobile Prevents malware from infiltrating mobile devices by detecting and blocking the download of malicious apps in real-time. Harmony Mobile’s unique network security infrastructure – On-device Network Protection – allows you to stay ahead of emerging threats by extending Check Point’s industry-leading network security technologies to mobile devices.